Berkat ZFS, Kehilangan Data Hanya Sekitar 10 Menit

 (mastodon.social)
3 poin oleh GN⁺ 2023-08-24 | 1 komentar | Bagikan ke WhatsApp
  • SSD berusia 2 tahun tiba-tiba mati, tetapi sistem berhasil dihidupkan kembali di drive baru lewat replikasi inkremental ZFS, sehingga kehilangan nyata hanya sekitar 10 menit
  • Arsitekturnya mengambil snapshot seluruh filesystem setiap 10 menit dan mengirimkannya ke NAS; otomatisasinya menggunakan zrepl
  • Snapshot menyimpan keadaan sistem yang sedang berjalan pada titik waktu tertentu dan hanya mengirim perubahan, sehingga replikasi latar belakang tetap memungkinkan bahkan di jaringan rumah
  • Proses pemulihan jauh dari pemulihan otomatis karena harus menjalankan ZFS receive sebesar 625GiB semalaman dan memulihkan wrapper key enkripsi
  • ZFS memang membutuhkan beban adopsi awal dan pemeliharaan yang besar, tetapi menunjukkan efek disaster recovery yang mampu memulihkan hingga keadaan kerja saat drive benar-benar rusak

Setelah SSD rusak, kerugian yang tersisa hanya 10 menit

  • Saat membuka laptop untuk mengirim email, layar membeku menjadi hitam, dan setelah reboot diketahui SSD berusia 2 tahun sudah mati
  • Setelah memulihkan sistem ke drive baru, laptop bisa digunakan kembali, dan total kehilangan data hanya sekitar 10 menit
  • Laptop yang dipulihkan boot ke titik saat pekerjaan terhenti, dan tab browser juga mengembalikan pekerjaan yang belum selesai dari malam sebelumnya
  • Gagasan untuk melanjutkan keadaan sebelumnya di perangkat baru, seperti iklan Chromebook 12 tahun lalu, benar-benar bekerja dalam situasi kerusakan kali ini

Arsitektur yang lebih mirip replikasi daripada backup

  • Alih-alih sekadar mencadangkan drive, digunakan metode replikasi seluruh filesystem
  • Musim dingin lalu, penyimpanan jaringan rumah dibangun untuk backup berkala komputer-komputer yang dipakai untuk pekerjaan kreatif, dan dari berbagai opsi dipilih replikasi inkremental ZFS
  • ZFS dapat membuat snapshot titik waktu tertentu secara efisien bahkan pada sistem yang sedang berjalan
  • Saat kemudian dikirim ke mesin lain, yang dikirim bukan seluruh data berulang kali, melainkan hanya data yang berubah

Dikirim ke NAS setiap 10 menit dengan zrepl

  • zrepl digunakan untuk mengotomatiskan pembuatan snapshot dan pengiriman ke NAS
  • Konfigurasinya mengambil dan mengirim snapshot seluruh filesystem setiap 10 menit
  • Berkat snapshot inkremental, replika dapat tetap mutakhir meski dijalankan di latar belakang pada jaringan rumah
  • Eksekusi terakhir membutuhkan 14 detik untuk pengiriman dan mengirim sekitar 64MiB

Beban kerja manual yang tampak saat proses pemulihan

  • Pemulihan sistem adalah proses yang perlu dipelajari dan sebagian besar bergantung pada pekerjaan manual
  • Proses ZFS receive 625GiB harus dijalankan semalaman
  • Karena snapshot dienkripsi oleh komputer asal, NAS tidak dapat membaca isinya
  • Agar backup benar-benar bisa digunakan, wrapper key enkripsi juga harus dipulihkan
  • Proses pemulihan terasa sangat mencemaskan sampai ada konfirmasi pertama bahwa data bisa didekripsi

Biaya adopsi dan penggantian hardware

  • Penyiapan awal ZFS membutuhkan penggantian seluruh filesystem, sehingga biaya awalnya tinggi
  • Pemeliharaannya membutuhkan banyak pengetahuan terkait, dan prosedur operasionalnya mencakup pekerjaan manual
  • Meski begitu, beruntung replikasi sudah disiapkan sebelum SSD pertama kali rusak, dan kasus ini memperlihatkan keunggulan ZFS
  • Drive yang mati adalah WD_BLACK SN850 yang awalnya termasuk dalam pesanan Framework
    • Di forum Framework, pernah terlihat beberapa kasus mengkhawatirkan tentang drive ini yang tiba-tiba mati atau tidak bisa boot
  • Pada hari yang sama, SK Hynix P41 SSD dan Sabrent NVMe enclosure dikirim dari Amazon dalam sekitar 3 jam

