31Jul

Hasar Hakkında Bir Uyarı Olmadan Sabit Sürücülerdeki Veriler Düşebilir mi?

click fraud protection

Hepimiz veri ve dosyalarımızı güvende ve sağlam tutmak için endişeleniyoruz, ancak verilerin zarar görmesi ve bir kullanıcı tarafından herhangi bir bildirim veya uyarı yapılmadan erişilebilmesi mümkün müdür? Bugünün Süper Kullanıcısı Q & A postasında endişeli bir okuyucu sorusunun yanıtı var.

Bugünkü Soru &Yanıt oturumu bize Q & A web sitelerinin topluluk temelli bir gruplandırması olan Stack Exchange'in bir alt bölümü olan SuperUser nezaketen geliyor.

Fotoğrafın genelleştirilmesi( Flickr).

Soru

SuperUser okuyucu topo morto, sabit disklerdeki verilerin bozulabileceğini ve zararla ilgili bir uyarı yapılmadan erişilebileceğini bilmek istiyor:

Sabit sürücünün fiziksel olarak bozulmasının, bir dosyanın içeriğinde bitlerin "çevrim" yapmasına neden olabilir mi?İşletim sistemi değişikliği fark etmeden ve dosyayı okurken kullanıcıyı bu konuda bilgilendirmeden?Örneğin, bir ASCII metin dosyasındaki bir "p"( ikili 01110000) bir "q"( ikili 01110001) olarak değişebilir mi, ardından bir kullanıcı dosyayı açtığında bir arızanın farkında olmadan "q" görürler mi?

instagram viewer

FAT, NTFS veya ReFS ile ilgili cevaplarla ilgileniyorum( fark yaratıyorsa).İşletim sistemlerinin kullanıcıları bu durumdan mı koruduklarını mı, yoksa verilerin zamanla kopyalar arasındaki farklılıkları kontrol ettiğini mi bilmek istiyorum.

Sabit disk sürücülerindeki veriler bozulabilir ve hasar hakkında bir uyarı yapılmadan erişilebilir mi?

Cevap

SuperUser katılımcısı Guntram Blohm'un bize cevabı var:

Evet, bit rot olarak adlandırılan bir şey var. Ancak hayır, kullanıcıyı fark etmeden etkilemez.

Bir sabit sürücü plakalara bir sektör yazarken, sadece bitleri RAM'de saklandığı gibi yazmaz, aynı bitin aynı uzunluğa sahip çok uzun dizisi olmadığından emin olmak için bir kodlama kullanır. Ayrıca, birkaç biti etkileyen hataları onarmasına ve birkaç biti etkileyen hataları algılamasına izin veren ECC kodları ekler.

Sabit disk sürücüsü sektörü okurken, bu ECC kodlarını kontrol eder ve gerektiğinde verileri onarır( mümkünse).Daha sonra neler olacağı, sürücünün şartnamesinden etkilenen şartlara ve sabit sürücünün sabit yazılımına bağlıdır.

  • Bir sektör okunabilir ve hiçbir ECC kodu problemi bulunmuyorsa, o zaman işletim sistemine geçilir.
  • Bir sektör kolayca onarıldığında, tamir edilen versiyon, diske yazılabilir, okunur ve daha sonra hatanın rasgele olup olmadığını( yani, kozmik ışınlar vb.) Belirlemek için veya ortamla ilgili sistematik bir hata varsa doğrulanabilir.
  • Sabit disk, ortamla ilgili bir hata olduğunu tespit ederse, sektörü yeniden ayırır.
  • Bir okuma, birkaç okuma girişiminden sonra( RAID sabit sürücü olarak belirlenmiş bir sabit sürücüde) okunamıyorsa veya düzeltilemiyorsa, sabit disk vazgeçer, sektörü yeniden ayırır ve denetleyiciye birsorun. Sektörü diğer RAID üyelerinden yeniden yapılandırmak için RAID denetleyicisine güveniyor ve başarısız sabit sürücüye geri yazıyor ve başarısız sabit sürücüye bunu yeniden ayrılan sektörde saklar( umarım bir sorun yaşamaz).
  • Bir sınıra bir masaüstündeki sabit diskte okunamıyor veya düzeltilemiyorsa, sabit disk okumak için daha fazla girişimde bulunacak. Sabit disk sürücüsünün kalitesine bağlı olarak, kafanın yeniden konumlandırılması, art arda okunduğunda çevrilen bitlerin olup olmadığını kontrol etmesi, hangi bitlerin en zayıf olduğunu kontrol etmesi ve bir kaç şey daha kontrol etmesi gerekebilir. Bu denemelerden herhangi biri başarılı olursa, sabit sürücü sektörü yeniden tahsis edecek ve onarılan verileri geri yazacaktır.

