在備份場景中使用 btrfs 快照優於 rsnapshot 有哪些優勢
目前我使用 rsnapshot 將數據從一個加密的 ext4 驅動器備份到另一個。我的系統在每個驅動器上打開一個 LUKS 容器，並按照每小時的時間表執行 rsnapshot。我對 btrfs 的內置快照功能很感興趣，我很好奇它是否可以用來代替我目前的設置（當然假設我重新格式化了驅動器）。有沒有我沒有意識到的明顯問題？可以通過使用 btrfs 來改進我目前的設置，例如它是否更快？
btrfs 是一種寫時復製文件系統，具有許多使其比傳統文件系統慢的特性（如錯誤檢測和糾正、透明壓縮、快照、子卷等）。
但是，btrfs 快照非常輕量級，幾乎不需要時間來製作。並且使用
btrfs send ... | btrfs receive(orbtrfs send | ssh | btrfs receive) 比使用rsyncorrsnapshot或任何其他需要比較發送方和接收方文件的方法快得多。發送快照時不需要進行這些文件比較，因為一個快照和另一個快照之間的確切差異是已知的（它們是快照固有的），因此更改的塊可以作為連續二進制流發送到接收器 - 不需要比較文件時間戳或內容。
簡而言之，整體文件系統性能會變慢，但備份會快得多。
我使用
zfs而不是btrfs，它具有非常相似的快照和發送/接收機制。當我從備份切換rsync到zfs send備份時，它將增量備份的執行時間從幾個小時減少到幾分鐘。我將本地網路上的所有機器備份到主文件伺服器上的“備份”池中。
rsync在 cron 觸發第二天的備份之前，備份還沒有完成。由於始終執行多個同時備份，伺服器的性能非常糟糕，並且需要不斷的手動干預（主要是殺死 rsync 程序）才能將其恢復到可用狀態。切換到zfs send是擁有一個可用的文件伺服器和一個不可用的文件伺服器之間的區別。現在我幾乎不需要去想它，它就行了。最多每隔一兩年，我就會清除備份池上的舊快照（我積極地自動使正在備份的主機上的快照過期，但在備份池上的積極性要小得多），如果我讓備份池保留一百萬或兩個快照。至於它是否可以替換您目前的設置，我建議創建一個帶有兩個 btrfs 池的 btrfs 測試 VM，並嘗試製作快照並將它們從一個池發送到另一個池。或多個測試虛擬機，以便您可以
btrfs send在ssh.在您非常熟悉和熟悉 btrfs 快照和 btrfs 發送/接收的工作方式之前，我不建議您切換。
事實上，也可以製作一些 ZFS 虛擬機，這樣您就可以感受其中的差異。
VM 非常適合在您決定是否要使用它之前嘗試新東西。閱讀文件是必不可少的，但如果您真的想了解某些東西是如何工作的，那就沒有什麼比親自動手了。
順便說一句，透明壓縮可以抵消使用 btrfs 或 ZFS 之類的 fs 和 ext4 或 xfs 等更傳統的 fs 之間的大部分性能損失，具體取決於您的工作負載。
- 如果 fs 性能對您來說是唯一或最重要的事情，那麼使用
xfs- 到目前為止，它是明顯的贏家。- 如果您需要/想要快照、快照發送/接收、壓縮、ECC、子卷等，請使用 ZFS 或 btrfs。
- IMO，使用 btrfs 而不是 ZFS 的唯一真正原因是 btrfs 在主線 linux 核心中，而 ZFS 可能永遠不會是由於 CDDL 和 GPL 之間的許可證衝突。對於 ZFS，您必須編譯和安裝核心模組……使用 zfs-dkms 模組非常容易。
- 如果您使用的是 Ubuntu，那麼您可以開箱即用地使用 ZFS，他們認為許可證問題沒什麼大不了的 - IMO 他們對此是錯誤的，但他們不太可能被 Oracle 起訴。
- 此外，由於您使用 LUKS，您可能會感興趣的一件事是 ZFS 可以選擇加密任何數據集（btrfs 術語中的“子卷”。有點像 LVM 術語中的組合 LV + 文件系統）。我從來沒有使用過 LUKS 或 ZFS 的加密，所以我不能告訴你它們是如何比較的。
- 這些天我真的沒有太多理由使用 ext4，除了它幾乎是大多數發行版的預設設置。沒有優勢，也沒有令人信服的理由來使用它。
- 最後，不要被 ZFS 的重複數據刪除所誘惑。這在理論上聽起來是個好主意，但在實踐中這意味著重複數據刪除表需要保存在 RAM 中，這樣您就可以減少對更便宜的驅動器的需求，並用更昂貴的 RAM 取而代之. 對於一些特殊的案例（例如執行數百或數千個相同的 VM 映像）來說，這是一筆不小的交易——RAM 將更好地用於執行程序或記憶體磁碟。