Bacaan terkait

1 komentar

 
GN⁺ 2023-08-24
Komentar Hacker News

  • Karena menggunakan ZFS, bisa dibilang persiapannya lebih baik dibanding pengguna SSD WD atau SanDisk lainnya
    https://petapixel.com/2023/08/08/sandisk-portable-ssds-are-failing-so-frequently-we-can-no-longer-recommend-them/
    https://www.theverge.com/22291828/sandisk-extreme-pro-portable-my-passport-failure-continued
    https://news.ycombinator.com/item?id=37042587
    https://www.theverge.com/23837513/western-digital-sandisk-ssd-corrupted-deleted-questions
    https://news.ycombinator.com/item?id=37188736

  • Tepat sebelum sepenuhnya meninggalkan dunia Linux, saya mulai sedikit demi sedikit menggali gunung es bernama btrfs, dan ternyata cukup menarik
    Potensinya terlihat besar di berbagai fitur seperti inovasi backup dan konfigurasi disk. btrfs memang bukan ZFS, tetapi ada bagian fitur yang tumpang tindih, dan bisa dibilang mendekati “ZFS untuk orang miskin”. Selain itu, ZFS punya posisi yang agak ambigu soal lisensi, packaging, dan status penyertaan di dalam kernel, jadi pada sistem operasi tertentu btrfs berjalan jauh lebih masuk akal
    Pernah di Linux User Group saya bilang bahwa saya harus mencabut kabel listrik untuk me-reboot komputer, lalu saya dimarahi habis-habisan karena tindakan bodoh itu dan disarankan memakai ZFS. Namun kalau mengingat sistem itu adalah Raspberry Pi, mungkin penilaian soal mana dari dua tindakan itu yang bijak bisa berubah

    • Memang katanya Pi bisa mengalami kerusakan filesystem, tetapi setiap kali memasang image saya menjalankan skrip yang memasang tmpfs di sana-sini dan mematikan sebagian besar log yang tidak berguna, jadi saya belum pernah melihatnya sendiri
      Selama tidak menyiksa kartu SD, perangkat seperti ini terus berjalan dengan sangat stabil. ZFS memang terlihat sangat keren, tetapi sekalipun suatu hari saya membeli NAS, rasanya saya tidak ingin mengeluarkan uang untuk perangkat yang bisa menjalankan ZFS, jadi kemungkinan saya akan memakai RAID dan ext4 saja
      Saya terus menghindari btrfs karena tiap beberapa bulan melihat tulisan “BTRFS menghapus data saya”, lalu melihat perdebatan berlanjut soal apakah itu salah btrfs atau bukan. Belakangan sepertinya tulisan seperti itu makin jarang terlihat, jadi mungkin sudah waktunya melirik lagi
    • Sekadar penasaran, apa yang membuat Anda sepenuhnya meninggalkan dunia Linux? Apa yang bisa dipelajari “komunitas” dari pengalaman itu agar bisa menjadi lebih baik bagi orang lain?
    • Satu-satunya hal yang benar-benar tidak saya sukai dari btrfs adalah ia mudah mengalami fragmentasi
      Terutama pada image VM sparse, dan menurut saya zvol jauh lebih baik untuk penggunaan itu

  • Beberapa tahun lalu ada krisis kapasitor, sekarang rasanya kita mengalami krisis media penyimpanan
    Rasanya konyol bahwa semua media penyimpanan makin lama makin buruk. WD merusak HDD dengan SMR, dan para produsen mengatakan masa operasi 3 tahun untuk SSD dan HDD sudah terlalu lama—ini bukan bercanda. Tahun ini saja satu SSD Kingston mati, dan mungkin bisa dimaklumi karena usianya sekitar 8 tahun, tetapi HDD portabel WD juga mati setelah kira-kira 2 tahun
    Internet sekarang penuh dengan masalah kehilangan data dan umur pakai. HDD 20 tahun lalu juga bukan barang yang bisa dipakai selamanya, tetapi setidaknya saya ingat ia jelas bertahan lebih lama daripada umur manfaat komputer yang dibeli bersamanya

    • Hard disk zaman sekarang jauh lebih beruntung daripada 20 tahun lalu
      Dua puluh tahun lalu adalah era drive IBM Deathstar yang terkenal buruk, ketika lapisan magnetiknya benar-benar terkelupas dari platter. Ada juga drive Maxtor mengerikan yang mati dalam 1–2 tahun, dan setelah Seagate mengakuisisi Maxtor, drive Seagate juga sempat menjadi tidak stabil. Saat mengoperasikan server dengan sekitar 8 disk, saya harus terus mengganti kira-kira satu disk per tahun
      Sebaliknya, sekarang saya membantu mengelola server ZFS dengan lebih dari 20 drive, dan umur drive kira-kira 4–5 tahun. Selain itu, komputer waktu itu menjadi usang jauh lebih cepat. Sekarang komputer berusia 6 tahun masih cukup layak dipakai, tetapi dulu komputer berusia 3 tahun saja sudah sangat terasa tua
    • Tidak perlu khawatir. Sebentar lagi chip juga akan mulai bermasalah setelah beberapa tahun
      Kita sedang mentok di batas penskalaan, dan pertumbuhan eksponensial melambat
    • Secara pribadi, saya ingat dulu HDD milik saya dan orang-orang di sekitar saya kadang rusak
      Sekarang hal seperti itu hampir tidak terjadi pada SSD. Bahkan SSD Intel lama dari akhir 2000-an yang dikenal bermasalah pun masih berfungsi baik di MacBook tua yang sama, yang saya pakai beberapa tahun lalu saya berikan kepada ibu saya. Saya penasaran seperti apa data sebenarnya
    • Semua drive WD yang saya beli dalam 10 tahun terakhir bekerja sesuai harapan. Termasuk yang untuk NAS yang dibeli setelah pengenalan SMR, karena saya memastikan itu Plus atau Pro, bukan Red biasa
      Untuk SSD saya juga cukup beruntung, tetapi di desktop saya masih cenderung menaruh direktori /home dan array RAID di drive putar lama, jadi hanya memakai SSD kecil
      Ada dua pengecualian. Saya mencabut dua WD Red pra-SMR dari NAS lama untuk menggantinya dengan disk yang lebih besar, lalu menyimpannya dalam kondisi sepenuhnya normal di kantong antistatis di laci. Sekitar 2,5 tahun kemudian, saat butuh disk cadangan dan saya keluarkan untuk diperiksa, keduanya tidak berfungsi; satu benar-benar mati, dan yang satu lagi hanya nyaris terdeteksi tetapi tidak bisa dibaca. Yang pertama sama sekali tidak muncul saat disambungkan, dan meski saya membersihkan semua kontak termasuk pin PCB controller, tidak ada gunanya, jadi akhirnya saya buang. Yang kedua baru bisa dipakai lagi setelah diformat ulang penuh, tetapi bahkan dengan testdisk tidak ada cara memulihkan data lama. Saya belum pernah mengalami atau memperkirakan hal seperti ini, jadi sejujurnya cukup mengkhawatirkan
    • Sekitar 20 tahun lalu juga ada HGST “Deathstar”, drive yang sangat buruk sampai memicu gugatan class action
      Disk memang selalu mati secara acak, dan itu juga salah satu alasan Sun membuat ZFS

  • Ringkasnya, thread Mastodon itu menunjuk ke https://zrepl.github.io
    “zrepl adalah solusi terpadu satu atap untuk replikasi ZFS”

    • Selain fakta bahwa zrepl ditulis dalam Go dan sanoid/syncoid adalah skrip Perl, adakah yang tahu apa perbedaan zrepl dan sanoid/syncoid?
    • Sepertinya harus berkomunikasi dengan daemon yang berjalan di server penyimpanan
      Misalnya, akan keren kalau S3 bisa langsung dipakai sebagai storage

  • Zrepl adalah salah satu alasan besar saya bisa menjalani hidup digital nomad dengan tenang
    Setiap malam, sebuah skrip yang dijalankan kira-kira sekali membuka pool ZFS yang dilindungi LUKS dengan header terpisah, lalu menyalin semua snapshot. Enclosure NVME itu selalu ada di “tas” yang tidak pernah lepas dari saya
    Berkat konfigurasi ini dan NixOS, saya bisa mem-provision laptop baru yang identik dalam sekitar 10 menit. Baru-baru ini saya juga menambahkan replikasi offsite, jadi bahkan kalau saya dirampok secara sangat parah sekalipun, kemungkinan kehilangan data serius hampir mendekati 0
    Zrepl benar-benar perangkat lunak yang luar biasa. Mudah mulai digunakan, tetapi cukup canggih dan kuat untuk mengutak-atik semua titik pengaturan jika diperlukan. Rasanya pujian apa pun masih kurang

    • Kedengarannya Anda jauh lebih aman daripada kebanyakan orang yang bisa habis hanya karena satu pencurian, kebakaran, banjir, atau bencana lain
    • Pernah memakai sanoid/syncoid? Dibandingkan keduanya, apa yang Zrepl berikan lebih banyak?
    • Akan bagus kalau Anda menulis bagaimana konfigurasi ini bekerja. Kedengarannya cukup menarik

  • Mungkinkah pengambilan snapshot setiap 10 menit pada filesystem ikut memengaruhi matinya SSD?

    • ZFS itu khusus, dan karena memakai copy-on-write, biaya membuat snapshot rendah
      Secara intuitif, meski snapshot diambil sangat sering, jumlah penulisan tambahan sepertinya cukup kecil. Namun akan bagus kalau ada pengukuran yang ilmiah
      Dulu di beberapa server yang saya kelola, saya mengambil snapshot ZFS setiap menit, setiap jam, dan setiap hari. Snapshot per menit dihapus setelah 60 menit, dan snapshot per jam serta per hari dibackup lewat job cron di mesin lain. Snapshot per jam disimpan kira-kira 72 jam, dan snapshot harian dibuat untuk disimpan permanen. Snapshot per menit tujuannya untuk membatalkan kesalahan manual saat migrasi SQL, dan itu bekerja dengan baik
      Sekarang pun saya memakai ZFS di server FreeBSD, tetapi proyek-proyek saat ini trafiknya rendah dan perubahan data penting juga jarang, jadi di server pribadi saya kira-kira seminggu sekali mengambil snapshot secara manual dan memicu backup secara manual dari server lain. Selain itu, sekarang saya hanya men-snapshot bagian filesystem yang berisi database PostgreSQL dan data aplikasi. Data sistem operasi tidak lagi terlalu saya pedulikan. Kalau terjadi kerusakan hardware serius, saya akan menginstal ulang OS; nilai konfigurasi penting saya catat, dan saat skrip backup berjalan saya buat agar menyalin nilai-nilai itu alih-alih berbagai hal remeh lain
    • Kemungkinannya rendah
      Snapshot tidak banyak melakukan penulisan, dan baik SSD maupun ZFS sama-sama memakai cara copy-on-write. Artinya, biaya penulisan setelah snapshot sama seperti sebelum snapshot
      Namun konteksnya kurang. Baik SSD maupun ZFS tidak suka kondisi penuh atau hampir penuh. Kalau data kerja sekitar 650GB dan drive-nya 1TB, snapshot bisa dengan mudah membuat pemakaian drive melewati 90%. Hal itu saja mungkin sudah membuat ZFS tidak nyaman
    • Sepemahaman saya, mengambil snapshot di ZFS berarti menulis objek metadata dan sebagian referensi data
      Jika diasumsikan data 100GB, ukuran blok 128K, dan pointer 64-bit, data baru yang ditulis selama snapshot kira-kira hanya sekitar 5MB. Kalau ini dilakukan 6 kali per jam, 52.560 kali per tahun, apakah cukup untuk menyebabkan keausan drive lebih awal? Hasilnya sekitar 256GB per tahun. Kemungkinan besar ini kurang dari 1% daya tahan tulis SSD. Jadi kalau snapshot tiap 10 menit adalah penyebab pentingnya, saya akan terkejut
      Bisa saja saya keliru, dan estimasi ini saya buat dengan meminta bantuan dari sumber yang tidak terlalu dapat dipercaya. Koreksi dipersilakan. Namun jika estimasi saya ternyata lebih tinggi daripada kenyataan, dan meski begitu kecil kemungkinan memengaruhi umur pakai, poinnya sendiri mungkin tidak terlalu berarti
    • Kemungkinannya rendah. Snapshot pada dasarnya menandai blok yang paling baru ditulis dan mencegah blok lama diubah
      Karena ZFS adalah copy-on-write, perubahan file menimbulkan penulisan yang sama, hanya saja sebagian data lama tidak dihapus
    • Menurut komentar di sebuah situs web oranye acak[1], ukuran tulis minimum chip flash modern mungkin sekitar 100MB
      Maka penulisan 5MB setiap 10 menit sebenarnya menjadi 600MB per jam, 4,8TB untuk hari kerja 8 jam, 24TB untuk 40 jam per minggu, dan pada drive 1TB menjadi 3,43 DWPD secara waktu nyata, atau 2500TBW selama 2 tahun waktu nyata[2]
      Ketahanan tulis resmi SN850 adalah 600TBW, tetapi karena urusan garansi, tentu saja angka itu mungkin dibuat konservatif rendah. Kebetulan 2500TB juga merupakan angka ketahanan yang umum di banyak SSD di pasar ini. Secara keseluruhan, kedengarannya bukan sesuatu yang sepenuhnya mustahil
      Kalau masih hidup, saya penasaran apa kata controller di data SMART. Di Linux, jalankan apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sda, lalu seharusnya keluar tabel[4]. Di Windows, pasang CrystalDiskInfo[3]
      1: https://news.ycombinator.com/item?id=29165202
      2: DWPD: drive writes per day, TBW: Total Bytes Written - in terabytes
      3: https://crystalmark.info/en/software/crystaldiskinfo/
      4: “Pre-fail” berarti nilainya seharusnya berubah tepat sebelum gagal, dan “Old_age” berarti nilai yang menunjukkan usia; bukan berarti “ini buruk dan sebentar lagi rusak” atau “drive ini sudah tua”. Semua item selalu menampilkan Pre-fail dan Old_age. Menurut saya, sejak lama seharusnya ada orang yang menggantinya menjadi “somewhat_boolean” dan “life_remain”

  • Saya biasanya melakukan backup inkremental Apple Time Machine ke server disk berputar Synology
    Saat melakukan pekerjaan berisiko atau meng-upgrade mesin, saya juga kadang me-mirror drive internal ke SSD eksternal. Cara ini bekerja dengan baik. Pemulihan Time Machine bisa cukup lambat, tetapi sebagian besar data penting ada di Git dan repositori hosting, jadi itu bukan masalah besar. Kadang saya memakai Time Machine saat ingin mengembalikan satu file
    Saya juga punya salah satu drive SanDisk yang terkenal bermasalah[0], tetapi tidak saya pakai untuk hal penting. Isinya hanya semacam penyimpanan game. Karena saya pengguna Mac, game bukan faktor besar, dan kalau itu mati pun saya tidak akan menangis
    [0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/

    • Saya juga memakai Time Machine. Saya mengambil aplikasi https://tclementdev.com/timemachineeditor/ dan membuatnya memicu backup TM secara manual setiap kali mesin sedang idle
      Rasanya ini bekerja jauh lebih baik daripada backup otomatis Apple atau backup berbasis waktu
    • Saya sudah menyerah dengan Time Machine. Di Synology, bahkan dengan atalk dan semacamnya, hampir tidak pernah berjalan benar lebih dari satu atau dua bulan

  • Snapshot saya dienkripsi di komputer asal. Kerennya, NAS tidak bisa membacanya
    Jadi untuk menulis backup, saya juga harus memulihkan wrapper key enkripsinya. Tidak bohong, rasanya cukup menakutkan sampai saya mendapat konfirmasi pertama bahwa data bisa didekripsi
    Untuk metode backup kustom, jangan berasumsi bahwa itu berfungsi sampai Anda benar-benar memastikan data bisa dipulihkan secara berkala

    • Backup yang tidak kustom pun sama saja
    • Saya selalu hanya berpikir harus menyimpan salinan header LUKS di disk terpisah untuk berjaga-jaga

  • Masa depan dekat Linux di sini adalah bcachefs
    https://bcachefs.org/

    • Apa yang dilakukan bcachefs lebih baik daripada BTRFS atau ZFS?
    • Untuk disebut masa depan dekat, ini sudah dikembangkan selama 7 tahun dan masih belum diterima upstream
      Pekerjaan untuk memasukkannya ke upstream memang sedang berjalan
    • Ada ringkasan singkat kenapa kita harus menantikannya? Ada fitur keren?

  • “Rasanya cukup menakutkan sampai saya mendapat konfirmasi pertama bahwa data bisa didekripsi” terdengar seperti prosedurnya kurang diuji dan kurang didokumentasikan dibanding kondisi ideal
    Ini bukan hal yang sangat jarang pada sistem rumahan atau desktop pribadi. Meski begitu, di server produksi Anda tentu tidak ingin mencari tahu prosedur pemulihan secara dadakan di tempat

    • Benar. Saya tahu semua bahan yang dibutuhkan untuk pemulihan ada, dan sudah pernah mengujinya 6 bulan lalu, tetapi awalnya saya menyalin kunci yang salah
      Saat gagal dimuat, sempat terasa suram, tetapi saya segera menyadari kesalahannya. Pada momen kegagalan seperti ini, ada semacam kejernihan ketika semua celah dalam proses menjadi sangat jelas