Bu, "masaüstü", "NAS / RAID" veya "video gözetim" sabit diskleri olarak satılan sabit sürücüler arasındaki temel farklardan biridir. Bir RAID sabit disk sürücüsü, hızlı bir şekilde vazgeçebilir ve kullanıcı tarafında gecikmeyi önlemek için denetleyiciyi onarabilir. Bir masaüstü sabit disk sürücüsü, kullanıcıyı birkaç saniye beklemek zorunda kaldıklarından, verilerin kaybolduğunu söylemekten çok daha iyi olacağından tekrar tekrar denemeye devam edecektir. Ve bir video sabit disk, hasar gören bir çerçeve olarak hata gidermekten daha fazla sabit veri oranlarına sahiptir ve genellikle fark edilmeyecektir.

Herhangi bir oranda, sabit disk, çürümeye karşı dayanıklılığın olup olmadığını anlayacak ve normalde kurtaracaktır ve yapamıyorsa, hangi sürücüye işletim sistemine söyleyeceğini söyleyecektir. Ardından, hatayı kullanıcıya göstermek ve üzerinde işlem yapmak işletim sistemine bağlıdır. Bu nedenle cybernard şunları söylüyor:

  • Hiçbir zaman tek bir hataya şahit olmadım, ancak tüm sektörlerin başarısız olduğu birçok sabit disk gördüm.

Sabit disk, bir sektörde bir sorun olup olmadığını bilecek, ancak hangi bitlerin başarısız olduğunu bilmeyecektir. Başarısız olan tek bir bit her zaman ECC tarafından yakalanacaktır.

Lütfen otomatik olarak kendiliğinden onaran chkdsk ve dosya sistemleri, dosyalar içindeki verileri onarmak için bir adım atmadığına dikkat edin. Bunlar, dizin girişi ile tahsis edilen blokların sayısı arasındaki bir dosyanın boyutundaki bir farklılık gibi, dosya sistemi yapısında yolsuzluğa hedefleniyor. NTFS'nin kendini iyileştirici özelliği, yapısal hasarı algılar ve verilerinizi daha fazla etkilemesini önler, ancak zaten hasar gören verileri tamir etmez.

Elbette, verilerin hasar görmesine neden olan diğer nedenler vardır.Örneğin, bir denetleyicideki hatalı RAM, sabit sürücüye gönderilmeden önce verileri değiştirebilir. Bu durumda, sabit sürücüdeki hiçbir mekanizma veriyi algılayamaz veya onaramaz; bu, dosya sisteminin yapısının hasar görmesinin bir nedeni olabilir. Diğer nedenler arasında, yazılım hataları, sabit sürücüye yazarken gözlem karartmaları( dosya sistemi günlüğü ile giderilmesine rağmen) veya hatalı dosya sistemi sürücüleri( NTFS ters mühendislikten bu yana Linux'ta NTFS sürücüsü varsayılan olarak salt okunur durumdadır)belgelenmemiş ve geliştiriciler kendi kodlarına güvenmiyor).

  • Bu senaryoyu bir kere daha uygulamanın, verilerin çalışma kopyasını her koşulda mevcut tutmak için iki farklı veri merkezindeki iki farklı sunucuya tüm dosyalarını kaydedeceği bir zaman vardı.Birkaç ay sonra, kopyalanan dosyaların yaklaşık yüzde 0,1'inin, uygulamanın veritabanında sakladığı MD5 kontrol toplamıyla uyuşmadığını fark ettik. Sunucu ile SAN arasında hatalı bir fiber kablo olduğu ortaya çıktı.

Bu diğer nedenler, ZFS gibi bazı dosya sistemlerinin hataları algılamak için ek toplam özet bilgileri tutmalarının nedeni. Bunlar, yalnızca çürümeye uğramadan yanlış gidebilecek daha çok şeyden sizi korumak üzere tasarlanmıştır.

Açıklamaya bir şey eklemek mi istiyorsunuz? Yorumların sesini kapatın. Diğer teknik uzman Stack Exchange kullanıcılarından daha fazla cevap okumak ister misiniz? Buradaki tam tartışma dizinine göz atın.