Jadwal ZFS Scrub untuk Pool VPS Kecil

Apa yang sebenarnya dilakukan ZFS scrub

ZFS scrub membaca setiap blok yang dialokasikan dalam pool, menghitung ulang checksum-nya, lalu membandingkan hasilnya dengan checksum yang tersimpan dalam block pointer induk. Jika keduanya berbeda, ZFS memperbaiki blok tersebut menggunakan redundansi yang tersedia pada pool. Tidak ada mekanisme lain dalam ZFS yang melakukan tugas ini. Pembacaan biasa hanya memverifikasi blok yang kebetulan Anda akses. Jadi, file yang tidak pernah Anda buka selama dua tahun tetap tidak terverifikasi sampai scrub membacanya.

Scrub bukan fsck, yaitu proses perbaikan offline yang diperlukan filesystem lain. Tidak ada tahap perbaikan struktur karena ZFS tidak pernah membiarkan format pada disk berada dalam kondisi rusak: setiap penulisan dilakukan ke lokasi baru, lalu uberblock, yaitu root pointer pool, diperbarui terakhir. Scrub juga tidak membaca seluruh perangkat. Scrub hanya membaca blok yang dialokasikan. Karena itu, scrub pada pool yang hampir kosong selesai dalam hitungan menit, sedangkan pool yang sama saat terisi 80% memerlukan waktu jauh lebih lama.

Scrub berjalan dengan prioritas I/O terendah yang tersedia bagi ZFS. Di Linux, zfs_vdev_scrub_max_active secara default bernilai 2. Artinya, paling banyak dua pembacaan scrub berjalan secara bersamaan pada setiap vdev (virtual device, yaitu kelompok disk yang diperlakukan ZFS sebagai satu unit). zfs_scrub_min_time_ms secara default bernilai 750. Nilai ini adalah waktu minimum yang digunakan thread sinkronisasi untuk pekerjaan scrub di antara flush transaction group, yaitu commit berkala yang digunakan ZFS untuk mengelompokkan penulisan. Pada mesin yang tidak sibuk, scrub menggunakan seluruh kapasitas disk. Saat beban meningkat, scrub mengurangi aktivitasnya. Pada pool dengan satu atau dua perangkat, tidak ada kapasitas lain untuk dialihkan. Karena itu, penjadwalan lebih penting pada konfigurasi ini daripada pada chassis besar dengan enam puluh drive.

Mengapa melakukan scrub pada pool yang tidak dapat memperbaiki dirinya sendiri?

Kalimat ini menentukan semua hal lain pada pool kecil. Tanpa redundansi, scrub mendeteksi kerusakan tetapi tidak dapat memperbaikinya. Satu virtual disk dalam VPS adalah pool tanpa mirror dan tanpa parity. ZFS akan membaca blok yang rusak, mendapati checksum tidak cocok, menghitungnya pada kolom CKSUM, mencantumkan nama file, lalu berhenti karena tidak ada salinan kedua yang dapat digunakan untuk membangunnya kembali.

Ada dua pengecualian parsial yang perlu diketahui. Secara default, ZFS menyimpan salinan tambahan metadata (redundant_metadata=all) pada region perangkat yang berbeda. Karena itu, scrub dapat memperbaiki directory entry atau block pointer yang rusak bahkan pada pool dengan satu perangkat. Dataset dengan copies=2 juga menyimpan dua salinan blok datanya, dengan biaya ruang dua kali lipat. Namun, keduanya tidak dapat bertahan jika perangkat tersebut tidak lagi tersedia. Dokumentasi properti copies memperingatkan hal ini secara tepat: jangan membuat pool striped, menetapkan copies=2, lalu menganggap Anda telah memiliki redundansi.

Jadi, pada pool dengan satu perangkat, scrub memberi Anda satu hal: pemberitahuan yang lebih awal dan akurat. Scrub mengubah kerusakan yang sebelumnya tidak terlihat menjadi nama file di zpool status -v, sementara backup Anda masih menyimpan versi file yang baik. Ini adalah alasan untuk memiliki backup, bukan alasan untuk tidak melakukan scrub. Jika Anda belum memahami perbedaan antara image point-in-time dan salinan nyata di luar server, mulai dengan mengapa snapshot VPS bukan backup, karena hasil scrub hanya berguna jika ada salinan utuh yang disimpan di tempat lain.

