Development

資料庫備份策略：超越簡單轉儲

Created   Updated
Database Backup MySQL PostgreSQL
  1. 資料庫備份類型
  2. 資料庫備份常見迷思
  3. 進階資料庫備份技術
  4. 資料庫備份實施清單
  5. 資料庫備份 vs 通用資料備份
  6. 資料庫特定考量因素
  7. 做出選擇

資料庫不僅僅是檔案——它們是活躍的、交易性的系統，需要專門的備份方法來保持資料完整性。雖然通用備份策略為我們提供了基礎框架，但資料庫備份涉及獨特的技術挑戰：ACID合規性、參照完整性和交易一致性。

本文深入探討資料庫特定的備份技術，超越基本的轉儲操作，涵蓋進階策略如時間點復原、跨資料庫一致性和效能優化的備份方法。

如需全面的資料價值評估和通用備份策略，請參閱資料備份策略 - 從規劃到復原。

資料庫備份類型

邏輯備份 vs 實體備份

邏輯備份：匯出資料庫結構和資料為SQL語句或特定格式。

優點：

  • 可攜性強，可在不同資料庫版本間使用
  • 人類可讀，便於除錯和部分復原
  • 壓縮效果好
  • 可選擇性備份特定表格或資料

缺點：

  • 復原速度較慢，特別是大型資料庫
  • 需要更多CPU資源進行匯出/匯入
  • 可能無法捕獲所有資料庫物件（如預存程序、觸發器）

實體備份：複製實際的資料庫檔案和日誌。

優點：

  • 復原速度快
  • 完整備份，包含所有資料庫物件
  • 支援增量和差異備份
  • 適合大型資料庫

缺點：

  • 平台相依性強
  • 檔案大小通常更大
  • 需要資料庫停機或特殊工具確保一致性

完整備份 vs 增量備份

備份類型 資料量 復原時間 儲存需求 複雜性
完整備份 全部資料 快速 高 低
增量備份 僅變更 中等（需要多個檔案） 低 中等
差異備份 自上次完整備份的變更 中等 中等 中等
交易日誌備份 交易記錄 最快（時間點復原） 最低 高

資料庫備份常見迷思

🔄 vMotion/即時遷移就是備份

現實情況：VM遷移技術移動執行中的系統，但不會建立復原點。

為什麼錯誤：vMotion在主機間移動VM以進行維護或負載平衡。它不會建立備份、防止資料損毀或提供時間點復原。如果資料庫損毀，vMotion只是將損毀的資料庫移到另一個主機。

正確方法：使用vMotion實現高可用性和維護，使用適當的資料庫備份方法進行資料保護。

📁 檔案系統備份保護資料庫

現實情況：在資料庫執行時複製資料庫檔案可能建立損毀、無法使用的備份。

為什麼錯誤：資料庫檔案持續被修改。在活躍操作期間進行檔案層級備份可能捕獲不一致的狀態，其中某些變更已寫入但其他變更尚未寫入，違反ACID屬性。

正確方法：使用資料庫感知的備份方法，確保交易一致性。

🔄 複寫就是備份

現實情況：複寫提供高可用性，但不能防止邏輯損毀或使用者錯誤。

為什麼錯誤：如果有人刪除表格或損毀資料，損毀會複寫到所有副本。複寫不提供時間點復原或防止應用程式錯誤導致的資料損毀。

正確方法：使用複寫實現可用性，使用備份進行資料保護和復原。

📊 讀取副本不需要備份

現實情況：讀取副本可能損毀、延遲或獨立於主要資料庫發生故障。

為什麼錯誤：讀取副本不是備份——它們是可能遇到自身故障的即時副本。副本延遲可能導致資料遺失，副本損毀可能使其無法用於復原。

正確方法：獨立備份讀取副本並定期驗證其一致性。

⏰ 計劃停機消除備份需求

現實情況：即使在維護視窗期間，資料庫也可能遇到損毀或人為錯誤。

