容量層（或我們在 Vim 中稱之為 - captir）早在 Veeam Backup and Replication 9.5 Update 4 時代就出現了，名稱為 Archive Tier。 背後的想法是能夠將超出所謂的操作恢復視窗的備份移至物件儲存。 這有助於為那些磁碟空間很少的使用者清理磁碟空間。 這個選項稱為移動模式。
要執行這個簡單（看起來）的操作，滿足兩個條件就足夠了：移動備份中的所有點都必須位於上述操作復原視窗的邊界之外，該視窗是在 UI 中明確設定的。 第二：鏈必須是所謂的「密封形式」（密封備份鍊或非活動備份鏈）。 也就是說，隨著時間的推移，這條鏈不會有任何變化。
但在 VBR v10 中，這個概念補充了新的功能——複製模式、密封模式以及一個名字很難發音的東西——不變性。
這些是我們今天要討論的有趣的事情。 首先介紹一下它在VBR9.5u4中是如何運作的，然後介紹第十個版本中的變化。
願純語言的擁護者原諒我，但有太多術語無法翻譯。
所以這裡會有大量的英國語。
還有很多動圖。
還有圖片。
- 沒有絲毫的遺憾。 文章作者。
一如既往
好吧，讓我們先分析操作復原視窗和密封備份（或如非活動備份鏈文件中所稱的）。 如果沒有他們的理解，進一步的解釋是不可能的。
如圖所示，我們有一個帶有資料塊的備份鏈，它位於容量層所連接的儲存庫的效能層 SOBR 上。 我們的營運備份窗口為三天。
因此，週一創建的 .vbk 密封了前一個鏈，其視窗設定為三天。 這意味著您可以安全地開始將三天前的所有物品運送到射擊場。
但密封鏈到底意味著什麼？更新 4 中可以將什麼送到容量射擊場？
對於前向增量，密封鏈的標誌是建立新的完整備份。 如何獲得此完整備份並不重要：合成完整備份和活動完整備份都會被考慮。
在反向的情況下，這些都是不屬於操作視窗的檔案。
在前向增量和回滾的情況下，這些都是回滾和.vbk，如果性能範圍上還有另一個.vbk
現在讓我們考慮使用備份副本鏈的選項。 只有屬於政府飛行服務隊扣留的物品才會被運送到這裡。 因為儲存在更新的備份副本鏈中的所有內容都可以以一種或另一種方式變更。
現在讓我們看看幕後。 在那裡，會發生一個稱為脫水的過程 - 在範圍內留下空備份文件，並將這些文件中的區塊拖曳到容量拍攝範圍。 為了優化這個過程，使用了所謂的脫水指數，它可以讓您避免複製已經複製到容量拍攝範圍的區塊。
讓我們透過一個例子來看看這是什麼樣的：假設我們有一個來自交易窗口的 .vbk，並且屬於一條密封鏈。 這意味著我們完全有權將其移至容量射擊場。 移動時，會在傳輸檔案的容量破折號和區塊中建立元資料檔案。 連結級元資料檔案描述了我們的檔案由哪些區塊組成。 在圖中的情況下，我們的第一個檔案由區塊 a、b、c 組成，元資料包含這些區塊的連結。 當我們有第二個 .vbk 文件，準備移動並由區塊 a、b 和 d 組成時，我們透過分析脫水指數，了解到只有區塊 d 需要傳輸。 其元數據檔案將包含指向兩個先前區塊和一個新區塊的連結。
因此，用資料填滿這些空白空間的過程稱為補水。 它已經使用自己的補水索引，該索引基於本地效能範圍上最舊的 .vbk 檔案。 也就是說，如果用戶想要從容量射擊場返回文件，我們首先創建最舊的完整備份的塊的索引，並僅從容量射擊場傳輸丟失的塊。 在圖中所示的情況下，為了根據補水指數對FullBackup1.vbk進行補水，我們只需要從容量拍攝範圍中取得的區塊C。 如果儲存雲物件充當容量射擊場，這可以讓您節省大量資金。
在這裡，這項技術可能看起來與 WAN 加速器中使用的技術相同，但實際上只是看起來如此。 在加速器中，重複資料刪除是全域性的；這裡，本地重複資料刪除在每個檔案內的特定偏移處使用。 發生這種情況是由於要解決的任務不同：這裡我們需要複製大型完整備份文件，根據我們的研究，即使它們之間經過很長一段時間，這種重複資料刪除演算法也會給出最佳結果。
但索引之神還有更多索引！ 還有資料恢復的索引！ 當我們開始恢復位於容量儀表板中的電腦時，我們將只讀取不在效能儀表板中的唯一資料區塊。
它是怎麼發生的
這就是介紹部分的全部內容。 它非常詳細，但如上所述，如果沒有這些細節，就無法解釋新功能是如何運作的。 因此，事不宜遲，讓我們繼續第一個。
複製方式
它很大程度上基於現有技術，但具有完全不同的使用邏輯。
此模式的目的是確保位於本地盤區的所有資料在容量破折號中都有一個副本。
如果正面比較「移動」和「複製」模式，結果將如下所示：
- 只有密封的鏈條才能移動。 在複製模式的情況下，無論備份作業中發生什麼，絕對都會傳輸所有內容。
- 當檔案超出操作備份視窗的邊界時會觸發移動，一旦備份檔案出現就會觸發複製。
- 不斷監控新資料的複製情況，並每 4 小時觸發一次移動資料。
在考慮新模式時，我建議從簡單的範例轉向複雜的範例。
在最常見的情況下，我們只需擁有帶有增量的新文件，然後將它們複製到容量拍攝範圍即可。 無論備份作業採用什麼模式，無論是否屬於鏈上的密封部分，無論我們的操作視窗是否已過期。 他們只是拿走了它並複製了它。
這背後的過程仍然是如上所述的脫水。 在複製模式下，它還確保我們不會複製儲存中已有的區塊。 唯一的區別是，如果在電影模式下我們用虛擬文件替換真實文件，這裡我們不會以任何方式接觸它們並保持一切不變。 否則，它是完全相同的脫水指數，它仔細地試圖節省您的金錢和時間。
問題出現了 - 如果您查看使用者介面，您有機會同時選擇這兩個選項。 這種組合模式將如何運作？
讓我們弄明白。
開始是標準的：立即建立並複製備份檔案。 為其建立並複製增量。 這種情況會一直發生，直到我們意識到檔案已經離開我們的操作視窗並且出現一條密封鏈的那一刻。 此時我們執行脫水操作並將這些檔案替換為虛擬檔案。 當然，我們不會再向容量射擊場複製任何東西。
所有這些令人著迷的邏輯只負責介面中的一個複選框：創建備份後立即將其複製到物件儲存。
為什麼我們需要這種複製模式？
最好這樣重新表達這個問題：在它的幫助下我們可以免於哪些風險？ 它能幫助我們解決什麼問題？
答案很明顯：當然，這就是資料恢復。 如果我們在物件儲存上擁有本地資料的完整副本，那麼無論我們的產品發生什麼情況，我們始終可以從位於條件亞馬遜的檔案中復原資料。
因此，讓我們從最簡單到最複雜的順序來看看可能的情況。
落在我們頭上的最簡單的不幸就是備份鏈中的檔案之一無法存取。
一個更悲傷的故事是我們的 SOBR 儲存庫的一個範圍損壞了。
當整個 SOBR 存儲庫無法存取但容量射擊場仍在運行時，情況會變得更糟。
一切都非常糟糕 - 當備份伺服器死掉時，你的第一個願望就是嘗試在十分鐘內跑到加拿大邊境。
現在讓我們分別看看每種情況。
當我們遺失一個（甚至多個）備份檔案時，我們所需要做的就是啟動儲存庫重新掃描過程，遺失的檔案將被替換為虛擬檔案。 並且使用再水化過程（在文章開頭討論過），用戶將能夠將資料從容量射擊場下載到本地儲存。
現在情況更加複雜了。 假設我們的 SOBR 由在效能模式下運行的兩個擴展組成，這意味著我們的 .vbk 和 .vib 分佈在它們上相當不均勻的層中。 而在某個時間點，其中一個盤區不可用，使用者迫切需要恢復機器，而該機器的部分資料正是位於該盤區上。
使用者啟動恢復嚮導，選擇他想要恢復的點，嚮導在工作時發現他本地沒有恢復所需的所有數據，因此需要從容量拍攝下載畫廊。 同時，保留在本機儲存上的區塊將不會從雲端下載。 榮耀恢復索引（是的，文章開頭也提到過）。
這種情況的一個子類型是整個 SOBR 儲存庫變得無法存取。 在這種情況下，我們沒有任何東西可以從本地儲存複製，所有區塊都是從雲端下載的。
而最有趣的情況是備份伺服器掛掉了。 這裡有兩個選擇：管理員是偉大的並且進行了配置備份，管理員是邪惡的匹諾曹本人並且沒有進行配置備份。
在第一種情況下，他只需在某處部署全新安裝的 VBR 並使用標準方法從備份還原其資料庫就足夠了。 在這個過程結束時，一切都會恢復正常。 或依照上述情況之一恢復。
但是，如果管理員要么是他自己的敵人，要么配置備份也遭受了史詩般的失敗，那麼即使在這裡我們也不會讓他聽天由命。 對於這種情況，我們引入了一個稱為導入物件儲存的新流程。 它允許您跳過手動重新建立 SOBR 儲存庫並在後續重新掃描時為其附加容量射擊範圍的過程，只需將儲存物件新增至 Vim 介面並執行「匯入儲存庫」程式即可。 如果您的備份已加密，那麼唯一可能妨礙您和您的備份的是輸入密碼的請求。
這可能是關於複製模式的全部內容，我們繼續討論
密封模式
主要想法是新備份不能出現在儲存庫的選定 SOBR 範圍上。 在 v10 之前，我們只有維護模式，完全禁止對儲存庫進行任何操作。 一種用於關閉儲存的硬核模式，其中只有「Evacuate」按鈕可用，該按鈕一次將備份傳輸到另一個範圍。
而密封模式是一種「軟」選項：我們禁止建立新的備份，並根據選擇的保留逐步刪除舊的備份，但在此過程中我們不會失去從儲存點復原的能力。 當我們有一個硬體接近其使用壽命並需要更換它，或者我們只是需要將其釋放以用於更重要的事情，但沒有地方可以立即移動所有東西時，這是非常有用的。 不然無法刪除。
因此，操作原理非常簡單：需要禁止所有寫入操作（新資料的出現），保留讀取（復原）和刪除（保留）。
兩種模式可以同時使用，但請記住維護具有更高的優先權。
作為範例，請考慮由兩個範圍組成的 SOBR。 假設前四天我們以Forward Forever Incremental模式建立了備份，然後我們密封了extent，這導致我們在第二個可用extent上建立一個新的活動完整資料。 如果我們的保留是四，那麼當位於密封範圍內的整個鏈超出其限度時，就心安理得地刪除它。
在某些情況下，刪除會提前發生。 例如，這是具有週期性滿的正向增量。 如果我們在前兩天創建了完整備份，並且在星期四我們決定密封儲存庫，那麼在星期五建立新備份時，星期一的檔案將被刪除，因為到目前為止沒有任何依賴關係。 而這一點本身並不取決於任何人。 然後，我們等到可用範圍上建立了四個點，然後刪除剩餘的三個點，這三個點不能單獨刪除。
使用反向增量，事情變得更簡單。 其中，最舊的點不依賴任何東西，可以安全地刪除。 因此，一旦在新盤區上建立了新的.vbk，舊的.vrbs就會被一一刪除。
順便說一句，為什麼我們每次都要創建一個新的.vbk：如果我們不創建它，而是繼續舊的增量鏈，那麼舊的.vbk 在任何模式下都會凍結無限長的時間，從而阻止其刪除。 因此，決定一旦範圍被密封，我們就在空閒範圍上建立完整備份。
由於射擊場的容量，事情變得更加複雜。
我們先來看看複製模式。 假設我們積極創建了四天的備份，然後容量射擊場被封閉。 我們不會刪除任何東西，而是謙虛地忍受保留，然後我們將資料從容量射擊範圍中刪除。
在移動模式下，大約會發生同樣的事情 - 我們等待修飾，刪除本地儲存中的舊內容，並刪除儲存在物件儲存中的內容。
一個有趣的例子，永遠向前增量。 我們在三個點安裝保留，並在周一開始進行備份，並定期將其複製到雲端。 密封儲存後，繼續建立備份，維持三個點，但儲存在容量破折號中的資料仍然存在依賴性，無法刪除。 因此，我們等到週四，當我們的 .vbk 超出保留範圍時，我們才會平靜地刪除整個保存的鏈。
還有一個小小的免責聲明：這裡的所有範例都是在一台機器上顯示的。 如果您的備份中有多個，那麼它們的修飾將根據是否製作了 Active Full 而有所不同。
這基本上就是全部了。 那麼讓我們繼續討論最核心的功能 -
不變性
和前面幾點一樣，首先是這個函數要解決什麼問題。 一旦我們將備份上傳到某個地方進行存儲，就有強烈的願望來保證它們的安全，即在給定的保留期間物理上禁止它們的刪除和任何修改。 包括管理員，包括他們的根帳戶。 這可以讓您保護它們免受意外或故意損壞。 任何使用 AWS 的人都可能遇到類似的功能，稱為物件鎖定。
現在讓我們大致了解一下該模式，然後再深入研究細節。 在我們的範例中，將為我們的容量射擊場啟用不變性，保留四天。 並且在備份中啟用複製模式。
不變性不會以任何方式與一般保留相互作用。 例如，它不會添加額外的積分或類似的東西。 只是一個人不能在四天內刪除備份檔案。 如果您在星期一進行備份，則只能在星期五刪除其檔案。
所有先前解釋的脫水、索引和元資料的概念仍然完全相同。 但有一個條件 - 該區塊不僅是為資料設定的，也是為元資料設定的。 這樣做是為了防止狡猾的攻擊者決定擦除我們的元資料資料庫並防止資料區塊變成無用的二進制糊狀。
現在是解釋我們的區塊生成技術的好時機。 或者區塊生成。 為此，請考慮導致其出現的情況。
讓我們以六天為時間尺度，以下我們將標記不變性的預期到期時間。 第一天，我們取得並建立一個由資料區塊 a 及其元資料組成的檔案。 如果不變性設定為三天，則可以合理地假設資料將在第四天解鎖並刪除。 第二天，我們將新增一個新檔案 2，其中包含具有相同設定的區塊 b。 第四天，A塊仍然需要移除。 但在第三天，可怕的事情發生了——創建了一個 File3 文件，其中包含一個新區塊 d 和一個到舊區塊 a 的連結。 這意味著對於一個區塊及其不變性標誌必須重置為新日期，即轉移到第六天。 這裡出現了一個問題 - 在實際備份中存在大量此類區塊。 並且為了延長它們的不變性期限，您需要每次發出大量請求。 事實上，這將是一個幾乎無休止的日常過程，因為我們很可能會在每個副本中找到大量的重複資料刪除區塊。 來自物件儲存提供者的大量請求意味著什麼？ 正確的！ 月底帳單巨額。
為了不讓你最喜歡的客戶突然暴露並獲取大量金錢，區塊生成機制被發明了。 這是我們新增到設定的不變性期限中的額外期限。 在下面的範例中，該時間段為兩天。 但這只是一個例子。 事實上，他們使用自己的公式，在每月鎖定期間額外提供約十天的時間。
讓我們繼續考慮相同的情況，但涉及區塊生成。 第一天，我們從區塊 a 和元資料建立 file1。 我們將生成週期和不變性加起來 - 這意味著刪除檔案的機會將在第六天。 如果第二天我們建立 File2，其中包含區塊 b 和區塊 a 的鏈接，那麼預期刪除日期不會發生任何情況。 她像第六天那樣站著。 因此，我們試圖在請求數量上節省金錢。 唯一可以改變截止日期的情況是生成期限已過。 也就是說，如果在第三天新的 File3 包含阻止 a 的鏈接，則將添加第 2 代，因為第 1 代已經過期。 並且預計刪除a塊的日期將移至第八天。 這使我們能夠大幅減少請求數量，以延長重複資料刪除區塊的生命週期，從而為客戶節省大量資金。
該技術本身可供 S3 和 S3 相容硬體的用戶使用，其製造商保證其實施與亞馬遜的實施沒有不同。 因此，為什麼不支持 Azure 的合理問題的答案是——它們具有類似的功能，但它在容器層級而不是單一物件層級工作。 順便說一句，亞馬遜本身有兩種模式的物件鎖定：合規性和治理。 在第二種情況下，儘管有物件鎖定，仍然存在以下可能性：管理員之上的最高管理員和根之上的root，仍然刪除資料。 在合規的情況下，一切都釘牢了，任何人都不能刪除備份。 甚至亞馬遜管理員（根據他們的官方聲明）。 這是我們支持的模式。
像往常一樣，還有一些有用的連結：
- Про 在每一個細節。
- 有關的所有信息 處於最佳狀態
- О 詳細
來源： www.habr.com