Scrub yang tidak menemukan apa pun juga merupakan hasil. Hasil tersebut memberi tahu Anda bahwa data yang akan Anda andalkan masih utuh. Itulah informasi yang ingin Anda ketahui sebelum melakukan restore atau migrasi.

Seberapa sering Anda harus melakukan scrub pada pool VPS kecil?

Bulanan adalah default yang tepat, dan itulah interval yang diasumsikan oleh paket yang tersedia. Debian dan Ubuntu menyediakan cron job yang melakukan scrub pada pool yang sehat setiap Minggu kedua setiap bulan. Sistem periodic FreeBSD menggunakan ambang batas dalam satuan hari, dan daily_scrub_zfs_default_threshold secara default bernilai 35, yang dalam manual dijelaskan sebagai lima minggu.

Scrub mingguan pada pool kecil yang sibuk biasanya membutuhkan biaya lebih besar daripada manfaatnya. Dengan satu atau dua perangkat, scrub bersaing menggunakan antrean yang sama dengan aplikasi Anda, dan tidak ada perangkat cadangan untuk menanganinya. Pada VPS, alokasi I/O terbatas. Artinya, operasi baca yang digunakan scrub mengurangi operasi baca yang tersedia untuk database Anda. Sebagai imbalannya, scrub mingguan paling banyak memberi peringatan tiga minggu lebih awal tentang kerusakan yang tetap tidak dapat Anda perbaiki. Pertukaran ini hanya masuk akal jika scrub tidak membebani sistem.

Ukur durasinya, lalu buat keputusan. Jalankan satu scrub secara manual dan pantau waktu yang dibutuhkannya.

1. Jalankan sudo zpool scrub tank pada malam yang tenang dan catat total waktu sejak zpool status.
2. Jika proses selesai jauh di bawah satu jam dan server tidak digunakan pada malam hari, interval mingguan masih terjangkau.
3. Jika proses berjalan selama berjam-jam saat pool melayani trafik, pertahankan interval bulanan dan biarkan job dari paket menanganinya.
4. Ukur ulang durasinya setiap kali pool bertambah secara signifikan, karena durasi scrub mengikuti jumlah data yang dialokasikan, bukan kapasitas disk.

Apa pun pilihan Anda, catat keputusan tersebut bersama pekerjaan server berulang lainnya. Scrub harus tercantum dalam daftar yang sama dengan pemutakhiran paket dan rotasi log: lihat checklist pemeliharaan server Linux bulanan.

Mulai, jeda, dan hentikan scrub

sudo zpool scrub tank
sudo zpool status tank

Menjeda dan menghentikan adalah operasi yang berbeda. Memilih opsi yang salah dapat membuat Anda mengulangi pekerjaan selama berjam-jam.

sudo zpool scrub -p tank
sudo zpool scrub tank
sudo zpool scrub -s tank

-p menjeda scrub. Status dan progres jeda disinkronkan ke disk secara berkala. Karena itu, scrub yang dijeda tetap dijeda setelah export atau reboot: pool kembali dalam keadaan scrub masih dijeda dan menunggu tindakan Anda. Menjalankan zpool scrub lagi akan melanjutkan scrub dari checkpoint terakhir yang ditulis ke disk. Sebaliknya, -s menghentikan scrub. Scrub berikutnya yang Anda mulai akan dimulai dari awal. Gunakan -p jika Anda memerlukan kembali akses ke disk selama satu jam. Gunakan -s jika Anda ingin menghapus scrub.

Ada dua flag lain yang perlu diketahui. -w menunggu hingga scrub selesai sebelum mengembalikan kontrol. Ini diperlukan dalam script agar langkah berikutnya tidak dimulai terlalu awal. -e hanya menjalankan scrub pada file yang memiliki error data yang diketahui, sebagaimana dilaporkan oleh zpool status -v. Ini adalah cara cepat untuk memastikan bahwa file yang Anda pulihkan dari backup kini bersih.

ZFS menjalankan satu scrub atau resilver per pool pada satu waktu. Resilver adalah proses rebuild setelah perangkat diganti. Keduanya membutuhkan I/O yang intensif. Jika suatu perangkat sedang menjalani resilver, scrub akan menunggu gilirannya.

Cara membaca status zpool saat scrub berjalan

