文件系統快照與簡單地製作文件副本有何不同？
通過做這個，
# btrfs subvolume snapshot /mnt/1 /mnt/1/snapshot # tree /mnt/1 /mnt/1 ├── a ├── snapshot │ ├── a │ └── subv └── subv └── b 3 directories, 3 files我們可以在 btrfs 上從 /mnt/1 創建快照。
我的問題是：與使用 rsync 來簡化備份文件系統相比，使用快照有什麼優勢？
快照可以被視為一種特殊情況，但不同於複製。
我對 Btrfs 的具體細節不是很熟悉，但以下內容適用於 ZFS，Btrfs 從中汲取了很多靈感。顯然**Btrfs 快照實際上是讀/寫的，**使它們更類似於ZFS 文件系統複製，但這不會改變它們與文件副本的關係。
快照是文件系統狀態的只讀時間點副本。
這是因為 Btrfs 和 ZFS 都是所謂的 Copy On Write 文件系統。每當更改數據塊時，更改的數據都會寫入磁碟上與原始副本不同的位置。這樣做的主要好處是它大大提高了可靠性：因為需要在原地覆蓋的數據非常少，因此導致數據失去的問題的可能性大大降低。但是，*還有其他優點。*這樣的優勢之一是您可以有效地進行文件系統級快照。一個主要的缺點是，當你的儲存被填滿時，它往往會大大增加儲存碎片，因為塊分配器很難在某個地方、任何地方找到物理儲存副本。事實上，建議將 ZFS 池的使用率保持在 80% 以下，可能至少不是出於這個確切原因。
快照基本上告訴文件系統程式碼“這些塊仍然需要”。因此，它們不會被回收並可能被新數據覆蓋。但是，它們仍然引用相同的舊數據塊。
現在，這與簡單地使用 rsync、cp、cat 或其他任何東西製作副本有何不同？這是不同的，因為在數據實際更改之前，不會製作數據的額外物理副本。
這就像立體模型上的硬連結；當訪問不同名稱的文件時，使用相同的物理磁碟副本。不同之處在於，對於硬連結，對同一個名稱下的文件的更改會傳播到其他所有副本，因為它們確實引用了相同的數據塊。使用寫時複製和快照，更改的塊僅顯示在更改的位置。（對於只讀快照，這意味著在文件的“目前”版本中。）您還只需要重寫實際更改的塊；剩餘的塊完全留在它們所在的位置。例如，對於包含 VM 磁碟映像的快照文件之類的操作，這可能會對儲存在磁碟上所需的數據量產生巨大影響。
所以，回顧一下：
- 快照只需要更改塊所需的磁碟空間。複製需要副本數乘以文件大小。
- 快照是只讀的或讀/寫的，具體取決於文件系統設計。副本是按設計讀/寫的。
- 副本是獨立的。快照引用與文件的目前版本相同的數據塊，直到文件的目前版本發生變化（全部或部分）。