ZFS sayesinde veri kaybı yalnızca 10 dakikalık bölümle sınırlı kaldı

 (mastodon.social)
3 puan yazan GN⁺ 2023-08-24 | 1 yorum | WhatsApp'ta paylaş
  • 2 yıllık SSD aniden öldü, ancak ZFS artımlı çoğaltma sayesinde sistem yeni sürücüde yeniden ayağa kaldırıldı ve gerçek kayıp yaklaşık 10 dakikalık bölümle sınırlı kaldı
  • Tüm dosya sistemini her 10 dakikada bir snapshot alıp NAS’a gönderen bir yapı vardı; otomasyon için zrepl kullanıldı
  • Snapshot’lar çalışan sistemin belirli bir andaki durumunu kaydedip yalnızca değişiklikleri aktararak, ev ağında bile arka planda çoğaltmayı mümkün kıldı
  • Geri yükleme süreci, 625GiB ZFS receive işlemini gece boyunca çalıştırmayı ve şifreleme wrapper key’ini de geri yüklemeyi gerektirdiği için otomatik kurtarmadan oldukça uzaktı
  • ZFS’in ilk kurulum ve bakım yükü yüksek olsa da, gerçek bir sürücü arızasında çalışma durumunu bile geri getiren felaket kurtarma etkisini gösterdi

SSD arızasından sonra kalan kayıp 10 dakika

  • Dizüstü bilgisayarı e-posta göndermek için açtığı anda ekranın siyah halde donmuş olduğu görüldü; yeniden başlatmadan sonra 2 yıllık SSD’nin ölmüş olduğu doğrulandı
  • Sistem yeni sürücüye geri yüklendikten sonra tekrar kullanılabilir hale geldi ve toplam veri kaybı yaklaşık 10 dakikalık bölümle sınırlı kaldı
  • Kurtarılan dizüstü bilgisayar, işin kesildiği noktadan açıldı; tarayıcı sekmeleri de önceki geceden kalan tamamlanmamış işi geri getirdi
  • 12 yıl önceki Chromebook reklamındaki, yeni cihazda önceki durumdan devam etme fikri bu arıza durumunda gerçekten çalıştı

Yedekten çok çoğaltmaya yakın bir yapı

  • Sürücüyü basitçe yedeklemek yerine tüm dosya sistemini çoğaltma yöntemi kullanıldı
  • Geçen kış yaratıcı işler için kullanılan bilgisayarların periyodik yedekleri amacıyla ev ağı depolaması kuruldu ve çeşitli seçenekler arasından ZFS artımlı çoğaltma seçildi
  • ZFS, çalışan bir sistemde bile belirli bir ana ait snapshot’ları verimli biçimde oluşturabilir
  • Sonrasında başka bir makineye gönderirken tüm veriyi tekrar tekrar aktarmak yerine yalnızca değişen verileri aktarır

zrepl ile her 10 dakikada bir NAS’a aktarım

  • Snapshot oluşturma ve NAS’a aktarımı otomatikleştirmek için zrepl kullanıldı
  • Yapılandırma, tüm dosya sisteminin her 10 dakikada bir snapshot’ının alınıp aktarılması şeklindeydi
  • Artımlı snapshot’lar sayesinde ev ağında arka planda çalışırken bile kopya güncel tutulabildi
  • Son çalıştırmada aktarım 14 saniye sürdü ve yaklaşık 64MiB gönderildi

Geri yükleme sürecinde ortaya çıkan manuel iş yükü

  • Sistem geri yükleme, öğrenme gerektiren bir süreçti ve büyük ölçüde manuel çalışmaya dayanıyordu
  • 625GiB ZFS receive işleminin gece boyunca çalıştırılması gerekti
  • Snapshot’lar kaynak bilgisayar tarafından şifrelenmiş halde olduğu için NAS içerikleri okuyamıyordu
  • Yedeği gerçekten kullanabilmek için şifreleme wrapper key’inin de geri yüklenmesi gerekiyordu
  • Verilerin çözülebileceğine dair ilk doğrulama gelene kadar geri yükleme süreci çok stresliydi