Jalankan sudo zpool status tank dan baca angka Anda sendiri, bukan dengan mencocokkannya dengan angka milik orang lain. Saat scrub berjalan, baris scan: memuat jumlah yang telah dipindai, jumlah yang telah diproses, total, jumlah yang diperbaiki, persentase progres, dan perkiraan waktu yang tersisa.

Scanned adalah fase metadata: ZFS menelusuri pohon blok dan mengumpulkan alamat yang perlu dibaca. Issued adalah fase data: pembacaan yang benar-benar dikirim ke perangkat, setelah diurutkan berdasarkan urutan disk. Scrub yang diurutkan menyebabkan adanya dua penghitung, dan issued adalah penghitung yang menunjukkan progres nyata. Pada tahap awal, scanned jauh lebih cepat daripada issued, sehingga perkiraan waktu hampir tidak berarti. Nilai ini baru layak dinilai setelah mencapai sepuluh persen pertama.

Repaired menghitung byte yang ditulis ulang dari salinan yang baik. Pada pool tanpa redundansi, nilainya tetap 0, apa pun yang ditemukan scrub. Ini menegaskan kembali poin sebelumnya dalam bentuk angka yang dapat dipantau.

Selanjutnya, baca kolom untuk setiap perangkat. READ dan WRITE menghitung error I/O yang dilaporkan langsung oleh perangkat. CKSUM menghitung blok yang gagal dalam verifikasi checksum, dan CKSUM adalah kolom yang diisi oleh scrub. Nilai CKSUM yang bukan 0 pada perangkat yang terlihat sehat tetap merupakan masalah nyata: data berhasil dikembalikan, tetapi isinya salah.

Baris terakhir adalah hasil akhirnya. errors: No known data errors berarti scrub berhasil. Hasil lain berarti Anda harus menjalankan sudo zpool status -v tank, yang menampilkan daftar lengkap error data sejak scrub lengkap terakhir, termasuk nama file yang terdampak. Pulihkan file tersebut dari backup, jalankan sudo zpool clear tank untuk mereset penghitung, lalu jalankan scrub lagi. Setiap scrub lengkap membangun ulang daftar tersebut, sehingga nama file yang tidak lagi muncul setelah scrub lengkap yang bersih benar-benar sudah tidak bermasalah.

Pekerjaan scrub berkala apa yang ada di server Anda?

Jangan berasumsi bahwa pekerjaan tersebut ada, dan jangan berasumsi bahwa hanya ada satu. Mekanismenya berbeda menurut platform dan paket. Format pool sama di semua platform. Hal ini mudah membuat Anda lupa bahwa tool di sekitarnya berbeda. Cara ZFS dirilis di FreeBSD dibandingkan dengan Linux adalah perbedaan yang penting di sini.

Di FreeBSD, pekerjaan tersebut berada dalam sistem periodic. Atur nilai berikut di /etc/periodic.conf:

daily_scrub_zfs_enable="YES"
daily_scrub_zfs_pools="tank"
daily_scrub_zfs_default_threshold="35"

daily_scrub_zfs_pools adalah daftar nama pool yang dipisahkan spasi. Jika dikosongkan, sistem akan melakukan scrub pada semua pool. daily_scrub_zfs_default_threshold adalah jumlah hari antar-scrub jika tidak ada ambang batas khusus untuk pool. Manual menetapkan 35 sebagai nilai default. Pekerjaan harian berjalan setiap hari. Scrub hanya dimulai setelah ambang batas terlampaui.

Di Linux, mekanismenya bergantung pada paket ZFS dari distribusi Anda. Beberapa sistem menggunakan kedua mekanisme sekaligus. Terdapat systemd timer per pool, yaitu zfs-scrub-monthly@tank.timer dan zfs-scrub-weekly@tank.timer, yang diaktifkan satu pool pada satu waktu. Debian dan Ubuntu juga menyediakan /etc/cron.d/zfsutils-linux. Paket ini menjalankan skrip yang melakukan scrub pada setiap pool ONLINE pada hari Minggu kedua setiap bulan. Periksa konfigurasi yang tersedia sebelum menambahkan apa pun:

systemctl list-timers 'zfs-*'
ls /etc/cron.d/ | grep -i zfs
sudo zpool history tank | grep scrub

zpool history adalah jawaban yang sebenarnya karena mencatat scrub yang benar-benar dimulai oleh pool, beserta tanggalnya. Dua scrub per bulan berarti kedua mekanisme aktif, dan salah satunya harus dinonaktifkan. Untuk mengaktifkan timer:

