向我們的部落格讀者問好！我們已經部分熟悉了 - 我的英文帖子出現在這裡，由我親愛的同事翻譯 。這次我決定直接向俄語觀眾講話。
對於我的首次亮相，我想找到一個盡可能廣泛的受眾感興趣並且需要詳細考慮的主題。丹尼爾·笛福認為，死亡和稅收等待著每個人。就我而言，我可以說任何支援工程師都會對恢復點儲存策略（或更簡單地說，保留）有疑問。四年前，作為一名初級初級工程師，我開始解釋如何保留人才，現在我已經作為西班牙語和義大利語團隊的領導者繼續解釋。我確信來自第二級甚至第三級支持的同事也會定期回答同樣的問題。
有鑑於此，我想寫一篇盡可能詳細的最終文章，供俄語用戶可以一次又一次地返回作為參考書。現在正是時候 - 最近發布的十週年紀念版在多年來未曾改變的基本功能上添加了新功能。我的帖子主要關注這個版本 - 儘管大部分內容都適用於以前的版本，但您根本找不到其中描述的一些功能。最後，展望未來，我會說下一個版本中預計會有一些變化，但我們會在時機成熟時告訴您。那麼就讓我們開始吧。
備份作業
首先我們來看看版本10中沒有改變的部分。保留策略是由幾個參數決定的。讓我們打開用於創建新任務的視窗並轉到“儲存”選項卡。在這裡我們將看到一個參數，該參數決定所需的還原點數量：
然而，這只是等式的一部分。實際點數也取決於為作業設定的備份模式。若要選擇此選項，請按一下相同標籤上的「進階」按鈕。這將開啟一個包含許多選項的新視窗。讓我們對它們進行編號並一一考慮：
如果僅啟用選項 1，作業將以「永遠向前增量」模式運作。這裡沒有困難 - 該任務將儲存從完整備份（具有 VBK 副檔名的檔案）到最後一個增量（具有 VIB 副檔名的檔案）的指定數量的還原點。當點數超過設定值時，最舊的增量將與完整備份合併。換句話說，如果任務設定為儲存 3 個點，那麼在下一個會話之後，儲存庫上將立即有 4 個點，之後完整備份將與最舊的增量合併，並且點總數將返回到3.
「反向增量」模式（選項2）的保留也非常簡單。由於在這種情況下，最新的點將是完整備份，然後是一系列所謂的回滾（具有 VRB 副檔名的檔案），因此要套用保留，只需刪除最舊的回溯就足夠了。情況也是一樣的：會話結束後，點數會超過設定值1，之後又會恢復到所需值。
請注意，使用反向增量模式，您也可以啟用定期完整備份（選項4），但這不會改變本質。是的，完整的復原點會出現在鏈中，但我們仍然會簡單地一一刪除最舊的點。
最後，我們來到了有趣的部分。如果您啟動增量備份，但另外啟用選項 3 或 4（或同時啟用兩者），任務將開始使用「主動」或合成方法建立定期完整備份。創建完整備份的方法並不重要——它將包含相同的數據，並且將增量鏈劃分為「子鏈」。這種方法稱為前向增量，正是這種方法向我們的客戶提出了很大一部分問題。
此處透過刪除鏈中最舊的部分（從完整備份到增量備份）來套用保留。同時，我們不會只刪除完整的備份或只刪除部分增量。整個“子鏈”立即被徹底刪除。設定點數的意思也會改變 - 如果在其他方法中這是最大允許數量，之後必須套用保留，那麼這裡此設定會決定最小數量。換句話說，刪除最舊的「子鏈」後，剩餘部分的點數不應低於這個最小值。
我將嘗試以圖形方式描述這個概念。假設保留設定為 3 個點，任務每天運行，並在周一進行完整備份。當總點數達到 10 時，將在這種情況下套用保留：
為什麼放了 10 個卻已經有 3 個了？週一創建了完整備份。從週二到週日，工作量不斷增加。最後，下週一再次建立全備份，只有創建了2個增量後，才能最終刪除整個鏈的舊部分，因為剩餘的點數不會低於設定的3。
如果想法很明確，那麼我建議你嘗試自己計算留存率。我們假設以下條件：週四首次啟動任務（自然會進行完整備份）。任務設定為每週三、週日建立全量備份，並儲存8個復原點。何時首次應用保留？
為了回答這個問題，我建議您拿一張紙，將其按一周中的每一天排列起來，並寫下每天創建的點。答案將變得顯而易見
回答
說明：要回答，只要問自己「何時應用保留」？答案是當我們可以刪除前 3 個點（VBK、VIB、VIB）並且鏈的其餘部分不低於所需的 8 個點時。很明顯，當我們總共得到11分時，也就是第二週的星期日，我們就能做到這一點。
有些讀者可能會反對：「如果有的話為什麼要做這一切？ ？。毫無疑問，這是一個非常有用的工具，在某些情況下我會使用它，但它也有其限制。首先，它不允許你指定初始條件，很多時候問題恰恰是“我們有這樣一條鏈，如果我們改變這樣那樣的設定會發生什麼？”其次，該工具仍有些不夠明確。向客戶展示 RPS 頁面，我沒有發現任何理解，但是按照示例中的方式繪製它（即使使用相同的 Paint），日復一日，一切都變得清晰了。
最後，我們沒有考慮「將先前的備份鏈轉換為回滾」選項（標記為數字5）。此選項有時會讓「自動」啟動它、只想啟用合成備份的客戶感到困惑。同時，此選項啟動一種非常特殊的備份模式。不說細節，我就直接說，在產品開發的現階段，「將先前的備份鏈改回回滾」已經是一個過時的選擇，我也想不出什麼場景應該使用它。它的價值是如此可疑，以至於有一段時間安東·戈斯特夫（Anton Gostev）本人通過論壇呼籲，要求向他發送其有用用途的示例（如果你有，請寫在評論中，我非常感興趣）。如果沒有（我認為會是這種情況），那麼該選項將在未來的版本中刪除。
此任務將建立增量 (VIB)，直到計劃合成完整備份的那一天為止。這一天，實際上創建了一個VBK，但這個VBK之前的所有點都轉換為回滾（VRB）。此後，任務將繼續建立完整備份的增量，直到下一次合成備份。結果，在鏈中創建了 VBK、VBR 和 VIB 檔案的爆炸性混合物。保留的應用非常簡單 - 透過刪除最後一個 VBR：
問題
除了實際了解其工作原理之外，使用增量模式時出現的大多數問題通常都與完整備份相關。此模式需要定期進行完整備份，否則儲存庫將累積積分直至滿。
例如，可能很少建立完整備份。假設任務設定為儲存 10 個點，每月建立一次完整備份。很明顯，這裡的實際點數將明顯大於顯示的點數。或任務一般設定為無限增量模式工作，儲存50個點。然後有人不小心創建了完整備份。就是這樣，從現在開始，任務將等待滿點累積 49 個增量，之後它將應用保留並返回到無限滿模式。
在其他情況下，設定為定期建立完整備份，但由於某種原因卻沒有。我將在這裡列出最受歡迎的原因。一些客戶端喜歡使用“run after”調度選項並將作業配置為在鏈中運行。讓我們舉個例子：有 3 個作業每天運行並在周日建立完整備份。第一個任務於22.30開始，其餘任務鍊式啟動。增量備份需要 10 分鐘，因此到 23.00:22.30 所有作業都完成工作。但完整備份需要一個小時，因此週日會發生以下情況：第一個任務從 23.30 運行到 23.30。接下來從 00.30 到 XNUMX。但第三項任務從週一開始。完整備份設定為週日，因此在這種情況下根本不會發生。該任務將等待完整備份來套用保留。因此，在使用“run after”選項時要小心，或者根本不使用它 - 只需將作業設為同時啟動，然後讓資源調度程序完成其工作即可。
困難的選項“刪除已刪除的項目”
完成任務「儲存」-「進階」-「維護」的設定後，您可以看到「刪除此後刪除的項目資料」選項，該選項可以按天計算。
一些客戶希望這能夠保留。事實上，這是一個完全獨立的選擇，誤解可能會導致意想不到的後果。然而，首先，我們需要解釋貝加萊如何應對會話期間只有少數電腦成功備份的情況。
讓我們想像一下這個場景：一個無限增量作業配置為儲存 6 個點。任務中有兩台機器，一台總是備份成功，另一台有時會出錯。結果到了第七點就出現了下面的情況：
是時候申請保留了，但一輛車有7分，另一輛車只有4分。這裡會申請保留嗎？答案是肯定的，會的。如果至少有一個物件已備份，貝加萊就會認為該點已建立。
如果在某個會話期間某些機器根本沒有包含在任務中，則可能會出現類似的情況。例如，當機器不是單獨添加到任務中，而是作為容器（資料夾、儲存）的一部分添加到任務中，並且某些機器暫時遷移到另一個容器時，就會發生這種情況。在這種情況下，任務就會被認為是成功的，但是在統計中你會發現一則訊息，要求你注意某某台機器不再被任務處理。
如果不注意這一點會發生什麼？在無限增量或反向增量模式的情況下，「問題」機器的恢復點數量會隨著每次會話而減少，直到達到1，儲存在VBK中。也就是說，即使機器很長時間沒有備份，仍然會保留一個復原點。如果啟用定期完整備份，情況會有所不同。如果您忽略來自貝加萊的訊號，最後一點可能最終會與鏈的舊部分一起被刪除。
了解這些細節後，您終於可以考慮「刪除之後刪除的項目資料」選項。如果特定機器 X 天沒有備份，它將刪除機器的所有點。請注意，此設定不會響應錯誤（嘗試過，但沒有成功）。甚至不應該嘗試備份機器。該選項似乎很有用，並且應該始終保持啟用。如果管理員將機器從任務中刪除，那麼一段時間後，清除不必要的資料鍊是合乎邏輯的。然而，定制需要紀律和謹慎。
我給大家舉一個實踐中的例子：任務中增加了幾個容器，其組成是相當動態的。由於缺乏 RAM，貝加萊伺服器遇到了未被發現的問題。該任務開始並嘗試對機器進行備份，但其中一台機器除外，該機器當時不存在於容器中。由於許多機器產生錯誤，因此預設情況下貝加萊應該再嘗試 3 次來備份「問題」機器。由於 RAM 不斷出現問題，這些嘗試持續了幾天。沒有重複嘗試對遺失的虛擬機器進行備份（缺少虛擬機器並不是錯誤）。結果，在其中一次重複嘗試中，滿足了「刪除已刪除的項目」條件，並且機器上的所有點都被刪除了。
對此，我可以這麼說：如果您設定了有關任務結果的通知，甚至更好的是，使用與 Veeam ONE 的集成，那麼很可能這種情況不會發生在您身上。如果您每週查看一次貝加萊伺服器以檢查一切是否正常，那麼最好拒絕可能導致備份刪除的選項。
v.10 中新增的內容
我們之前講的內容在貝加萊已經存在了許多版本。在了解了這些操作原理之後，我們現在來看看周年慶「十」新增了哪些內容。
每日保留率
上面我們研究了基於點數的「經典」儲存策略。另一種方法是在同一選單中設定“天”而不是“恢復點”。
從名稱中就可以清楚地看出這個想法 - 保留將儲存一定的天數，但每天的積分數量並不重要。在這種情況下，您需要記住以下幾點：
- 計算留存率時不考慮當天
- 任務根本不起作用的天數也被計算在內。應牢記這一點，以免意外失去那些不規則任務的分數。
- 恢復點從創建開始之日開始計算（即，如果任務在周一開始工作並在周二完成，則這是從週一開始的點）
否則，依任務使用保留的原則也由所選的備份方法決定。讓我們使用相同的增量方法來嘗試另一個計算任務。假設保留設定為 8 天，該任務每 6 小時運行一次，並在周三進行一次完整備份。然而，該任務在周日不起作用。該作業首次在周一運行。什麼時候會應用保留？
回答
一如既往，最好畫一個標誌。我將允許自己簡化任務，並且不會繪製每天創建的所有積分，因為每天的積分數量在這裡並不重要。對我們來說唯一重要的是，在第一個星期一和星期三，第一個點將是完整備份，但在剩餘的日子裡，任務將只建立 4 個增量點。
我們明確表示，保留將透過刪除週一的完整備份及其增量來應用。什麼時候會發生這種情況？當鏈的其餘部分包含 8 天。同時，我們不計算當天，相反，我們計算星期日。因此，答案是第二週的星期四。
常規作業的 GFS 歸檔
在 v.10 之前，祖父-父-子 (GFS) 儲存方法僅適用於備份複製作業和磁帶複製作業。現在可用於定期備份。
雖然這與當前主題無關，但我必須說，新功能並不意味著背離3-2-1策略。主儲存庫中存檔點的存在不會以任何方式影響其可靠性。據了解，GFS 將與 Scale-out 儲存庫結合使用，將這些點上傳到 S3 和類似儲存。如果您不使用它，那麼最好繼續將主點和歸檔點儲存在不同的儲存庫中。
現在我們來看看創建GFS點的原理。在任務設定的「儲存」步驟中，會出現一個特殊按鈕，可呼叫以下選單：
GFS 的本質可以歸結為幾點（請注意，GFS 在其他類型的任務中的工作方式有所不同，稍後會詳細介紹）：
- 此任務不會為 GFS 點建立單獨的完整備份。相反，將使用最合適的完整備份。因此，任務必須以增量模式工作並定期進行全量備份，或者必須由使用者手動建立全量備份。
- 如果僅啟用一個週期（例如一週），則在 GFS 週期開始時，任務將簡單地開始等待完整備份並將第一個適當的備份標記為 GFS。
範例：作業配置為使用週三的備份來儲存每週的 GFS。該任務每天運行，但計劃在周五進行完整備份。在這種情況下，GFS 週期將從週三開始，任務將開始等待合適的點。它將在周五出現，並標有 GFS 標誌。
- 如果同時包含多個週期（例如，每周和每月），則貝加萊將使用允許將同一點用作多個間隔的 GFS 的方法（以節省空間）。旗幟將從最小的開始按順序分配。
範例：每週 GFS 設定為星期三，每月 GFS 設定為該月的最後一周。該任務每天運行並在周一和周五創建完整備份。
為簡單起見，我們從該月的倒數第二週開始計數。本週將在周一創建完整備份，但該備份將被忽略，因為每週 GFS 間隔從週三開始。但周五的全備份完全適合GFS點。這個系統我們已經很熟悉了。
現在讓我們看看本月最後一周發生了什麼。每月的 GFS 間隔將從星期一開始，但星期一的 VBK 將不會標記為 GFS，因為作業旨在將一個 VBK 標記為每月和每週的 GFS 點。在這種情況下，搜尋從每週一次開始，因為根據定義，它也可以成為每月一次。
但是，如果僅包括每周和每年間隔，它們將彼此獨立運行，並且可以將 2 個單獨的 VBK 標記為相應的 GFS 間隔。
備份複製任務
另一種類型的任務通常需要對工作進行澄清。首先，讓我們來看看沒有創新的「經典」工作方法 v.10
簡單的保留方法
預設情況下，此類作業以無限增量模式運作。點的建立由兩個參數決定 - 複製間隔和所需的恢復點數量（此處沒有按天保留）。建立作業時，在第一個作業標籤上設定複印間隔：
點數在「目標」標籤上進一步確定
此任務為每個時間間隔建立 1 個新點（原始任務為 VM 創建了多少個點並不重要）。在間隔結束時，新點被最終確定，並且如有必要，透過組合 VBK 和最舊的增量來應用保留。這個機制我們已經很熟悉了。
使用 GFS 的保留方法
BCJ 還可以儲存存檔點。這是在同一「目標」標籤上配置的，位於恢復點數量設定的下方：
GFS 點可以透過兩種方式建立 - 綜合地使用輔助儲存庫上的數據，或透過模擬完整備份並從主儲存庫讀取所有資料（由標記為 3 的選項啟動）。兩種情況下的保留率會有很大不同，因此我們將分別考慮。
合成GFS
在這種情況下，GFS 點不會恰好在指定日期創建。相反，當計劃建立 GFS 點當天的 VIB 與完整備份合併時，將建立 GFS 點。這有時會引起誤解，因為時間過去了，仍然沒有 GFS 點。並且只有來自技術支援的強大薩滿才能預測該點將在哪一天出現。事實上，不需要魔法——只需查看設定的點數和同步間隔（每天創建多少個點）。試著用這個範例自己計算一下：任務設定為儲存7個點，同步間隔為12小時（即每天2個點）。目前，鏈上已有7個點，今天是周一，計劃在這一天創建GFS點。將於哪一天創建？
回答
這裡最好描述一下鏈條如何隨著時間的推移、日復一日地變化：
因此，在周一，鏈中的最後一個增量被標記為 GFS，但沒有其他可見的變化發生。每天該任務都會創造 2 個新點，而保留會無情地推動鏈條前進。最後，週四是時候將保留應用於該增量了。此會話將比平常花費更長的時間 - 因為任務將從鏈中「提取」必要的區塊並創建一個新的完整點。從這一刻起，鏈上已經有8個點－主鏈7個+GFS。
使用“讀取整個點”選項建立 GFS 點
上面我說了BCJ是以無限的增量模式運作。現在我們來看看這條規則的唯一例外。啟用「讀取整個點」選項後，GFS 點將在計畫的日期準確地建立。任務本身將以增量模式運行，並定期進行完整備份，我們上面已經討論過。也將透過刪除鏈中最舊的部分來應用保留。但是，在這種情況下，只會刪除增量，而完整備份將保留為 GFS 點。因此，在計算保留時，不會考慮標示為 GFS 標誌的點。
假設任務設定為儲存 7 個點並在週一建立每週 GFS 點。在這種情況下，每週一該任務實際上會建立完整備份並將其標記為 GFS。當從最舊的部分刪除增量後，剩餘增量的數量不低於 7 時，將應用保留。如下圖所示：
因此，到第二週結束時，鏈條上總共有 14 個點。第二週，任務創造了7分。如果這是一項簡單的任務，那麼就已經應用了保留。但這是一個有GFS保留的BCJ，所以我們不計算GFS點，也就是說只有6個，也就是說，我們還不能應用保留。在第三週，我們使用 GFS 標誌建立另一個完整備份。 15 分，但我們再次不計算這一點。最後，在第三週的星期二，我們建立了一個增量。現在，如果我們刪除第一週的環鏈增量，則增量總數將滿足既定的留存率。
如上所述，在這種方法中，定期建立完整備份非常重要。比方說，如果你設定主要保留期為7天，但只有1個年積分，很容易想像增量會累積很多很多，遠遠超過7。在這種情況下，最好使用創建的合成方法政府飛行服務隊。
再次“刪除已刪除的項目”
BCJ 也存在此選項：
這裡此選項的邏輯與常規備份任務中的邏輯相同 - 如果機器在指定的天數內未處理，則其資料將從鏈中刪除。然而，對於 BCJ 來說，該選項的實用性客觀上更高，原因如下。
在正常模式下，BCJ 以無限增量模式運行，因此如果在某個時刻從作業中刪除一台機器，則保留將逐漸刪除所有恢復點，直到只剩下一個恢復點 - 在 VBK 中。現在，我們假設該任務仍配置為建立合成 GFS 點。到時候，作業將必須為鏈中的所有機器建立一個 GFS。如果某台機器根本沒有新點，那麼，您就必須使用現有的機器。每次都是如此。結果，可能會出現以下情況：
請注意“文件”部分：我們有主要的 VBK 和 2 週 GFS 點。現在到恢復點部分 - 事實上，這些檔案包含相同的機器映像。當然，這樣的 GFS 點沒有任何意義，它們只是佔空間。
這種情況只有在使用合成 GFS 時才有可能出現。為了防止這種情況，請使用「刪除已刪除的項目」選項。只需記住將其設置為足夠的天數即可。技術支援發現該選項設定的天數少於同步間隔的情況 - BCJ 開始發狂並在創建點之前刪除點。
另請注意，此選項不會影響已建立的 GFS 點。如果您想要清理存檔，則需要手動執行此操作 - 右鍵單擊電腦並選擇“從磁碟刪除”（在出現的視窗中，不要忘記選中“刪除 GFS 完整備份”框） :
創新 v.10 – 立即複製
處理完「經典」功能後，讓我們繼續討論新功能。有一項創新，但非常重要。這是一種新的運作模式。
不存在所謂的「同步間隔」；任務將不斷監視是否出現新點並將其全部複製，無論有多少個。但同時，作業仍然是增量的，也就是說，即使主作業創建了VBK或VRB，這些點也會被複製為VIB。否則，在此模式下不會有任何意外 - 標準保留和 GFS 保留都根據上述規則進行工作（但是，此處僅提供合成 GFS）。
磁碟正在旋轉。具有旋轉驅動器的存儲庫的功能
勒索軟體病毒的持續威脅已使其成為事實上的安全標準，在病毒無法到達的媒體上保存資料副本。一種選擇是使用磁碟輪換儲存庫，一次使用一個磁碟：當一個磁碟連接且可寫入時，其餘磁碟儲存在安全位置。
要教導貝加萊使用此類儲存庫，您需要在儲存庫步驟中點擊儲存庫設定中的進階按鈕，然後選擇適當的選項：
此後，VBR 預計現有鏈會定期從儲存庫中消失，這意味著磁碟輪轉。根據儲存庫類型和作業類型，貝加萊的行為會有所不同。這可以用下表來表示：
讓我們考慮一下每個選項。
普通任務和 Windows 儲存庫
因此，我們有一個任務將鏈保存到第一個磁碟。在輪換期間，創建的鏈實際上消失了，任務需要以某種方式在這種損失中倖存下來。創建完整備份讓她感到安慰。因此，每次旋轉都意味著一次完整的備份。但是斷開連線的磁碟上的點會發生什麼事呢？在計算保留率時，它們會被記住並考慮在內。因此，任務中設定的點數就是需要在所有磁碟上保留多少個點。這是一個例子：
此作業以無限增量模式運行，並配置為儲存 3 個還原點。但我們還有第二個磁碟，我們每週輪換一次（可能會有更多磁碟，這不會改變本質）。
在第一周，任務將在第一個磁碟上建立點並合併多餘的點。因此，總點數將等於三：
然後我們連接第二個驅動器。啟動時，貝加萊會注意到磁碟已被更換。第一個磁碟上的鏈將從介面中消失，但有關它的資訊將保留在資料庫中。現在任務將在第二個圓盤上保留 3 個點。一般情況會是這樣的：
最後，我們重新連接第一個驅動器。在建立新點之前，任務將檢查保留發生的情況。我提醒你，保留度設定為儲存 3 點。同時，我們在磁碟 3 上有 2 個點（但它已斷開連接並儲存在 B&R 無法到達的安全位置），並且在磁碟 3 上有 1 個點（但此點已連接）。這意味著我們可以安全地從磁碟 3 中刪除 1 個點，因為它們超出了保留範圍。之後任務再次建立完整備份，我們的鏈開始如下所示：
如果保留配置為儲存天數而不是點數，則邏輯不會改變。此外，當使用磁碟輪轉的儲存庫時，根本不支援 GFS 保留。
常規作業和Linux儲存庫網路存儲
此選項也是可行的，但由於施加的限制，通常不建議這樣做。該任務將以相同的方式對磁碟旋轉和鏈消失做出反應 - 透過建立完整備份。此限制是由於切斷保留機製造成的。
這裡，在輪轉期間，斷開連接的磁碟上的整個鏈都會從貝加萊資料庫中刪除。請注意，從資料庫中，檔案本身保留在磁碟上。它們可以被導入並用於恢復，但很容易猜測這些被遺忘的鏈遲早會填滿整個存儲庫。
解決方案是新增 DWORD ForceDeleteBackupFiles，如此頁面所示： 。然後，作業將開始在每次輪調時簡單地刪除作業資料夾或儲存庫資料夾（取決於值）的全部內容。
然而，這並不是優雅的保留，而是對所有內容的清理。不幸的是，技術支援遇到這樣的情況：儲存庫只是磁碟的根目錄，除了備份之外，還存放其他資料。這一切都在旋轉過程中被破壞了。
此外，啟用 ForceDeleteBackupFiles 後，它適用於所有類型的儲存庫，也就是說，即使 Windows 上的儲存庫也會停止套用保留並開始刪除內容。也就是說，Windows上的本機磁碟是這種備份儲存系統的最佳選擇。
備份副本和 Windows 儲存庫
有了 BCJ，事情就會變得更加有趣。不僅擁有完整的保留，而且無需每次換盤時都進行全量備份！它的工作原理如下：
首先，貝加萊開始在第一張光碟上創建點。假設我們將保留率設為 3 分。該任務將以無限增量模式工作，並合併所有不必要的內容（我提醒您，在這種情況下不支援 GFS 保留）。
然後我們連接第二個驅動器。由於上面還沒有鏈，我們建立一個完整備份，之後我們有第二個包含三個點的鏈：
最後，是時候重新連接第一個驅動器了。這就是神奇的開始，因為該任務不會創建完整備份，而是簡單地繼續增量鏈：
此後，實際上每個磁碟都會有自己獨立的鏈。因此，這裡的保留並不是指所有磁碟上的點數，而是每個磁碟上單獨的點數。
備份副本和Linux儲存庫網路存儲
再一次，如果儲存庫不在本機 Windows 磁碟機上，那麼所有的優雅都會消失。該腳本的工作原理與上面討論的腳本類似，只執行一項簡單的任務。每次輪換時，BCJ 將創建完整備份，並且現有點將被忘記。為了避免耗盡可用空間，您需要使用 DWORD ForceDeleteBackupFiles。
結論
因此，由於文本如此長，我們研究了兩種類型的任務。當然，還有更多任務，但不可能以一篇文章的形式考慮所有這些任務。如果閱讀後您還有任何疑問，請在評論中寫下來，我將很樂意親自解答。
來源： www.habr.com