Kurulum maliyeti ve donanım değişimi

  • ZFS’in ilk kurulumu tüm dosya sisteminin değiştirilmesini gerektirdiği için başlangıç maliyeti yüksekti
  • Bakım için ciddi ilgili bilgi gerekiyor ve operasyonel süreçler manuel adımlar içeriyor
  • Yine de SSD ilk kez arızalanmadan önce çoğaltmanın ayarlanmış olması şanstı ve bu örnekte ZFS’in avantajları ortaya çıktı
  • Ölen sürücü, asıl Framework siparişine dahil olan WD_BLACK SN850 idi
    • Framework forumunda bu sürücünün aniden öldüğüne veya önyüklenemez hale geldiğine dair endişe verici örnekler görülmüştü
  • Aynı gün Amazon’dan SK Hynix P41 SSD ve Sabrent NVMe enclosure yaklaşık 3 saat içinde teslim alındı

İlgili okumalar

1 yorum

 
GN⁺ 2023-08-24
Hacker News yorumları

  • ZFS kullandığı için diğer WD veya SanDisk SSD kullanıcılarına göre daha iyi hazırlıklı sayılır
    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

  • Linux dünyasını tamamen terk etmeden hemen önce btrfs denen buzdağını biraz kurcalamaya başlamıştım; epey ilginçti
    Yedekleme yenilikleri, disk yapılandırması gibi birçok özellikte büyük potansiyel taşıyor gibi görünüyordu. btrfs, ZFS değil ama işlevsel olarak çakışan tarafları var ve bir bakıma “fakirin ZFS’si”ne daha yakın. Ayrıca ZFS’in lisanslama, paketleme ve çekirdeğe dâhil edilme durumu biraz muğlak olduğundan, belirli işletim sistemlerinde btrfs çok daha mantıklı çalışıyor
    Linux User Group’ta bilgisayarı yeniden başlatmak için güç kablosunu çekmek zorunda kaldığımı söylemiştim; bu aptalca hareket yüzünden fena azar işitmiş ve ZFS kullanmam önerilmişti. Ancak o sistemin Raspberry Pi olduğu düşünülürse, bu iki davranıştan hangisinin daha akıllıca olduğu konusundaki fikirler değişebilir

    • Pi’de dosya sistemi bozulması olabileceği söylenir ama her imaj kurduğumda çeşitli yerlere tmpfs bağlayan ve çoğu işe yaramaz logu kapatan bir betik çalıştırdığım için bunu bizzat hiç görmedim
      SD kartı zorlamadığınız sürece bu cihazlar son derece kararlı biçimde çalışmaya devam ediyor. ZFS gerçekten harika görünüyor ama bir gün NAS alsam bile ZFS çalıştırabilecek bir cihaza para harcamak isteyeceğimi sanmıyorum; muhtemelen sadece RAID ve ext4 kullanırım
      btrfs’ten ise birkaç ayda bir “BTRFS verilerimi uçurdu” yazıları gördüğüm ve bunun btrfs’in hatası olup olmadığı tartışmalarının sürdüğünü izlediğim için uzak durdum. Son zamanlarda böyle yazıları daha az görüyor gibiyim; belki de yeniden bakmanın zamanı gelmiştir
    • Meraktan soruyorum: Linux dünyasını tamamen terk etmenize ne sebep oldu? “Topluluğun” başkaları için daha iyi olabilmesi adına bu deneyimden ne öğrenilebilir?
    • btrfs’te gerçekten hoşuma gitmeyen tek şey parçalanmaya yatkın olması
      Özellikle seyrek VM imajlarında böyle; o kullanım için zvol’un çok daha iyi olduğunu düşünüyorum

  • Birkaç yıl önce kapasitör krizi vardı; şimdi de depolama krizi mi yaşıyoruz diye düşünüyorum
    Tüm depolama cihazlarının giderek kötüleşmesi saçma bir hâl alıyor. WD, SMR ile HDD’leri mahvediyor; üreticiler SSD ve HDD’lerin 3 yıllık çalışma süresinin zaten fazla uzun olduğunu söylüyor, şaka değil. Sadece bu yıl bir Kingston SSD öldü; onun yaklaşık 8 yıllık olduğunu varsayalım, ama taşınabilir bir WD HDD de yaklaşık 2 yıl içinde öldü
    Bugünlerde internet veri kaybı ve ömür sorunlarıyla dolu. 20 yıl önce HDD’ler de sonsuza kadar kullanılacak şeyler değildi ama en azından birlikte satın alınan bilgisayarın faydalı ömründen kesinlikle daha uzun dayandıklarını hatırlıyorum

    • Günümüz sabit diskleri, 20 yıl öncesine göre çok daha şanslı
      20 yıl önce, manyetik kaplaması plakalardan kelimenin tam anlamıyla dökülen kötü şöhretli IBM Deathstar disklerinin dönemiydi. 1-2 yıl içinde ölen berbat Maxtor diskler de vardı; Seagate Maxtor’u satın aldıktan sonra bir süre Seagate diskler de güvensizleşti. Yaklaşık 8 diskli bir sunucu işletirken yılda yaklaşık bir tanesini sürekli değiştirmek zorunda kalıyordum
      Buna karşılık şimdi 20’den fazla diski olan bir ZFS sunucusunun yönetimine yardım ediyorum ve disk ömürleri kabaca 4-5 yıl civarında. Ayrıca o dönemde bilgisayarlar çok daha hızlı eskiyordu. Bugün 6 yıllık bir bilgisayar gayet kullanılabilir olabiliyor ama o zaman 3 yıllık bir bilgisayar bile belirgin biçimde eski hissettirirdi
    • Endişelenmeye gerek yok. Yakında çipler de birkaç yıl geçince hatalı çalışmaya başlayacak
      Ölçekleme sınırlarına dayanıyoruz ve üstel büyüme yavaşlıyor
    • Kişisel olarak eskiden de benim ve çevremdekilerin HDD’lerinin zaman zaman bozulduğunu hatırlıyorum
      Şimdi SSD’lerde bu neredeyse hiç olmuyor. Hatta sorunlu olduğu bilinen 2000’lerin sonlarından kalma eski bir Intel SSD bile, birkaç yıl kullandıktan sonra anneme verdiğim aynı eski MacBook’un içinde hâlâ sorunsuz çalışıyor. Gerçek verilerin ne durumda olduğunu merak ediyorum
    • Son 10 yılda aldığım WD disklerin hepsi beklendiği gibi çalıştı. SMR’ın devreye girmesinden sonra aldığım NAS diskleri de buna dâhil; çünkü düz Red değil, Plus ya da Pro olduklarından emin oldum
      SSD konusunda da şanslıydım ama masaüstünde hâlâ /home dizinini ve RAID dizisini eski dönen disklerde tutma eğilimindeyim, bu yüzden yalnızca küçük SSD’ler kullanıyorum
      İki istisna vardı. SMR öncesi iki WD Red’i daha büyük disklerle değiştirmek için eski NAS’tan çıkardım; tamamen sağlam hâlde antistatik poşetlere koyup çekmecede sakladım. Yaklaşık 2,5 yıl sonra yedek disk gerektiğinde çıkarıp kontrol ettim; ikisi de çalışmıyordu. Biri tamamen ölmüştü, diğeri ise ancak algılanıyor ama okunamıyordu. İlki bağlayınca hiç görünmedi; denetleyici PCB pinleri dâhil tüm temas noktalarını temizledim ama fayda etmedi, sonunda attım. İkincisi ancak tam yeniden biçimlendirmeden sonra yeniden kullanılabilir hâle geldi; testdisk kullansam da eski verileri kurtarmanın yolu yoktu. Böyle bir şey ne yaşamıştım ne de bekliyordum; açıkçası epey endişe verici
    • Yaklaşık 20 yıl önce HGST “Deathstar” da vardı; toplu davaya konu olacak kadar kötü disklerdi
      Diskler her zaman rastgele ölürdü ve Sun’ın ZFS’i yaratmasının nedenlerinden biri de buydu

  • Çok kısa özetle, Mastodon başlığı https://zrepl.github.io adresine işaret ediyor
    “zrepl, ZFS replikasyonu için entegre, tek durak bir çözüm”

    • zrepl’in Go ile yazılmış olması ve sanoid/syncoid’in Perl betikleri olması dışında, zrepl ile sanoid/syncoid arasında nasıl farklar olduğunu bilen var mı?
    • Depolama sunucusunda çalışan bir daemon ile iletişim kurması gerekiyormuş gibi görünüyor
      Örneğin S3’ü doğrudan depo olarak kullanabilmek harika olurdu

  • Zrepl, dijital göçebe hayatını içim rahat şekilde sürdürebilmemin büyük nedenlerinden biri
    Geceleri yaklaşık bir kez çalışan bir betik, ayrı bir header’a sahip LUKS korumalı ZFS havuzunu açıyor ve tüm snapshot’ları kopyalıyor. O NVME kutusu her zaman bedenimden ayrılmayan “çantanın” içinde
    Bu kurulum ve NixOS sayesinde aynı yeni dizüstünü yaklaşık 10 dakikada provision edebiliyorum. Yakın zamanda offsite replikasyon da ekledim; tamamen fena şekilde soyulsam bile ciddi veri kaybı olasılığı neredeyse sıfıra yakın
    Zrepl gerçekten mükemmel bir yazılım. Başlaması kolay ama gerektiğinde tüm ayar noktalarına dokunabileceğiniz kadar incelikli ve güçlü. Ne kadar övsem az

    • Hırsızlık, yangın, sel ya da başka bir felaketle her şeyi bitecek çoğu insandan çok daha güvende gibi görünüyorsunuz
    • sanoid/syncoid kullandınız mı? Onlara kıyasla Zrepl ne fazlasını sunuyor?
    • Bu kurulumun nasıl çalıştığını yazsanız güzel olurdu. Kulağa oldukça ilginç geliyor

  • Dosya sisteminin her 10 dakikada bir anlık görüntüsünü almış olmak SSD'nin ölmesine katkıda bulunmuş olabilir mi?

    • ZFS özel bir sistem ve yazarken kopyalama kullandığı için anlık görüntü oluşturma maliyeti düşük
      Sezgisel olarak, çok sık anlık görüntü alınsa bile ek yazma miktarı epey az olacak gibi geliyor. Yine de bilimsel bir ölçüm olsa iyi olurdu
      Eskiden yönettiğim bazı sunucularda ZFS ile her dakika, her saat ve her gün anlık görüntü alıyordum. Dakikalık anlık görüntüleri 60 dakika sonra siliyordum; başka bir makinedeki cron işiyle saatlik ve günlük anlık görüntüleri yedekliyordum. Saatlik anlık görüntüleri yaklaşık 72 saat tutuyor, günlük anlık görüntüleri kalıcı olarak saklayacak şekilde ayarlıyordum. Dakikalık anlık görüntülerin amacı SQL migration sırasında yapılan manuel hataları geri almaktı ve iyi çalışıyordu
      Şu anda da FreeBSD sunucusunda ZFS kullanıyorum, ancak mevcut projeler düşük trafikli ve önemli veri değişiklikleri de nadir olduğundan kişisel sunucuda yaklaşık haftada bir kez manuel anlık görüntü alıyor ve başka bir sunucudan yedeklemeyi manuel tetikliyorum. Ayrıca artık yalnızca PostgreSQL veritabanı ve uygulama verilerinin bulunduğu dosya sistemi bölümünün anlık görüntüsünü alıyorum. İşletim sistemi verilerini artık pek umursamıyorum. Ciddi bir donanım arızası olursa OS'i yeniden kurar, önemli ayarları kaydederim; yedekleme betiği çalıştığında da başka ıvır zıvır yerine bu değerleri kopyalayacak şekilde ayarladım
    • Bunun olma ihtimali düşük
      Anlık görüntüler fazla yazmaz ve hem SSD hem de ZFS yazarken kopyalama yöntemini kullanır. Yani anlık görüntüden sonraki yazma maliyeti, anlık görüntüden öncekiyle aynıdır
      Ancak bağlam eksik. Hem SSD hem de ZFS dolu ya da neredeyse dolu olmayı sevmez. Çalışma verisi yaklaşık 650GB ve disk 1TB ise, anlık görüntüler yüzünden disk kullanımı kolayca %90'ın üzerine çıkmış olabilir. Sırf bu bile ZFS'i rahatsız etmiş olabilir
    • Benim anladığım kadarıyla ZFS'te anlık görüntü almak, metadata nesnesi ve bazı veri referansları yazmaktan ibaret
      100GB veri, 128K blok boyutu ve 64 bit işaretçi varsayarsak, anlık görüntü sırasında yeni yazılan verinin kabaca 5MB düzeyinde olacağını düşünüyorum. Bunu saatte 6 kez, yılda 52.560 kez yapmanın diskin erken aşınmasına yol açacak kadar olup olmadığına bakarsak, yılda yaklaşık 256GB eder. Bu muhtemelen SSD yazma dayanıklılığının %1'inden azdır. Bu yüzden 10 dakikalık anlık görüntüler önemli bir neden olsaydı şaşırırdım
      Yanılıyor olabilirim ve pek güvenilir olmayan bir kaynaktan yardım alarak tahmin ettim. Düzeltmelere açığım. Yine de tahminim gerçekte olduğundan yüksekse ve buna rağmen ömre etki etme olasılığı düşükse, tartışmanın kendisi pek anlamlı olmayabilir
    • Olasılık düşük. Anlık görüntü kabaca en son yazılan blokları işaretlemek ve önceki blokların değiştirilmesini engellemektir
      ZFS yazarken kopyalama olduğu için dosya değişikliklerinde aynı yazmalar gerçekleşir; yalnızca bazı eski veriler silinmez
    • Rastgele turuncu bir web sitesindeki bir yoruma[1] göre, modern flash yongalarının minimum yazma boyutu yaklaşık 100MB olabilir
      O zaman her 10 dakikada bir 5MB yazma, gerçekte saatte 600MB; 8 saatlik iş günü için 4,8TB; haftada 40 saat için 24TB olur ve 1TB'lık diskte gerçek zamanlı 3,43 DWPD, 2 yıl gerçek zamanlı kullanımda ise 2500TBW eder[2]
      SN850'nin resmi yazma dayanıklılığı 600TBW, ancak garanti nedeniyle bunun elbette muhafazakâr biçimde düşük tutulmuş bir değer olması muhtemel. Tesadüfen 2500TB de bu pazardaki birçok SSD için yaygın bir dayanıklılık değeri. Genel olarak bakınca tamamen imkânsız gibi gelmiyor
      Hâlâ hayattaysa, kontrolcünün SMART verilerinde ne söylediğini merak ediyorum. Linux'ta apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sda çalıştırılırsa bir tablo basacaktır[4]. Windows'ta CrystalDiskInfo[3] kurulabilir
      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”, değerin arızadan hemen önce değişmesi gerektiği anlamına gelir; “Old_age” ise yaşa ilişkin bir değer olduğu anlamına gelir, “bu kötü ve yakında bozulacak” ya da “bu disk eski” demek değildir. Tüm öğelerde her zaman Pre-fail ve Old_age gösterilir. Bence yıllar önce birileri bunları “somewhat_boolean” ve “life_remain” olarak değiştirmeliydi

  • Ben genelde Apple Time Machine artımlı yedeklemelerini Synology döner diskli sunucuya yapıyorum
    Riskli işler yaparken ya da makineyi yükseltirken, bazen dahili diski harici bir SSD'ye de aynalıyorum. Bu yöntem iyi çalışıyor. Time Machine'den geri yükleme epey yavaş olabiliyor, ancak önemli verilerin çoğu Git ve barındırılan depolarda olduğu için bu büyük bir sorun olmadı. Tek bir dosyayı geri almak istediğimde ara sıra Time Machine kullanıyorum
    Kötü şöhretli[0] SanDisk disklerden birine de sahibim, ama önemli işler için kullanmıyorum. İçinde en fazla oyun depolaması var. Mac kullanıcısı olduğum için oyun büyük bir unsur değil; ölürlerse de ağlamam
    [0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/

    • Ben de Time Machine kullanıyorum. https://tclementdev.com/timemachineeditor/ uygulamasını indirip makine boştayken TM yedeklemesini manuel olarak tetikleyecek şekilde ayarladım
      Apple'ın otomatik yedeklemelerinden ya da zaman tabanlı yedeklemelerinden çok daha iyi çalışıyor gibi görünüyor
    • Ben Time Machine'den vazgeçtim. Synology'de atalk vb. kullanınca bile bir iki aydan uzun süre düzgün çalıştığı pek olmadı

  • Snapshot’larım kaynak bilgisayarda şifreleniyor. NAS’ın okuyamaması güzel
    Bu yüzden yedeği kullanmak için şifreleme wrapper key’ini de geri yüklemem gerekti. Yalan yok, verileri çözebileceğime dair ilk onayı alana kadar epey korkutucuydu
    Özel hazırlanmış bir yedekleme yönteminin gerçekten düzenli olarak verileri geri yükleyebildiğini doğrulamadan çalıştığını varsaymamak gerekir

    • Özel olmayan yedeklemeler için de aynısı geçerli
    • Ne olur ne olmaz diye LUKS header kopyasını ayrı bir diskte tutmam gerektiğini hep düşünürdüm

  • Linux için yakın gelecek burada bcachefs
    https://bcachefs.org/

    • bcachefs, BTRFS veya ZFS’ten neyi daha iyi yapıyor?
    • Yakın gelecek demek için zaten 7 yıldır geliştiriliyor ve hâlâ upstream’e kabul edilmiş değil
      Upstream’e alınması için çalışmalar sürüyor gerçi
    • Neden heyecanlanmamız gerektiğine dair kısa bir özet var mı? Havalı bir özelliği falan mı var?

  • “Verileri çözebileceğime dair ilk onayı alana kadar epey korkutucuydu” demek, sürecin idealden daha az test edilmiş ve daha az belgelenmiş olduğu anlamına geliyor gibi
    Ev sistemleri veya kişisel masaüstlerinde çok nadir bir durum değil. Yine de prodüksiyon sunucusunda geri yükleme prosedürünü o anda doğaçlama çözmek istemezsiniz

    • Doğru. Geri yükleme için gereken malzemelerin hepsinin bende olduğunu biliyordum ve 6 ay önce bir kez test de etmiştim, ama başta yanlış anahtarı kopyalamışım
      Yükleme başarısız olunca kısa süreliğine içim karardı ama hemen hatamı fark ettim. Böyle arıza anlarında, tüm süreçteki boşlukların göz kamaştırıcı biçimde belirginleştiği türden bir berraklık geliyor