讀資料保護：工作負載的可恢復性05備份級別

躺柒發表於2024-12-06
負載

1. 恢復測試

1.1. 所有的備份都必須經過測試

  • 1.1.1. 沒有經過測試的備份不算真正的備份

1.2. 資料製作備份的唯一理由就在於以後想要從備份中恢復這些資料

1.3. 能不能把備份所保護的資料恢復出來，唯一的辦法就是對備份做測試

  • 1.3.1. 常規的（或者說，例行的）恢復測試應該是其中很重要的一個部分

  • 1.3.2. 要測試備份系統及其文件是否有效，我們還必須安排常規的恢復測試，以此來培訓員工

1.4. 對自己所負責的全部資料都定期執行恢復測試

  • 1.4.1. 每種資料的測試頻率應該根據這種資料多長時間恢復一次來決定

1.5. 雲平臺能夠簡化各種測試工作

  • 1.5.1. 不用擔心這些測試之間會爭著把資料恢復到同一套資源上

  • 1.5.2. 在雲平臺裡把每種測試所針對的資源配置好，這樣就可以讓這些測試都把資料恢復到各自所針對的資源上

  • 1.5.3. 應該把SaaS裡常見的一些東西也恢復出來

  • 1.5.3.1. 使用者

  • 1.5.3.2. 資料夾

  • 1.5.3.3. 單個的檔案

  • 1.5.3.4. 電子郵件

2. 備份級別

2.1. 完全備份(full backup)

  • 2.1.1. 將所有東西都備份下來

  • 2.1.2. 傳統意義上的完全備份會把有待保護的系統裡（除了你明確排除掉的那些東西之外）的所有東西，全都備份到備份伺服器中

  • 2.1.3. 檔案系統裡的所有檔案或資料庫裡的所有記錄，都在備份範圍之內

  • 2.1.3.1. 前者屬於非結構化資料(unstructured data)

  • 2.1.3.2. 後者屬於結構化資料(structured data)

2.2. 增量備份(incremental backup)

  • 2.2.1. 只把變化的內容備份下來

  • 2.2.1.1. 傳統意義上的增量備份會把檔案系統裡自上次備份以來發生變化的所有檔案，或者資料庫裡自上次備份以來發生變化的所有記錄都備份下來

  • 2.2.1.2. 不同的備份產品在運用這幾類增量備份時所採用的術語，可能也有所區別

  • 2.2.2. 全檔案式的增量備份（full-file incremental backup，也稱整檔案式的增量備份）​

  • 2.2.2.1. 只要某檔案的修改日期跟上次備份時不同，或它在Windows系統裡的存檔位（archive bit，也叫檔案位、封存位）標註為開啟，那麼該檔案就會納入這次備份的範圍

  • 2.2.2.2. 只有兩種增量備份不是這麼運作的，也就是塊級別的增量備份以及原資料端的去重備份

  • 2.2.3. 標準的增量備份

  • 2.2.3.1. 標準的增量備份（typical incremental backup，也叫典型的增量備份）是把從上次備份算起發生變化的所有資料全都備份下來，無論上次做的是哪種型別的備份，都這樣處理

  • 2.2.3.2. 如果你做的是標準的增量備份，那必須把當前這個標準增量備份與最近一次完全備份之間的所有標準增量備份全拿出來，才能夠恢復資料

  • 2.2.4. 積累式的增量備份

  • 2.2.4.1. 積累式的增量備份（cumulative incremental backup，又叫累進的增量備份）是把從上次做完全備份時算起發生變化的所有資料全都備份下來

  • 2.2.4.2. 只需要拿出最近一次的積累式增量備份以及它所依據的那個完全備份，就可以把所有資料全都恢復出來

  • 2.2.4.3. 若是將備份放到磁碟上，那麼積累式的增量備份所具備的優勢，就體現不出來了

  • 2.2.5. 帶有層次的增量備份

  • 2.2.5.1. 利用層次或級別(level)這一概念來覆蓋前面某段時間內所發生的變化，它用0級備份來表示完全備份，用1至9級來表示增量備份

  • 2.2.5.2. 每一級的增量備份都會把從上一個級別低於它的備份算起發生變化的所有資料全都涵蓋進來

  • 2.2.5.3. 漢諾塔(Tower Of Hanoi, TOH)式的增量備份方案

  • 2.2.6. 塊級別的增量備份

  • 2.2.6.1. 塊級別的增量備份(block-level incremental backup)只會把自上次備份以來發生變化的位元組或塊備份進來

  • 2.2.6.2. 關注的是發生變化的位元組或塊，它會用一種機制來判定，有哪些位元組、位元組段或塊在上次製作備份之後發生了變化，從而需要納入增量備份之中

  • 2.2.6.3. 備份方式所要執行的I/O數量以及所需的頻寬，要比全檔案式的增量備份小得多

  • 2.2.6.4. 最為常見的用途是備份虛擬機器管理器

>  2.2.6.4.1. 點陣圖(bitmap)的結構，裡面記錄著從某個時間點算起發生變化的全部二進位制位

  • 2.2.7. 源資料端的重複資料刪除

  • 2.2.7.1. 源資料端的重複資料刪除(source-side deduplication)簡稱源端去重，其中的“源”字是為了強調這種去重應用於源(source)資料，而非目標(target)資料

  • 2.2.8. 合成式的完全備份

  • 2.2.8.1. 製作完全備份的頻率越高，恢復起來就越快，因為這會縮短處理增量備份所花的時間

  • 2.2.8.2. 透過複製製作合成式的完全備份

>  2.2.8.2.1. 不會影響備份客戶端，也就是說，你要備份的那個伺服器或虛擬機器，根本不會在合成備份的過程中受到影響，因此，無論什麼時候都可以做這樣的備份

