btrfs 發送的可恢復傳輸

我計劃通過將 btrfs 快照發送到線上儲存來備份數據。儲存作為 LUKS 加密容器文件安裝在 cifs 共享上。

以後的傳輸會相當快，但是第一個是 1,3TB，當我使用 tc 給我留下合理數量的上游時，需要 23 天。現在，理論上，我的連接可以處理這個問題，但重新連接是可能的。據我了解，如果我只是使用，這將迫使我重新開始

btrfs send ... | btrfs receive ...

是否有任何保存，即可恢復的方式來做到這一點？我找到了 buttersink，但它似乎只允許恢復 S3。

有任何想法嗎？

隨意使用評論來提出完全不同的解決方案。它是一個 Hetzner Storagebox ( https://www.hetzner.de/de/hosting/storagebox/bx40 )。我有 FTP、FTPS、SFTP、SCP（但不是 SSH，paramiko 也不起作用）、Samba/CIFS、HTTPS、WebDAV 訪問。儲存不信任未加密的數據。兩個站點上的可用空間都不過分。將有很多更改的較小文件，因此沒有定期完整備份（再次需要一個月）的重複似乎是不可行的。出於同樣的原因，將本地版本與遠端本地安裝的版本進行比較時，rsync 很可能會很慢。EncFS 似乎沒有保存，因為隨著時間的推移，另一方可能會收集單個文件的多個版本。

據我了解，您的遠端儲存是作為文件系統公開的。我不使用btrfs自己，但我假設快照相當於一個大的“完整備份”文件，然後是一些較小的“增量”文件。

在此基礎上，我仍然會繼續使用，rsync因為它是可重新啟動的。rsync除非遠端主機上有可用的伺服器，否則您不能使用其時髦的 delta 差異算法，但您可以rsync假設源文件沒有更改，並在其達到的字節偏移量中斷後繼續：

test -t 2 && progress=--progress
rsync -av $progress --partial --append --sparse /path/to/source.img /path/to/remote/storage/

如果您可以gzip在傳輸之前對您的源文件有用，請執行此操作。（與本地到本地文件傳輸無關，--rsyncable也不rsync -z相關。）rsync

btrbk支持：

恢復備份（如果備份目標暫時無法訪問）

buttersink 支持：

本地 btrfs 文件系統、通過 SSH 的遠端 btrfs 文件系統或 S3 儲存桶。

或者您可以手動執行此操作：

1. 不要通過 stdout 寫入 shell 管道，而是使用-f選項將send的數據寫入文件：

btrfs send -f outfile 2. 使用您喜歡的可恢復傳輸方法（例如rsync）傳輸文件 3. 用於btrfs receive -f outfile從 outfile 而不是從 stdin 讀取數據

引用自：https://unix.stackexchange.com/questions/285433