sudo systemctl enable --now zfs-scrub-monthly@tank.timer

Ruang kosong lebih penting daripada parameter apa pun

Durasi scrub pada pool kecil ditentukan oleh jumlah data yang dialokasikan dan seberapa tersebar data tersebut. Memenuhi pool akan memperburuk kedua faktor itu.

Panduan OpenZFS menyarankan agar ruang kosong pool dipertahankan di atas 10%. Jika berada di bawah batas tersebut, metaslab—potongan ruang yang digunakan allocator—mulai melewati ambang ruang kosong 4%, dan allocator beralih dari first-fit ke best-fit. Best-fit membutuhkan CPU jauh lebih besar. Latensi penulisan meningkat, fragmentasi bertambah, dan scrub berikutnya menjadi lebih lambat karena jumlah data yang sama kini dibaca sebagai lebih banyak operasi baca dengan ukuran lebih kecil.

Karena itu, langkah pertama bukan mengubah parameter. Hapus data yang tidak diperlukan. Pada server ZFS, penyebab yang paling umum adalah snapshot lama, diikuti oleh image dan layer Docker yang tidak pernah dihapus serta paket kernel yang tertinggal setelah upgrade. Jalankan zfs list -o space sebelum melakukan hal lain karena perintah ini memisahkan ruang yang digunakan snapshot dari ruang yang digunakan data aktif.

Selanjutnya, parameter yang relevan secara singkat. Di Linux, Anda dapat membaca nilai saat ini:

cat /sys/module/zfs/parameters/zfs_scrub_min_time_ms
cat /sys/module/zfs/parameters/zfs_vdev_scrub_max_active

FreeBSD menyediakan parameter yang sama melalui sysctl. Temukan parameter tersebut dengan sysctl -a | grep scrub. Menaikkan nilainya akan mempercepat scrub selesai, tetapi memperlambat aplikasi. Menurunkannya memberikan hasil sebaliknya. Pada pool dengan satu atau dua perangkat, tidak ada pengaturan yang dapat memberikan kedua manfaat tersebut karena hanya ada satu antrean yang harus dibagi. Parameter jarang memperbaiki masalah desain. Jika scrub bulanan mengganggu kinerja, kesimpulan yang tepat adalah pool terlalu penuh atau perangkat terlalu lambat. Parameter hanya memindahkan masalah.

Waktu scrub adalah perkiraan resilver

Resilver melakukan proses pembacaan yang sama seperti scrub: membaca blok yang dialokasikan, memverifikasinya, lalu menulis blok yang hilang ke perangkat pengganti. Jadi, durasi scrub adalah perkiraan paling realistis tentang berapa lama rebuild akan berlangsung, serta berapa lama pool akan berjalan dengan redundansi yang berkurang selama proses tersebut.

ZFS menjadwalkan pekerjaan resilver dengan prioritas yang lebih tinggi daripada pekerjaan scrub, sehingga rebuild biasanya selesai lebih cepat daripada scrub pada pool yang sama. Gunakan durasi scrub sebagai batas atas yang konservatif. Jika scrub memerlukan waktu sembilan jam, siapkan jendela rebuild dengan durasi yang kurang lebih sama. Pahami bahwa kegagalan perangkat kedua dalam jendela tersebut akan menyebabkan pool hilang. Inilah alasan praktis untuk menggunakan pasangan mirror, bukan satu grup raidz yang lebar, karena raidz, yaitu tata letak paritas yang digunakan ZFS sebagai pengganti RAID 5, melakukan rebuild dengan membaca semua perangkat yang masih bertahan.

Pada pool dengan satu perangkat, tidak ada resilver sama sekali. Jika perangkat tersebut gagal, pool juga ikut gagal. Waktu pemulihan Anda adalah waktu restore, jadi ukur proses restore tersebut. Restore yang belum pernah Anda jalankan bukanlah rencana pemulihan.

Apa yang berubah saat Anda menyewa disk

Pada VPS, perangkat blok bersifat virtual. Hypervisor menyajikan sebuah volume. Di bawahnya dapat terdapat NVMe lokal atau volume jaringan tereplikasi dengan paritasnya sendiri. Untuk scrub, ada dua konsekuensi.

