為什麼需要進行備份？ 畢竟，設備非常非常可靠，而且還有比實體伺服器可靠性更好的「雲端」：透過正確的配置，「雲端」伺服器可以輕鬆地在基礎設施實體伺服器發生故障時繼續存在，並且從從服務用戶的角度來看，服務時間會有一個微小的、幾乎察覺不到的跳躍。 此外，資訊重複通常需要付出「額外」的處理器時間、磁碟負載和網路流量的代價。
理想的程式運行速度快、不洩漏記憶體、沒有漏洞、不存在。
-未知
由於程式仍然是由蛋白質開發人員編寫的，並且通常沒有測試過程，而且程式很少使用「最佳實踐」（它們本身也是程序，因此並不完美）來交付，因此系統管理員通常必須解決聽起來很簡單但實際上很簡單的問題。簡而言之：“恢復到原來的樣子”，“使基礎恢復正常運行”，“緩慢工作- 回滾”，還有我最喜歡的“我不知道是什麼，但修復它」。
除了由於開發人員粗心工作或綜合情況而產生的邏輯錯誤，以及對建構程式的小功能（包括連接和系統功能，包括作業系統、驅動程式和韌體）的不完整了解或誤解 -還有其他錯誤。 例如，大多數開發人員依賴執行時，完全忘記了物理定律，而這些物理定律仍然無法使用程式來規避。 這包括磁碟子系統以及一般情況下任何資料儲存子系統（包括RAM 和處理器快取！）的無限可靠性，以及處理器上的零處理時間，以及在透過網路傳輸和在電腦上處理期間不存在錯誤。處理器和網路延遲，該延遲等於 0。您不應該忽視臭名昭著的最後期限，因為如果不及時滿足，將會出現比網路和磁碟操作的細微差別更嚴重的問題。
如何處理全面出現並影響有價值數據的問題？ 沒有什麼可以取代活著的開發人員，而且在不久的將來這也不是可能的事實。 另一方面，只有少數專案成功地充分證明該計劃將按預期工作，並且不一定可以將證據應用於其他類似的專案。 此外，此類證據需要花費大量時間並需要特殊技能和知識，考慮到最後期限，這實際上最大限度地減少了使用它們的可能性。 此外，我們還不知道如何使用超快速、便宜且無限可靠的技術來儲存、處理和傳輸資訊。 此類技術如果存在的話，也是以概念的形式出現的，或者最常見的是僅出現在科幻小說和電影中。
好的藝術家抄襲，偉大的藝術家偷竊。
-巴勃羅畢卡索。
最成功的解決方案和令人驚訝的簡單事情通常發生在乍看完全不相容的概念、技術、知識和科學領域相遇的地方。
例如，鳥類和飛機都有翅膀，但儘管功能相似 - 某些模式下的操作原理是相同的，並且以類似的方式解決技術問題：中空的骨骼、使用堅固且輕質的材料等 -結果雖然非常相似，但完全不同。 我們在技術中看到的最好的例子也很大程度上借鑒自大自然：船舶和潛艇的加壓艙與環節動物直接類比； 建立 raid 陣列並檢查資料完整性 - 複製 DNA 鏈； 以及成對的器官，不同器官的工作獨立於中樞神經系統（心臟自動化）和反射 - 互聯網上的自主系統。 當然，「正面」採取和應用現成的解決方案充滿了問題，但誰知道呢，也許沒有其他解決方案。
如果我知道你會跌倒在哪裡，我就會鋪上稻草！
——白俄羅斯民間諺語
這意味著備份副本對於想要執行以下操作的人來說至關重要：
- 能夠在最短的停機時間甚至根本沒有停機的情況下恢復系統的運行
- 大膽行動，因為一旦出現錯誤，總是有回滾的可能性
- 最大限度地減少故意資料損壞的後果
這是一個小理論
任何分類都是任意的。 大自然不分類。 我們分類是因為它對我們來說更方便。 我們也根據我們任意取得的數據進行分類。
——讓‧布魯勒
無論實體儲存方式如何，邏輯資料儲存都可以分為兩種存取該資料的方式：區塊和檔案。 這種劃分最近變得非常模糊，因為純粹的區塊以及純粹的文件邏輯儲存並不存在。 然而，為了簡單起見，我們假設它們存在。
區塊資料儲存意味著存在一個實體設備，其中資料被寫入某些固定部分（區塊）。 區塊是在某個位址存取的；每個區塊在設備內都有自己的位址。
備份通常是透過複製資料塊來進行的。 為了確保資料完整性，新區塊的記錄以及現有區塊的變更在複製時都會暫停。 如果我們用普通世界來類比，最接近的東西就是一個擁有相同編號單元的壁櫥。
基於邏輯設備原理的文件資料存儲接近於區塊存儲，並且往往組織在頂層。 重要的區別是儲存層次結構和人類可讀的名稱的存在。 抽像以檔案（命名資料區域）的形式分配，以及目錄（儲存描述和對其他檔案的存取的特殊檔案）。 文件可以提供附加元資料：創建時間、存取標誌等。 備份通常是這樣完成的：它們會尋找更改的文件，然後將它們複製到具有相同結構的另一個文件儲存中。 資料完整性通常是透過不寫入檔案來實現的。 文件元資料的備份方式相同。 最接近的類比是圖書館，其中有不同書籍的部分，並且還有一個包含人類可讀的書籍名稱的目錄。
最近，有時會描述另一種選擇，原則上文件資料儲存就是從該選擇開始的，並且具有相同的古老功能：物件資料儲存。
它與檔案儲存的不同之處在於它沒有超過一次的嵌套（平面方案），而且檔案名稱雖然是人類可讀的，但仍然更適合機器處理。 執行備份時，物件儲存通常與檔案儲存類似，但偶爾也有其他選擇。
— 有兩種類型的系統管理員，一種是不進行備份的系統管理員，另一種是已經進行備份的系統管理員。
- 其實分為三種：還有檢查備份是否可以恢復的。-未知
另外值得理解的是，資料備份過程本身是由程式執行的，因此它具有與任何其他程式相同的缺點。 消除（不是消除！）對人為因素以及功能的依賴 - 這些功能單獨使用不會產生很強的效果，但組合在一起可以產生明顯的效果 - 所謂的規則 3-2-1。 如何破解它有很多選擇，但我更喜歡以下解釋：必須存儲 3 組相同的數據，2 組必須以不同的格式存儲，1 組必須存儲在地理上遠程的存儲中。
儲存格式應該要理解如下：
- 如果對物理儲存方法有依賴性，我們會更改物理方法。
- 如果對邏輯儲存方法有依賴，我們就會改變邏輯方法。
為了達到3-2-1規則的最大效果，建議兩種方式都改變儲存格式。
從備份為其預期目的（恢復功能）做好準備的角度來看，「熱」備份和「冷」備份之間存在差異。 熱的與冷的只有一件事不同：它們可以立即使用，而冷的則需要一些額外的恢復步驟：解密、從存檔中提取等。
不要將熱副本和冷副本與線上副本和離線副本混淆，這意味著資料的物理隔離，實際上是備份方法分類的另一個標誌。 因此，離線副本（不直接連接到需要恢復的系統）可以是熱副本，也可以是冷副本（就恢復準備情況而言）。 線上副本可以直接在需要恢復的地方使用，大多數情況下是熱副本，但也有冷副本。
另外，不要忘記，建立備份副本的過程本身通常不會以建立備份副本結束，並且可能存在相當多的副本。 因此，有必要區分全備份，即全備份。 那些可以獨立於其他備份進行恢復的副本，以及差異（增量、差異、減量等）副本 - 那些無法獨立恢復並需要初步恢復一個或多個其他備份的副本。
差異增量備份是節省備份儲存空間的嘗試。 因此，只有與先前備份相比發生變化的資料才會寫入備份副本。
建立差異遞減備份的目的相同，但方式略有不同：建立完整備份副本，但實際上僅儲存新副本與前一個副本之間的差異。
另外，值得考慮儲存備份過程，它支援不儲存重複項。 因此，如果您在其上寫入完整備份，實際上只會寫入備份之間的差異，但恢復備份的過程將類似於從完整副本恢復並且完全透明。
Quis custodiet ipsos custodes？
（誰來保護守望者自己？ - lat。）
沒有備份副本是非常不愉快的，但如果看似做了備份副本，但恢復時卻發現無法恢復，那就更糟了，因為：
- 來源資料的完整性已受到損害。
- 備份儲存損壞。
- 恢復速度非常慢；您無法使用已部分恢復的資料。
正確建置的備份過程必須考慮到這些評論，尤其是前兩者。
可以透過多種方式保證來源資料的完整性。 最常用的是：a）在區塊層級建立檔案系統的快照，b）「凍結」檔案系統的狀態，c）具有版本儲存的特殊區塊設備，d）檔案的順序記錄或區塊。 也套用校驗和來確保資料在恢復期間得到驗證。
也可以使用校驗和來檢測儲存損壞。 另一種方法是使用專用設備或檔案系統，其中已記錄的資料無法更改，但可以添加新資料。
為了加速恢復，資料恢復使用多個進程進行恢復——前提是不存在慢速網路或慢速磁碟系統形式的瓶頸。 為了解決資料部分復原的情況，您可以將備份過程分解為相對較小的子任務，每個子任務都會單獨執行。 因此，可以在預測恢復時間的同時持續恢復效能。 這個問題通常出在組織層級（SLA）上，所以我們不會詳細討論這個問題。
香料專家不是在每道菜中添加香料的人，而是從不添加任何額外東西的人。
-在。 西尼亞夫斯基
系統管理員使用的軟體的做法可能會有所不同，但總的原則仍然是相同的，特別是：
- 強烈建議使用現成的解決方案。
- 程式應該按可預測的方式運行，即不應該有未記錄的功能或瓶頸。
- 設定每個程序應該非常簡單，您不必每次都閱讀手冊或備忘單。
- 如果可能的話，解決方案應該是通用的，因為伺服器的硬體特性可能存在很大差異。
有以下常用程式可用於從區塊裝置進行備份：
- dd，對於系統管理老手來說很熟悉，這也包括類似的程序（例如相同的 dd_rescue）。
- 某些檔案系統中內建的實用程序，用於建立檔案系統的轉儲。
- 雜食性公用事業； 例如部分克隆。
- 自己的（通常是專有的）決定； 例如，NortonGhost 及更高版本。
對於檔案系統，使用適用於區塊設備的方法可以部分解決備份問題，但可以使用以下方法更有效地解決該問題：
- Rsync，用於同步檔案系統狀態的通用程式和協定。
- 內建歸檔工具 (ZFS)。
- 第三方歸檔工具； 最受歡迎的代表是 tar。 還有其他的，例如 dar - 針對現代系統的 tar 的替代品。
值得單獨提及的是在創建備份副本時確保資料一致性的軟體工具。 最常用的選項是：
- 以唯讀模式（ReadOnly）掛載檔案系統，或凍結檔案系統（freeze）－此方法的適用性有限。
- 建立檔案系統或區塊設備（LVM、ZFS）狀態的快照。
- 使用第三方工具來組織印象，即使在某種原因無法提供前述要點的情況下（例如 hotcopy 等程式）。
- 然而，變更時複製技術 (CopyOnWrite) 通常與所使用的檔案系統（BTRFS、ZFS）相關。
因此，對於小型伺服器需要提供滿足以下要求的備份方案：
- 易於使用 - 操作過程中不需要特殊的額外步驟，創建和恢復副本的步驟最少。
- 通用 - 適用於大型和小型伺服器； 這在增加伺服器數量或擴展時很重要。
- 透過套件管理器安裝，或透過一兩個命令（例如「下載並解壓縮」）安裝。
- 穩定 - 使用標準或長期建立的儲存格式。
- 工作速度很快。
大致符合要求的申請人：
- rdiff-備份
- rsnapshot
- 飽嗝兒
- 複製
- 表裡不一
- 讓杜普
- 但
- 備份
- 雷斯蒂奇
- 博格備份
將使用具有以下特徵的虛擬機器（基於XenServer）作為測試平台：
- 4核2.5GHz，
- 16 GB 內存，
- 50 GB 混合式儲存（在 SSD 上快取虛擬磁碟大小 20% 的儲存系統），採用不分割的單獨虛擬磁碟形式，
- 200 Mbps 互聯網通道。
幾乎同一台機器將用作備份接收伺服器，僅配備 500 GB 硬碟。
作業系統 - Centos 7 x64：標準分割區，附加分割區將用作資料來源。
作為初始數據，我們採用一個包含 40 GB 媒體檔案和 mysql 資料庫的 WordPress 網站。 由於虛擬伺服器的特性差異很大，並且為了更好的再現性，這裡是
使用 sysbench 的伺服器測試結果。sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu 執行
sysbench 1.1.0-18a9f86（使用捆綁的 LuaJIT 2.1.0-beta3）
使用以下選項運行測試：
線程數：4
從當前時間初始化隨機數產生器
質數限制：20000
正在初始化工作線程...
線程開始了！
中央處理器速度：
每秒事件數：836.69
吞吐量：
事件/秒（eps）：836.6908
經過的時間：30.0039s
事件總數：25104
延遲（毫秒）：
分鐘：2.38
平均：4.78
最大值：22.39
第 95 百分位：10.46
總計：119923.64
線程公平性：
事件（平均/標準差）：6276.0000/13.91
執行時間（平均值/標準差）：29.9809/0.01
sysbench --threads=4 --time=30 --記憶體區塊大小=1K --記憶體範圍=全域 --記憶體總大小=100G --記憶體操作=讀取記憶體運行
sysbench 1.1.0-18a9f86（使用捆綁的 LuaJIT 2.1.0-beta3）
使用以下選項運行測試：
線程數：4
從當前時間初始化隨機數產生器
使用以下選項執行記憶體速度測試：
塊大小：1KiB
總大小：102400MiB
操作：讀取
範圍：全球
正在初始化工作線程...
線程開始了！
總操作數：50900446（每秒 1696677.10）
49707.47 MiB 傳輸（1656.91 MiB/秒）
吞吐量：
事件/秒（eps）：1696677.1017
經過的時間：30.0001s
事件總數：50900446
延遲（毫秒）：
分鐘：0.00
平均：0.00
最大值：24.01
第 95 百分位：0.00
總計：39106.74
線程公平性：
事件（平均/標準差）：12725111.5000/137775.15
執行時間（平均值/標準差）：9.7767/0.10
sysbench --threads=4 --time=30 --記憶體區塊大小=1K --記憶體範圍=全域 --記憶體總大小=100G --記憶體操作=寫記憶體運行
sysbench 1.1.0-18a9f86（使用捆綁的 LuaJIT 2.1.0-beta3）
使用以下選項運行測試：
線程數：4
從當前時間初始化隨機數產生器
使用以下選項執行記憶體速度測試：
塊大小：1KiB
總大小：102400MiB
操作：寫
範圍：全球
正在初始化工作線程...
線程開始了！
總操作數：35910413（每秒 1197008.62）
35068.76 MiB 傳輸（1168.95 MiB/秒）
吞吐量：
事件/秒（eps）：1197008.6179
經過的時間：30.0001s
事件總數：35910413
延遲（毫秒）：
分鐘：0.00
平均：0.00
最大值：16.90
第 95 百分位：0.00
總計：43604.83
線程公平性：
事件（平均/標準差）：8977603.2500/233905.84
執行時間（平均值/標準差）：10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio 運行
sysbench 1.1.0-18a9f86（使用捆綁的 LuaJIT 2.1.0-beta3）
使用以下選項運行測試：
線程數：4
從當前時間初始化隨機數產生器
額外的文件開啟標誌：（無）
128 個文件，每個 8MiB
文件總大小 1GiB
塊大小 4KiB
IO請求數：0
組合隨機 IO 測驗的讀/寫比率：1.50
啟用定期 FSYNC，每 100 個請求呼叫 fsync()。
測試結束時呼叫 fsync()，啟用。
使用同步I/O模式
進行隨機讀/寫測試
正在初始化工作線程...
線程開始了！
吞吐量：
讀取：IOPS=3868.21 15.11 MiB/秒（15.84 MB/秒）
寫入：IOPS=2578.83 10.07 MiB/秒（10.56 MB/秒）
同步：IOPS=8226.98
延遲（毫秒）：
分鐘：0.00
平均：0.27
最大值：18.01
第 95 百分位：1.08
總計：238469.45
這篇筆記開始了一個大的
有關備份的系列文章
- 備份，第 1 部分：為什麼需要備份，方法和技術概述
- 備份第 2 部分：審查和測試基於 rsync 的備份工具
- 備份第 3 部分：審查和測試口是心非、重複、似曾相識的重複
- 備份第 4 部分：審查和測試 zbackup、restic、borgbackup
- 備份第 5 部分：測試適用於 Linux 的 bacula 和 veeam 備份
- 備份第 6 部分：比較備份工具
- 備份第 7 部分：結論
來源： www.habr.com