Filesystem Snapshots

Backup penuh dengan tar menyalin semua byte; rsync menyalin perubahannya. Keduanya butuh waktu yang sebanding dengan ukuran data, dan untuk volume ratusan gigabyte itu berarti menit hingga jam. Snapshot menawarkan jalan ketiga: “foto” keadaan volume pada satu titik waktu yang selesai dibuat hampir seketika, sebesar apa pun datanya. Keajaibannya ada pada teknik copy-on-write yang memindahkan pekerjaan dari saat pembuatan snapshot ke saat data ditulis. Chapter ini membedah mekanisme itu sampai bisa disimulasikan dengan perintah biasa, lalu memetakan dua implementasinya di Linux: Btrfs dan LVM.

Foto Metadata, Bukan Salinan Data #

Kesalahpahaman paling umum: snapshot dianggap salinan data yang dipercepat. Keliru — snapshot hanyalah catatan metadata: peta yang mencatat blok data mana milik file mana pada titik waktu tertentu. Data sendiri tidak digandakan sedikit pun saat snapshot dibuat. Yang terjadi kemudian adalah copy-on-write (CoW): begitu sebuah file lama akan dimodifikasi, filesystem tidak menimpa blok lamanya, melainkan menulis ke blok baru dan hanya memperbarui metadata milik file itu untuk menunjuk ke blok baru. Metadata snapshot tidak ikut diubah, sehingga snapshot tetap menunjuk ke blok lama — inilah “foto” yang tidak pernah pudar.

Konsekuensinya dua arah. Pertama, snapshot nyaris gratis saat dibuat dan murah disimpan — ruang hanya terpakai untuk blok yang berubah setelahnya, bukan seluruh volume. Kedua, snapshot adalah titik kembali cepat: rollback cukup menukar metadata sehingga volume “kembali” menunjuk ke keadaan lama, hitungan detik, tanpa menyalin data.

Simulasi Copy-on-Write dengan Alat Sehari-hari #

Mesin Btrfs dan LVM tidak tersedia di lingkungan latihan ini, tetapi mekanisme intinya bisa kita sentuh dengan alat biasa. Kernel mengekspos CoW per-file lewat reflink — salinan file yang berbagi blok data dan hanya menyalin saat ditulis. Dukungannya bergantung pada filesystem:

mkdir -p live
printf 'versi asli\n' > live/catatan.txt
cp --reflink=always live/catatan.txt salinan-reflink.txt 2>&1

Output yang Dihasilkan:

cp: failed to clone 'salinan-reflink.txt' from 'live/catatan.txt': Operation not supported

Pesan Operation not supported muncul karena filesystem latihan ini (overlay) tidak menyediakan mekanisme reflink — begitu pula ext4, filesystem paling umum di Linux. Di atas Btrfs dan XFS, perintah yang sama berhasil seketika dan menghasilkan file yang berbagi blok dengan aslinya. Kegagalan ini justru pelajarannya: copy-on-write bukan trik user-space, melainkan layanan dari lapisan filesystem — tanpa dukungan itu, tidak ada salinan instan yang aman.

Lapisan di bawahnya bisa kita tiru dengan hard link, dan simulasi ini menunjukkan dengan tepat masalah yang diselesaikan CoW. cp -al membuat pohon baru yang setiap filenya adalah hard link ke file aslinya — salinan “instan” tanpa menyalin data. Dua file lalu diperbarui dengan dua cara yang berbeda: satu ditimpa in-place, satu diganti lewat mv:

mkdir -p live
printf 'catatan revisi 1\n' > live/catatan.txt
printf 'konfig versi lama\n' > live/konfig.txt
cp -al live snapshot
[ "$(stat -c %i live/catatan.txt)" = "$(stat -c %i snapshot/catatan.txt)" ] && echo "inode sama: snapshot berbagi data tanpa menyalin"
printf 'catatan revisi 2\n' > live/catatan.txt
printf 'konfig versi baru\n' > live/konfig.baru
mv live/konfig.baru live/konfig.txt
echo "-- catatan.txt (ditulis in-place), live:"
cat live/catatan.txt
echo "-- catatan.txt, snapshot:"
cat snapshot/catatan.txt
echo "-- konfig.txt (diganti via mv), live:"
cat live/konfig.txt
echo "-- konfig.txt, snapshot:"
cat snapshot/konfig.txt

Output yang Dihasilkan:

inode sama: snapshot berbagi data tanpa menyalin
-- catatan.txt (ditulis in-place), live:
catatan revisi 2
-- catatan.txt, snapshot:
catatan revisi 2
-- konfig.txt (diganti via mv), live:
konfig versi baru
-- konfig.txt, snapshot:
konfig versi lama

Bedah baris per barisnya:

1. Baris 4 (cp -al live snapshot): menyalin pohon live sebagai rangkaian hard link — pemeriksaan inode pada baris 5 membuktikan kedua nama menunjuk data yang sama, tanpa satu byte pun digandakan.
2. Baris 6 (printf ... > live/catatan.txt): menimpa isi catatan.txt di tempat (in-place) — cara tulis yang dilakukan shell dan banyak program sederhana.
3. Baris 7-8 (printf ... ; mv): memperbarui konfig.txt dengan menulis file baru lalu menggantikan namanya — pola yang dipakai editor dan alat yang hati-hati.