Pertama, redundansi platform tidak terlihat oleh ZFS dan tidak dapat digunakan oleh ZFS. Jika platform memperbaiki error media di bawah lapisan Anda, ZFS tidak pernah melihat masalah tersebut. Jika platform meneruskan blok yang salah, ZFS mendeteksinya tetapi tidak dapat memperbaikinya karena salinan yang benar berada di sisi lain batas tersebut.

Kedua, Anda biasanya tidak dapat membaca data SMART (self-monitoring, analysis and reporting technology) dari perangkat di bawah disk virtual. Karena itu, peringatan dini yang menjadi dasar pemantauan kesehatan disk pada VPS mungkin sama sekali tidak tersedia. Penghitung CKSUM dari scrub menjadi sinyal utama yang dapat Anda pantau sendiri.

Jika ingin ZFS memperbaiki masalah, bukan hanya melaporkannya, pool memerlukan lebih dari satu perangkat dalam instance yang sama. Ini merupakan keputusan perencanaan, bukan penyesuaian konfigurasi. Memilih VPS penyimpanan daripada VPS biasa memberi Anda kapasitas. Namun, apakah Anda mendapatkan dua perangkat independen bergantung pada paketnya. Jalankan lsblk dan pastikan terlebih dahulu sebelum membuat mirror pada dua partisi yang ternyata berasal dari satu volume. Kami menyewakan server Linux dan FreeBSD, bukan appliance ZFS terkelola. Karena itu, jadwal scrub dan pencadangan harus Anda jalankan sendiri. Inilah komprominya: kendali penuh atas pool dan tanggung jawab penuh atas pemeliharaannya.

FAQ

Seberapa sering saya harus melakukan scrub pada pool ZFS di VPS?

Scrub setiap bulan cocok untuk sebagian besar pool kecil. Jadwal ini juga sesuai dengan konfigurasi bawaan paket: cron pada hari Minggu kedua di Debian dan Ubuntu, serta ambang batas bawaan 35 hari pada sistem periodic FreeBSD. Scrub setiap minggu hanya layak dilakukan setelah Anda mengukur durasi scrub dan memastikan prosesnya selesai dengan cepat pada server yang sedang tidak sibuk. Pada pool sibuk dengan satu atau dua perangkat, scrub mingguan menggunakan I/O aplikasi secara nyata setiap minggu, tetapi hanya memberi peringatan beberapa minggu lebih awal.

Apakah scrub pada pool ZFS dengan satu disk tidak ada gunanya?

Tidak, selama Anda memahami manfaatnya. Tanpa redundansi, scrub dapat mendeteksi kerusakan tetapi tidak dapat memperbaikinya, kecuali kerusakan metadata karena ZFS secara default menyimpan satu salinan tambahan. Hasilnya adalah daftar file rusak yang tercantum di zpool status -v, sehingga Anda masih memiliki waktu untuk memulihkannya ketika salinan yang baik masih tersedia di tempat lain. Tindakan yang tepat adalah memperbaiki strategi backup, karena scrub memberi tahu dengan tepat file mana yang harus dipulihkan.

Dapatkah saya menjeda scrub ZFS dan melanjutkannya nanti?

Ya. zpool scrub -p tank menjedanya, dan status jeda serta progresnya ditulis ke disk secara berkala. Karena itu, scrub tetap dijeda saat pool diekspor atau server di-reboot. Jalankan zpool scrub tank lagi untuk melanjutkan dari checkpoint terakhir. Jangan gunakan zpool scrub -s tank untuk tujuan ini: -s menghentikan scrub, dan scrub berikutnya dimulai lagi dari awal.

Mengapa scrub ZFS saya sangat lambat, dan apakah saya dapat mempercepatnya?

Durasi scrub bergantung pada data yang dialokasikan dan fragmentasi, bukan kapasitas disk. Pool yang terisi lebih dari 90% menjadi lambat karena metaslab dengan ruang kosong kurang dari 4% membuat allocator beralih dari first-fit ke best-fit. Fragmentasi yang dihasilkan menyebabkan scrub melakukan banyak pembacaan kecil. Mengosongkan ruang biasanya lebih efektif daripada mengubah tunable apa pun. Anda dapat menaikkan zfs_scrub_min_time_ms atau zfs_vdev_scrub_max_active agar scrub mendapat porsi antrean yang lebih besar, tetapi pada pool dengan satu atau dua perangkat, porsi tersebut langsung mengurangi porsi untuk aplikasi.