คุณสมบัตินี้ถูกใช้ในการทำ snapshot ของ filesystem ในระดับของ subvolume ด้วยคำสั่ง
btrfs subvolume snapshot <source> [<dest>/]<name>
โดย <source> ต้องเป็น path ของ subvolume ที่ถูกเมานท์ ส่วน <dest> ต้องเป็น path ที่อยู่ใน subvolume ที่อยู่ใน btrfs pool เดียวกัน
เช่น
ในระบบมี subvolume ชื่อ @ เมานท์ไว้ที่ / (เป็น root directory)
และ @home เมานท์ไว้ที่ /home
# mkdir /backups
# btrfs subvolume snapshot /home /backups/home-20110822
Create a snapshot of '/home' in '/backups/home-20110822'
ใน /backups/home-20110822 จะมีข้อมูลเก็บอยู่เหมือนใน ้/home ในขณะเวลานั้นๆ ทันที โดยใช้เนื้อที่เพิ่มขึ้นเพียงเล็กน้อย และใช้เวลาในการทำ snapshot สั้นมากๆ แม้ว่าข้อมูลจะมีเป็นจำนวนมากก็ตาม ซึ่งผู้ดูแลระบบอาจจะแจ้งให้ผู้ใช้ทราบว่า สามารถมาเรียกคืนข้อมูลเก่าๆ ย้อนหลังจาก snapshot ที่เก็บไว้ที่ /backups ก็ได้
snapshot ที่สร้างขึ้น สามารถแก้ไขได้ โดยไม่กระทบกับข้อมูลปัจจุบัน ซึ่งในทางปฏิบัติเราไม่ควรมาแก้ตรงนี้
การลบ snapshot
เนื่องจากเนื้อของดิสก์จะถูกใช้เพิ่มขึ้น เมื่อข้อมูลปัจจุบันต่างจาก snapshot แต่ละรุ่น ดังนั้นการจะเรียกคืนเนื้อที่ส่วนนี้กลับมา ต้องลบ snapshot เก่าๆ ทิ้งไปบ้าง (อาจจะกำหนดเป็นนโยบายว่า จะเก็บย้อนหลังเพียง 7 วัน แล้วเขียน cron script เพื่อจัดการอัตโนมัติ เป็นต้น)
คำสั่ง
btrfs subvolume delete <subvolume>
เช่น
# btrfs subvolume delete /backups/home-20110822
Delete subvolume '/backups/home-20110822'
ข้อควรระวังคือ ถ้าทำ snapshot ใน filesystem ที่มีไฟล์ถูกเปิดใช้งานอยู่ เช่น mysql server สำเนา snapshot ที่ได้จะไม่สมบูรณ์เพราะไฟล์ที่เปิดอยู่มักจะมีข้อมูลบางส่วนค้างอยู่ในหน่วยความจำ ยังไม่ได้ถูกบันทึกในไฟล์จริง ดังนั้นก่อนจะทำ snapshot ควรปิดระบบที่อาจจะเปิดไฟล์ค้างอยู่ก่อน (ในที่นี้คือให้ปิดโปรแกรม mysql server ก่อน) แล้วจึงสั่งทำ snapshot
ถ้าระบบของเราใช้ btrfs ที่มี data profile และ metadata profile เป็นแบบ RAID1 หรือสร้างบนระบบ RAID1, RAID10, RAID5/6 ไม่ว่าจะเป็นซอฟต์แวร์หรือฮาร์ดแวร์แล้วละก็ อาจจะกล่าวได้ว่า
"ลาก่อน โปรแกรม backup ทั้งหลาย"
หลังจากที่เข็ดกับ lzo เมื่อวานพี่ไปเจอ server อีกตัวนึง ทำงานมาตั้ง 6 เดือน ด้วย btrfs แต่ไม่ได้ compress มันเชื่อได้นะเนี่ย
ตอบลบอีกตัวนึง compress=zlib 3 เดือน