如何檢查 btrfs 發送/接收是否正常工作？

btrfs send並且receive可用於傳輸 TB 的數據，但這些命令不會產生有用的進度輸出（即使使用-v）。我如何檢查他們是否成功？

例如，如果我創建一個名為 的新子卷source，將 1 GB 隨機數據寫入其中，並將其設為只讀以便可以發送：

# btrfs subvolume create source
# head -c 1G < /dev/urandom > source/data
# btrfs property set source ro true

btrfs send然後，使用and創建新子卷的副本receive，但在完成之前中斷該過程：

# mkdir destination
# btrfs send source | btrfs receive destination
At subvol source
At subvol source
^C

btrfs subvolume list不會表明出現任何問題：

# btrfs subvolume list .
ID 1216 gen 370739 top level 5 path source
ID 1219 gen 371244 top level 5 path destination/source

新的子卷可以正常瀏覽，雖然很明顯它的數據​​已經損壞：

# exa -lT
  - ├── destination
  - │  └── source
251M │     └── random_data
  - └── source
1.1G    └── random_data

btrfs subvolume show destination/source不會警告我們子卷不完整。它確實表明 與destination/source不同UUID，source並且看起來好像當且僅當執行完成時destination/source’Received UUID才會設置為source’ 。UUID``btrfs receive

是否Received UUID保證由創建的btrfs receive子卷是另一個文件系統上具有該 UUID 的子卷的完整且未修改的副本？

這部分不man btrfs-send建議，並且似乎暗示destination/source在上面的範例中使用作為未來快照的父級source也將無法檢測和修復損壞。但是，我仍然不完全清楚該建議的目的send -c以及該建議是否也適用於send -p.

在增量模式（選項-p和-c）中，發送端和接收端都可用的先前發送的快照可用於減少必鬚髮送的資訊量，以便在不同的文件系統上重建發送的快照。

-p <parent>給出選項時可以省略該選項-c <clone-src>，在這種情況下，btrfs send 將從複製源中確定合適的父級。

除非您保證這些快照在發送方和接收方雙方都處於完全相同的狀態，否則您不得指定複製源。

據我所知，snap-sync和其他類似工具通過將輸出重定向到一系列文件並使用可靠的方法而不是簡單的管道來傳輸它們來buttersink處理這個問題。如果我想開發自己的增量備份解決方案而不依賴發行版未打包的第三方軟體，那麼這是正確的方法嗎？btrfs send``rsync

TL;DR：如果設置Received UUID了readonly標誌，則不太可能出現問題，除非涉及粗心或惡意。

就像@timakro 在他的回答中已經說過的那樣，Received UUID在轉移完成之前不會設置。readonly旗幟也不是。再加上流中的每個命令都經過校驗和的事實（據我所知，發送的元數據也包括校驗和）使得您不太可能在接收端收到損壞的快照，readonly並且Received UUID放。如果其中任何一個未設置，btrfs 將拒絕使用該快照作為未來的參考btrfs receive。

如果接收到特製的流，或者如果某些程序或使用者在接收到的快照時更改了接收到的快照的內容，則可能會損壞接收到的快照。從btrfs-receive手冊頁：

錯誤

btrfs receive 在成功完成後將子卷設置為只讀。但是，在接收過程中，對接收路徑中的文件或目錄具有寫入權限的使用者可以添加、刪除或修改文件，在這種情況下，生成的只讀子卷將不是已發送子卷的精確副本.

如果打算創建一個精確的副本，則應保護接收路徑不被使用者訪問，直到接收操作完成並且子卷設置為只讀。

此外，receive 目前不能很好地驗證增量發送流是否真正有意義，因此特製的發送流可以創建一個子卷，其中包含指向同一文件系統中任意文件的反射連結。因此，建議使用者不要在來自不受信任的來源的發送流上使用 btrfs 接收，並在通過不受信任的網路發送它們時保護受信任的流。

還值得注意的是，可以禁用readonly子卷上的標誌，修改內容，然後再次啟用它。如果在任何一方都這樣做了，所有的保證都會被拋到窗外。

請注意，將輸出通過管道傳輸到文件並傳輸該文件不會提供上述任何保護。就我個人而言，我絕對沒有理由將輸出btrfs send直接傳輸到ssh. 將流中間儲存在文件中的好處是它可以在不可靠的連接上恢復中斷的傳輸，但它不提供數據完整性方面的任何保證。

驗證接收到的快照是否與發送的快照匹配的一種好方法（雖然不是萬無一失）是使用rsync -avcn --del path/to/sent/snapshot/ user@remote:path/to/received/snapshot/.

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