Dua cara menulis itu menghasilkan akibat berlawanan pada “snapshot” hard link. Penulisan in-place merusak foto: catatan.txt di kedua pohon ternyata berisi catatan revisi 2 karena keduanya menunjuk inode yang sama. Penggantian lewat mv justru aman: nama live/konfig.txt pindah ke data baru sementara snapshot/konfig.txt tetap memegang konfig versi lama — persis perilaku CoW. Inilah inti persoalannya: keamanan foto bergantung pada kebiasaan aplikasi yang menulis, dan tidak ada jaminan semuanya memakai cara yang aman. Filesystem CoW menyelesaikannya di lapisan bawah — setiap penulisan, termasuk yang in-place, dialirkan ke blok baru, sehingga snapshot selalu utuh apa pun perilaku aplikasinya.

Snapshot Btrfs: Subvolume sebagai Unitnya #

Di Btrfs, yang di-snapshot adalah subvolume — pohon file mandiri di dalam satu filesystem. Menjadikan /mnt/data sebuah subvolume lalu memotretnya:

sudo btrfs subvolume create /mnt/data
sudo btrfs subvolume snapshot /mnt/data /mnt/snapshots/data-2026-01-15
sudo btrfs subvolume snapshot -r /mnt/data /mnt/snapshots/data-2026-01-15-ro
sudo btrfs subvolume list /mnt

Pembuatan snapshot Btrfs bersifat atomik — keberhasilannya bulat, tidak ada keadaan setengah jadi, dan aplikasi yang sedang menulis tidak mengganggu konsistensi metadata foto. Snapshot tampil sebagai folder biasa yang bisa dibaca langsung, jadi memulihkan satu file dari keadaan lama cukup menyalinnya keluar dari folder snapshot. Untuk rollback total ada btrfs subvolume set-default yang menetapkan snapshot sebagai subvolume utama pada boot berikutnya. Opsi -r membuat snapshot hanya-baca — penjaga penting agar foto tidak tanpa sengaja ikut termodifikasi, dan syarat nyaman untuk backup: btrfs send mengalirkan snapshot hanya-baca ke arsip di disk lain.

Snapshot LVM: Level Blok #

LVM menyediakan snapshot pada tingkat blok untuk logical volume apa pun, di atas filesystem apa pun — ext4, XFS, semuanya. Kita sudah mengintip sintaksnya di chapter LVM ; sekarang sisi perilakunya:

sudo lvcreate --snapshot -n dokumen-snap -L 5G /dev/data/dokumen
sudo lvs
sudo mount -o ro /dev/data/dokumen-snap /mnt/snap
sudo umount /mnt/dokumen
sudo lvconvert --merge /dev/data/dokumen-snap

Perbedaan kuncinya ada pada -L 5G: snapshot LVM menyediakan area CoW berukuran tetap untuk menampung blok lama setiap kali data asli ditulis. Area inilah harga ruangnya, bukan volume penuh. Pemantauannya ada di kolom Data% pada lvs — persentase area yang sudah terpakai. Rollback dilakukan lvconvert --merge: pada volume yang sedang aktif, penggabungan berjalan saat volume dimount ulang atau direboot. Rincian seluruh opsinya terdokumentasi di lvcreate(8) dan panduan praktisnya di wiki Arch tentang LVM .

Btrfs vs LVM: Memilih Lapisannya #

Pilihan praktisnya: sistem file yang sudah berjalan di atas ext4 dalam kolam LVM mendapatkan snapshot tanpa memformat ulang; instalasi baru yang menginginkan perilaku CoW menyeluruh — snapshot, checksum, kompresi — memilih Btrfs. Keduanya bisa hadir bersamaan: snapshot LVM memotret blok, dan di dalamnya Btrfs tetap bekerja dengan subvolumenya sendiri. Praktik pengelolaan subvolume dan snapshot Btrfs dirangkum di wiki Arch tentang Btrfs .

Snapshot Bukan Backup #

Satu batasan mengikat semuanya: snapshot tinggal di perangkat yang sama dengan datanya. Disk yang mati membawa serta seluruh fotonya; ransomware yang mengenkripsi volume juga mengenkripsi metadatanya. Snapshot adalah lapisan perlindungan cepat untuk kesalahan detik ini — upgrade gagal, konfigurasi salah, file tertimpa — sedangkan keandalan jangka panjang tetap dituntut strategi 3-2-1 yang kita rancang di chapter Backup Strategies : arsip tar yang dikirim keluar mesin. Keduanya bekerja berlapis: snapshot menutup RPO ke detik untuk bencana kecil, backup harian menutup bencana besar.

Kini kotak peralatan kita berlapis lengkap: rsync menyalin delta, tar membekukan waktu, snapshot mengembalikan detik yang lalu. Satu hal terakhir yang membedakan admin siap dari admin panik: keterampilan menjahit semuanya kembali saat bencana benar-benar datang. Itulah chapter penutup section ini — restore dan disaster recovery.