Kyllähän toi bit rot on ihan olemassa oleva uhka, mutta kyllä se monen kohdalla menee vaan enempi foliopipo hommiksi kuin ihan oikeaksi ongelmaksi.
Riippuu siitä miten tärkeäksi katsoo varmistustensa ehyenä pysymisen. Jos se ei ole tärkeää, sitten ehkä ne varmistuksetkin ovat sinänsä turhia. Varsinkin jos sen integriteettitarkistuksen saisi toimimaan taustalla ilman että joutuu itse jatkuvasti tekemään lisätyötä sen eteen, esim. erillisten checksum-työkalujen avulla.
Mutta tuosta olen kyllä eri mieltä että jos sulla on bvackupit kunnossa niin ei ongelmaa. Sinähän ET voi tietää että milloin se bit rot iskee, eli voit vaikka tehdä backupin jo mädästä tiedostosta
Toki tiedosto voi olla vaikka alusta asti korruptoitunut. Tarkoituksena on kuitenkin tehdä lisävarmistus että jos laitat sen vaikka kahdelle eri USB-levylle kahdeksi vuodeksi kaappiin, miten tarkistat sen kahden vuoden kuluttua että edes jompikumpi niistä on edelleen ok, jos vaikka jälkikäteen tehtävällä checksum-tarkistuksella ne antavat eri tuloksen.
En ajattele niin mustavalkoisesti että jos jää mikään 0.000001% mahdollisuus että siitä huolimatta jokin menee vikaan, kaikki sen eteen tehtävä työ on turhaa. Jos teen vaikka lopputyön ja otan kaksi fyysistä varmistusta kahteen lokaation ja kolmannen vielä pilveen... toki on teoriassa edelleen mahdollista että molemmat fyysiset varmistukset palavat poroksi samanaikaisesti ja pilvipalvelu johon talletit on mennyt konkurssiin ja datasi kadonnut sieltäkin. Oliko useampi varmistus siis alunperinkin täysin turhaa työtä?
Ehkä tavoitteena ei ole saada 100% varmuutta, jos edes 98% varmuus riittää esim. 50% varmuuden sijaan.
Se onko varmistusten bitrot mikään todellinen vai ainoastaan teoreettinen ongelma... en tiedä. Eteeni tulee varmistuksilta silloin tällöin yksittäisiä tiedostoja joiden havaitsen olevan korruptoituneita, tai ainakin epäilen niin. Esim. zip tai rar tiedosto joka ei enää suostukaan purkautumaan, lienee aika selvä juttu että jotain on tapahtunut jossain vaiheessa. Tai jos sama tiedosto on kahdella eri medialla ja tulee kaksi eri checksummaa, siinä arpoo kumpi on mahdollisesti vielä kunnossa vai onko kumpikaan, kun ei ole alkuperäistä checksummaa kummastakaan olemassa.
Mitään vastausta sille ei tuossa vaiheessa enää saa että missä vaiheessa ja miksi tiedosto on vioittunut, eikä sen tietäminen välttämättä mitään auttaisikaan enää siinä vaiheessa. Tärkeintä olisi lisätä jonkinlainen tarkistus että edes tietää onko tiedosto vielä ok, vai ei. Erillisten checksummien teko arkistoinnin yhteydessä on yksi, mutta pidemmän päälle työläs, tapa.
kun taas btrfs taikka jokin muu moderni filesystem olisi kertonut sulle siinä backupin teossa että hei nyt on tiedosto päässyt mädäntymään ja jos sulla oli peilattu taikka joku muu raid pooli käytössä niin se korjattaisiin siinä lennossa.
Kysyin jollain foorumilla (SuperUser varmaan) joskus antaako btrfs mitään lisävarmuutta sille että jos vaikka kopioin tiedoston koneelta ulkoiselle USB-asemalle (molemmilla btrfs käytössä), vastaako kopioitu tiedosto bitilleen alkuperäistä. Silloin sain ainakin käsityksen ettei esim. btrfs ota tuohon mitään kantaa tai tuo mitään lisäturvaa, btrfs on kiinnostunut vain siitä ettei sen omassa lokaalissa tiedostosysteemissä tapahdu ikäviä.
En tiedä onko teoriassa kuinka mahdollista että kopiointi menee vikaan (joku virhe USB:ssa, tai sitten aiemmin mainittu muistivirhe juuri kopioinnin aikana?), mutta tätä vastaan kai on sitten omat keinonsa, kuten Windowsissa TeraCopy joka ajaa automaattisesti checksum-tarkistukset alkuperäisen ja kopioidun tiedoston välillä, tai Linuxissa rsync sopivilla optioilla (saattoi olla että rsyncin joutui ajamaan kahteen kertaan jotta sai täyden varmuuden tuolle, eli toisella kopiointikerralla käskee rsyncciä ylikirjoittamaan vain ne tiedostot joiden checksum ei vastaa alkuperäistä, siinä yhteydessä ne kaikki tulee tarkistettua).
Single disk btrfs ei pysty kuin varoittamaan lahoamista mutta peilattu/parity tosiaan korjaa itsensä.
Juu, mutta single disk btrfs auttaa kuitenkin jos haluaa tietää onko ulkoisella varmistuksella oleva tiedosto edelleen ehjä, jotta sen voi esim. korvata toisella varmistuksella olevalla tiedostolla (melko epätodennäköistä että molemmat toisistaan erillään olevat tiedostot olisivat vioittuneet suunnilleen samoihin aikoihin).
Lisäksi mirroroinnit ja parityt eivät suoraan auta siihen jos teet inhimillisen virheen ja rikot tai tuhoat tiedoston itse, silloin helpointa on että sinulla on se sama tiedosto toisaalla ja voit korvata rikkoutuneen sillä. Mirroroinnit ja parityt ovat ehkä enemmän live-käyttöä varten, eivät kaapissa vuosikausia pidettäviä arkistoja varten.