>  2.2.8.2.2. 複製資料的過程很耗時間

>  2.2.8.2.3. 會對備份的來源系統與目標系統之中的磁碟，做出大量的I/O操作
  • 2.2.8.3. 透過目標去重裝置來模擬合成式的完全備份
>  2.2.8.3.1. 其間不需要移動資料，因此效率相當高，只不過這種辦法可能僅適用於備份特定型別的資料

>  2.2.8.3.2. 虛擬機器、檔案系統，以及某些受支援的資料庫
  • 2.2.8.4. 從剛開始就一直做增量備份
>  2.2.8.4.1. 你的備份軟體應該將每個物件都分開存放，即便是最小的物件

2.3. 月初做一次完全備份，每天做一次標準的增量備份，每週做一次積累式的增量備份

  • 2.3.1. 切換磁帶所浪費的時間從45min縮短到12min

2.4. Windows系統的存檔位

  • 2.4.1. 存檔位（archive bit，也叫檔案位、封存位）是Windows系統給檔案設計的一個標誌

3. 資料保護系統的各項指標

3.1. 與恢復有關的指標

  • 3.1.1. RTO

  • 3.1.1.1. 看它恢復資料需要多長時間

  • 3.1.1.2. RTO（Recovery Time Objective，恢復時間目標/目標恢復時間）是各方都同意的一個時長，用來表示系統在遇到事故之後，需要花多長時間才能恢復

  • 3.1.1.3. 不一定非得要求整個組織都採用同一個RTO

  • 3.1.1.4. RTO是一專案標，這與資料保護系統的實際恢復時間(RTA)是有區別的

  • 3.1.2. RPO

  • 3.1.2.1. 看恢復之後損失了多少資料

  • 3.1.2.2. RPO（Recovery Point Objective，恢復點目標/目標恢復點）是指遇到大型事件之後，本組織最多能允許多長時間內的資料遭受損失

  • 3.1.3. RTA與RPA

  • 3.1.3.1. RTA（實際恢復時間）與RPA（實際恢復點）這兩項指標只有在執行恢復時才能測量出來，這可以指真正的恢復，也可以指為了測試而做的資料恢復

  • 3.1.3.2. RTA與RPA則用來表示受測系統能夠在多大程度上滿足這兩專案標

  • 3.1.4. 如果不做恢復測試，就無法瞭解備份系統是否可靠，也無法瞭解執行大規模的資料恢復到底需要哪些資源，以及這種恢復工作對環境中的其餘部分會提出哪些要求

  • 3.1.4.1. 唯一的辦法就是做恢復測試

3.2. 與系統的能力或容量有關的指標

  • 3.2.1. 系統對授權與工作負載的使用量

  • 3.2.2. 總的儲存容量與已使用的容量

  • 3.2.2.1. 如果不監控儲存裝置的總容量以及系統當前已使用的容量，那你就有可能遇到必須做出緊急決定的情況，而你在這種情況下所做的選擇，可能會違背本組織的備份策略

  • 3.2.3. 資料處理速度

  • 3.2.3.1. 備份系統每天能夠接受的備份量通常有一定限度，我們一般用每秒多少MB或每小時多少TB來表示

  • 3.2.3.2. 一定要監控系統的資料處理速度與磁帶驅動器的資料處理速度，這是相當重要的

  • 3.2.3.3. 雲平臺的優點在於，如果你使用的這個雲端產品或雲端服務能夠根據使用情況自動調整其頻寬，那麼它的資料處理速度就幾乎不受限制

>  3.2.3.3.1. 主站的頻寬並不是無限的，而且每天也只有24個小時，因此主站與雲平臺之間的傳輸總量有一定限制

  • 3.2.4. 計算能力

  • 3.2.4.1. 雲平臺中的許多備份系統與備份服務所使用的軟體，與執行在資料中心裡的備份產品相同

3.3. 備份視窗

  • 3.3.1. 備份視窗（backup window，或稱備份時段）​

  • 3.3.2. 傳統的備份系統在備份期間會大幅影響主系統的效能

  • 3.3.3. 完全備份是要把所有東西都備份下來，因此給主系統帶來的負擔當然會比較大

  • 3.3.4. 做增量備份，如果用的是全檔案式的增量備份，那麼依然會讓主系統承受壓力

  • 3.3.4.1. 即便檔案裡只有一個位元組發生變化，備份系統也還是要把整個檔案都備份下來

3.4. 備份與恢復的成功率與失敗率

  • 3.4.1. 把執行備份與恢復的次數記錄下來，並計算出各自的成功率

3.5. 保留策略

  • 3.5.1. 是備份系統與檔案系統裡一個特別重要的東西

  • 3.5.2. 確保備份系統確實能夠按照預定的保留策略來保留資料

  • 3.5.3. 資料保護系統的保留期也應該由組織來決定

  • 3.5.3.1. 備份或檔案保留多久，不應該由IT部門裡的某個人決定，而是應該根據法律與監管方面的要求以及本組織的需求來決定

  • 3.5.3.2. 確定保留策略之後，你還應該看看資料保護系統有沒有遵守本組織的總策略

  • 3.5.4. 備份資料在每一級儲存介質上應該保留多久

  • 3.5.5. 在設定保留期時還應該說明備份資料在每一種介質上保留多久

  • 3.5.6. 被遺忘權

  • 3.5.6.1. Right To Be Forgotten, RTBF

  • 3.5.6.2. 擦除權(right to erasure)

  • 3.5.6.3. 備份系統是用來記住資料的，但我們現在可能得讓它把某些東西忘掉

相關文章