ZFS di Ubuntu: Snapshot yang Menyelamatkan Data Anda

RAID menjaga Anda dari disk yang mati, tapi tidak dari data yang diam-diam rusak. Di sinilah checksum ZFS mengubah aturan mainnya.

Foto: Gunnar Wolf, CC BY-SA 4.0, via Wikimedia Commons

Kasus yang paling sering saya temui: SMART semua disk hijau, RAID sehat, tapi satu file foto keluarga tidak bisa dibuka. Tanpa checksum, sistem tidak punya cara mengetahui bahwa isi file berbeda dari yang seharusnya. Ia hanya tahu bahwa blok itu bisa dibaca.

Tiga hal yang membuat ZFS berbeda

• Checksum end-to-end. Setiap blok punya sidik jari. Saat dibaca, isinya diverifikasi. Kalau tidak cocok dan ada redundansi, ZFS memperbaiki sendiri tanpa Anda tahu.
• Copy-on-write. Data lama tidak ditimpa. Ini yang membuat snapshot nyaris gratis dan konsisten, karena tidak ada file yang berubah di tengah proses.
• Snapshot dalam hitungan detik. Bukan salinan penuh, hanya penanda blok. Seribu snapshot tidak menghabiskan ruang sampai ada blok yang berubah.

Konsekuensinya juga nyata: ZFS menuntut RAM, dan beberapa keputusan saat membuat pool tidak bisa diubah setelahnya.

Keputusan yang tidak bisa dibatalkan

ashift. Ini nilai sektor minimum yang dipakai pool. Hampir semua disk modern memakai sektor 4K, jadi ashift=12 adalah pilihan yang benar. Kalau Anda salah dan memakai 9, performa akan buruk permanen — satu-satunya jalan keluar adalah membuat pool baru dan menyalin data.

Struktur pool. Mirror dan raidz punya karakter berbeda. Mirror cepat, mudah diperluas sepasang disk, dan bisa kehilangan satu disk per mirror. Raidz1 hemat kapasitas tapi rentan saat rebuild pada disk besar. Untuk data yang benar-benar tidak boleh hilang, saya memilih mirror dua arah dan menerima kehilangan separuh kapasitas.

Dedup. Jangan. Deduplikasi membutuhkan tabel besar di RAM dan bisa membuat sistem tidak bisa mount ketika RAM habis. Manfaatnya kecil untuk data umum.

Membuat pool

sudo apt install zfsutils-linux

# dua disk, mirror
sudo zpool create -o ashift=12 tank mirror /dev/disk/by-id/ata-DISK1 /dev/disk/by-id/ata-DISK2

sudo zfs set compression=lz4 tank
sudo zfs set atime=off tank
sudo zfs create tank/data

Selalu pakai /dev/disk/by-id, bukan /dev/sda. Nama perangkat kernel bisa berpindah urutan setelah reboot atau penambahan disk, dan pool yang menunjuk perangkat salah tidak akan mau mount.

compression=lz4 hampir selalu menguntungkan: biaya CPU kecil, dan banyak data teks serta log terkompresi jauh lebih baik. atime=off menghilangkan penulisan metadata yang tidak perlu setiap kali file dibaca.

Snapshot terjadwal

Snapshot manual berguna, tapi yang menyelamatkan data adalah yang berjalan tanpa Anda ingat.

sudo zfs snapshot tank/data@manual-$(date +%F-%H%M)
sudo zfs list -t snapshot
sudo zfs rollback tank/data@manual-2026-10-27-0300

Untuk otomatis, saya memakai timer systemd sederhana dengan kebijakan rotasi: 7 snapshot harian, 4 mingguan, 3 bulanan. Menyimpan semuanya selamanya akan membuat daftar snapshot tidak terbaca dan memperlambat operasi tertentu.

Snapshot bukan backup. Snapshot tinggal di pool yang sama. Kalau disknya mati atau pool rusak, snapshot ikut hilang. Ini pembeda yang sering dilupakan orang yang merasa aman setelah memasang snapshot.

Replikasi ke disk lain

Backup yang benar keluar dari mesin. zfs send mengirim stream biner yang bisa diterima pool lain, dan karena checksum ikut terbawa, integritas terjaga sepanjang jalur.

# pertama kali: full
sudo zfs send tank/data@harian-2026-10-27 | sudo zfs receive backup/data

# berikutnya: inkremental, hanya blok yang berubah
sudo zfs send -i @harian-2026-10-26 tank/data@harian-2026-10-27 | sudo zfs receive backup/data

Ini yang membuat replikasi harian masuk akal meski data besar. Setelah full pertama, setiap pengiriman hanya membawa perubahan.

Scrub dan cara membaca hasilnya

Scrub membaca seluruh pool dan memverifikasi checksum. Ini satu-satunya cara mengetahui apakah data Anda masih utuh — SMART tidak akan memberi tahu.

sudo zpool scrub tank
zpool status -v tank

Jalankan sebulan sekali lewat timer. Yang dicari di output adalah errors: No known data errors. Kalau ada angka di situ, jangan diabaikan: itu berarti ZFS menemukan blok yang tidak cocok, dan tanpa redundansi ia tidak bisa memperbaikinya.

Kesalahan yang paling sering terjadi

• Pool terisi di atas 80 persen. Performa menurun tajam karena algoritma alokasi kehabisan ruang bebas. Pasang alert pada 75 persen, bukan 95.
• Menganggap RAID sebagai backup. RAID menjaga ketersediaan, bukan riwayat. File yang terhapus tetap terhapus di semua disk.
• Tidak pernah menguji restore. Backup yang belum diuji adalah asumsi. Uji ke pool terpisah minimal sekali per kuartal.
• Menambah disk ke raidz satu per satu. Raidz tidak bisa diperluas dengan satu disk; Anda perlu menambah satu grup vdev utuh atau memakai mirror.

ZFS bukan sistem file yang bisa dipasang lalu dilupakan. Ia menuntut pemahaman di awal, dan sebagai gantinya memberi Anda sesuatu yang tidak dimiliki sistem lain: kepastian bahwa data yang dibaca hari ini adalah data yang ditulis kemarin.

Baca juga:

• Cara Backup Otomatis VPS ke Object Storage dengan restic
• Kenapa Homelab Mati dalam 6 Bulan: Bedah Kegagalan Self-Hosting
• Cara Membuat File Server Samba di Ubuntu
• Cara Install Proxmox VE di PC Bekas untuk Homelab