為什麼有限：計劃維護不能防止硬體故障、軟體錯誤或人為失誤。損毀可能隨時發生，擁有最新備份對快速復原至關重要。

正確方法：無論維護視窗如何，都要保持定期備份計劃。

🏥 災難復原就是資料庫備份

現實情況：災難復原（DR）是綜合的業務連續性策略，而資料庫備份是資料保護的一個組成部分。

為什麼不同：DR包括故障轉移系統、備用站點、網路冗餘和業務流程連續性。資料庫備份專門關注資料復原。DR系統可能使用即時複寫，這不提供時間點復原或防止邏輯損毀的保護。

正確方法：使用DR實現業務連續性和高可用性，使用資料庫備份進行資料保護和時間點復原。它們相互補充但服務於不同目的。

進階資料庫備份技術

時間點復原 (PITR)

使用基礎備份和交易日誌將資料庫復原到任何特定時刻。

實作方法：

# PostgreSQL PITR 設定
# 1. 建立基礎備份
pg_basebackup -D /backup/base -Ft -z -P

# 2. 配置連續歸檔
# 在 postgresql.conf 中：
# archive_mode = on
# archive_command = 'cp %p /backup/wal/%f'

# 3. 復原到特定時間
cat > recovery.conf << EOF
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2022-10-11 15:45:00'
recovery_target_action = 'promote'
EOF

跨資料庫一致性

在備份過程中確保多個相關資料庫的一致性。

協調備份：

#!/bin/bash
# 多個資料庫的協調備份

# 在所有資料庫上開始交易
mysql db1 -e "START TRANSACTION WITH CONSISTENT SNAPSHOT;"
mysql db2 -e "START TRANSACTION WITH CONSISTENT SNAPSHOT;"

# 記錄 LSN/位置以保證一致性
mysql db1 -e "SHOW MASTER STATUS;" > backup_position.txt
mysql db2 -e "SHOW MASTER STATUS;" >> backup_position.txt

# 執行備份
mysqldump --single-transaction db1 > db1_backup.sql &
mysqldump --single-transaction db2 > db2_backup.sql &

wait  # 等待所有備份完成

# 提交交易
mysql db1 -e "COMMIT;"
mysql db2 -e "COMMIT;"

備份壓縮和加密

降低儲存成本並保護敏感資料。

壓縮加密備份：

# MySQL 帶壓縮和加密的備份
mysqldump --single-transaction --routines --triggers database_name | \
  gzip -9 | \
  gpg --symmetric --cipher-algo AES256 \
  > backup_$(date +%Y%m%d_%H%M%S).sql.gz.gpg

# PostgreSQL 帶內建壓縮的備份
pg_dump --format=custom --compress=9 database_name | \
  gpg --symmetric --cipher-algo AES256 \
  > backup_$(date +%Y%m%d_%H%M%S).dump.gpg

備份驗證和測試

確保備份有效且可復原。

自動化備份測試：

#!/bin/bash
# 自動化備份驗證指令程式

BACKUP_FILE="$1"
TEST_DB="backup_test_$(date +%s)"

# 建立測試資料庫
mysql -e "CREATE DATABASE $TEST_DB;"

# 將備份復原到測試資料庫
if mysql $TEST_DB < $BACKUP_FILE; then
    echo "成功：備份復原成功"
    
    # 執行一致性檢查
    mysqlcheck --check --all-databases $TEST_DB
    
    # 驗證列數是否符合預期值
    EXPECTED_ROWS=$(mysql -sN -e "SELECT COUNT(*) FROM production.users;")
    ACTUAL_ROWS=$(mysql -sN -e "SELECT COUNT(*) FROM $TEST_DB.users;")
    
    if [ "$EXPECTED_ROWS" -eq "$ACTUAL_ROWS" ]; then
        echo "成功：列數驗證通過"
    else
        echo "錯誤：列數不匹配 - 預期：$EXPECTED_ROWS，實際：$ACTUAL_ROWS"
    fi
else
    echo "錯誤：備份復原失敗"
fi

# 清理測試資料庫
mysql -e "DROP DATABASE $TEST_DB;"

資料庫備份實施清單

備份策略：

  • ✅ 定義資料庫特定的RPO和RTO要求
  • ✅ 選擇適當的備份方法（邏輯、實體、交易日誌）
  • ✅ 實作時間點復原功能
  • ✅ 設計跨資料庫一致性策略

一致性和完整性：

  • ✅ 使用交易一致的備份方法
  • ✅ 復原後驗證參照完整性
  • ✅ 定期測試備份和復原程序
  • ✅ 監控備份完成情況和成功率

效能和可用性：

  • ✅ 最小化備份對生產系統的影響
  • ✅ 盡可能使用讀取副本進行備份操作
  • ✅ 實作並行備份和復原過程
  • ✅ 在低活動期間安排備份

安全和合規：

  • ✅ 加密敏感資料庫備份
  • ✅ 實施安全的備份儲存和存取控制
  • ✅ 維護備份和復原操作的稽核日誌
  • ✅ 滿足監管資料保留要求

監控和警報：

  • ✅ 監控備份作業完成情況和持續時間
  • ✅ 對備份失敗或異常進行警報
  • ✅ 追蹤備份儲存使用情況和成長
  • ✅ 自動驗證備份完整性

資料庫備份 vs 通用資料備份

資料庫備份：尊重ACID屬性和交易一致性的專業化備份方法。

通用資料備份：適用於文件、配置和靜態資料的檔案級備份。

主要區別：

方面 資料庫備份 通用資料備份
一致性 交易性 檔案級
方法 邏輯、實體、WAL 完整、增量、差異
複雜性 高 中等
復原 時間點 檔案還原
效能影響 資料庫感知 儲存級
驗證 ACID合規 檔案完整性

資料庫特定考量因素

資料庫備份決策涉及超越通用資料保護的獨特技術和業務考量：

技術複雜性：

  • ACID合規：在備份過程中確保交易一致性
  • 參照完整性：維護外鍵關係
  • 效能影響：最小化對生產系統的干擾
  • 復原粒度：時間點 vs 完整資料庫還原

業務因素：

  • 資料關鍵性：客戶記錄 vs 日誌資料 vs 使用者生成內容
  • 合規要求：金融或醫療資料的監管要求
  • 復原時間目標：資料庫必須多快復原？
  • 一致性要求：是否可以容忍一些資料遺失或不一致？

SaaS資料庫考量：
使用託管資料庫服務時，評估：

  • 提供商的備份功能和SLA
  • 您匯出/匯入資料的能力
  • 供應商鎖定風險和資料可移植性
  • 實施額外備份層的成本

有關全面的資料價值評估框架，請參閱資料備份策略 - 從規劃到復原。

做出選擇

資料庫備份不僅僅是另一個備份任務——它是一個專業學科，需要理解資料庫內部機制、交易處理和一致性要求。但更重要的是，它是關於風險、價值和資源分配的業務決策。

首先理解您資料庫的特定備份功能和要求。但首先，要理解您資料的業務價值以及遺失成本與保護成本的對比。實施適合您資料庫平台和業務需求的交易一致性備份方法。

記住：資料庫備份是您關鍵資料業務連續性的保證。正確實施時，它們提供信心，讓您最寶貴的資產——您的資料——能夠度過任何災難。實施不當時，它們提供虛假的安全感。對於低價值資料完全跳過時，它們代表明智的資源分配。

設計您的資料庫備份策略時，要像設計資料庫一樣精心，但始終通過業務價值和風險管理的視角。您未來的自己——和您的業務——會感謝您。

有關資料庫以外的更全面備份策略，請參閱資料備份策略 - 從規劃到復原。

分享到