Bestanden die eroderen op HD - hoe hiermee om te gaan?

[droner]

Ik gebruik een zwik externe WD HD's (MyBooks) voor archieven en backups daarvan. Nou was ik laatst wat oude, gearchiveerde projecten aan het bekijken en kwam ik wat beschadigde bestanden tegen: enkele sound files die niet 100% zijn bij afspelen en tekstbestanden die hun inhoud verloren lijken te hebben (simpele .txt files). Het gaat om bestanden van ruim 10 jaar oud. Deze specifieke disc (een oude 500MB MyBook) heeft toevallig (nog, foei!) géén backup. De disc geeft geen errors in CrystalDiscInfo, wel een wat hoge temperatuur van 60 graden.

Ik gebruik een sync tool (FreeFileSynch) om de back-up van m'n overige archiefschijven regelmatig bij werken. Maar als bestanden op een archiefschijf beschadigen, wordt die beschadiging natuurlijk gewoon gekopieerd bij synchen, neem ik aan. Een archief is zelf natuurlijk al snel veel te groot om alle bestanden met enige regelmaat te checken. Dus begin ik me zorgen te maken over m'n archieven, hoe secure zijn die op deze manier?

Als ik zo wat zoek over dit probleem vind ik steeds sites waarop beweren dat bestanden op HD helemaal niet *kunnen* beschadigen. Volgens mij is dat wel zo, ik weet 99% zeker dat die bestanden destijds onbeschadigd gearchiveerd zijn.

Heeft iemand hier ideeën over? Hoe kan dit voorkomen worden? Is het wellicht verstandiger om archieven gecomprimeerd op te slaan (i.v.m. ingebouwde datacorrectie in compressiemethodes)? Checksums berekenen en opslaan? Zijn er kant en klare oplossingen voor? Of is het werkelijk onmogelijk wat ik meen te zien en moeten die bestanden toch destijds al beschadigd zijn geweest?

[Anoniem: 15758]

droner schreef op woensdag 04 november 2015 @ 21:08:
Dus begin ik me zorgen te maken over m'n archieven, hoe secure zijn die op deze manier?

Heel simpel: niet. Want je gebruik een legacy filesystem. En die biedt 0,0 bescherming tegen corruptie. Sterker nog, als er corruptie plaatsvindt zal deze geeneens gedetecteerd worden. Dus je kunt tienduizend backups maken maar de corruptie kan ongedetecteerd naar alle backups vloeien.

Daarom zijn alle 1e en 2e generatie filesystems niet meer van deze tijd, waar toch verwacht mag worden dat computertechniek enigszins betrouwbaar functioneert. Ondetecteerde corruptie - ook wel silent corruption genoemd - is het ergste dat je kunt overkomen, juist omdat backups en redundancy je er niet tegen kan bescherming.

De oplossing is vrij simpel: een filesystem van de 3e generatie, dus ZFS, Btrfs of ReFS. Alleen ZFS is echt volwassen genoeg om gebruikt te worden, dus voor consumenten is een ZFS NAS de enige betrouwbare methode voor gegevensopslag. Alle andere oplossingen, zijn gevoelig voor corruptie.

Dat gezegd, het is niet zo dat corruptie aan de lopende band gebeurt, tenzij je een brak geheugenreepje hebt. Maar het valt niet uit te sluiten, waardoor je toch maatregelen zult moeten nemen als je dit risico zo goed als mogelijk wilt uitsluiten.

Behalve ZFS kun je nog met PAR files en andere redundante overhead werken, waardoor corruptie met enige moeite hersteld zou kunnen worden. Dit kan echter wel omslachtig werken, waardoor een ZFS NAS met ZFS send/receive voor backups eigenlijk de enige echt goede oplossing is. Daarom is ZFS in dit tijdperk ook zo populair: het is het eerste filesystem van de 3e generatie dat echt volwassen en goed bruikbaar is.

[jan99999]

-Ook altijd bij backuppen de verify functie gebruiken, zodat bron en doel ook echt hetzelfde zijn.
-Niet een copie van een copie maken, dan zou je 2 x een fout backuppen.
-Zeker 3 backups maken van belangrijke zaken.(1x extern).
-Met ZFS in raid(moet raid zijn), dan heb je checksum en reparatie van je files, beter kan niet, maar hier heb je nog steeds 3x een backup nodig(1x extern, 2x thuis). ZFS meld ook sneller als een file omvalt/slecht wordt.
En je moet ook meerdere keren per jaar je hd's testen, de sectoren herschrijven, zodat de info ook bewaard/ververst wordt, van iemand gehoord dat dit 4x per jaar zou moeten zijn, of dit war is weet ik niet, 1 x per jaar zal zeker moeten. Anders heb je ook geen kontrole of je hd achteruit gaat.
En voor de rest van hoe een backup maken, zie deze en andere forums hoe je dit moet doen.

Een hd kan ook opeens ophouden te werken, ouderdom/defect. Dus meerdere kopieen moet.
ZFS kun je doen door een nas te maken met freenas.
Spinrite is een programma om je sectoren te verversen, deze kijkt ook niet of linux of windows op je schijf staat. Probeer spinrite eens op je slechte hd, heel soms kan spinrite deze repareren.

[ Voor 15% gewijzigd door jan99999 op 04-11-2015 23:50 ]

[droner]

Mijn zorgen zijn bevestigd en de oplossing is dus duidelijk: ZFS.

Een snelle oriëntatie geeft de indruk dat het wel een relatief veeleisende oplossing is (voor een Windows gebruiker) - ik zal een dedicated ZFS systeem moeten bouwen of kopen waarmee Windows dan via een interface communiceert, nieuwe HD's aanschaffen voor erin, de pariteit verlangt een hoop extra opslagruimte en bij gewenste uitbreiding van opslagcapaciteit wordt geadviseerd gewoon nog zo'n heel systeem ernaast te zetten. 'Ka-ching!'

Op dit moment vraag ik me af of ik het risico van silent data corruption (die automatisch mee gebackupped wordt) niet voldoende uit kan sluiten door bij het maken van backups inderdaad dataverificatie uit te voeren en (evt. handmatig) de voorgestelde synch/backup batch te controleren voordat ik die uitvoer. Wellicht zal ik daarvoor sowieso over moeten stappen naar een andere backup/synch tool dan FreeFileSynch, want die heeft volgens mij helemaal geen verify functie. Is vast ook allemaal te vinden op deze fora, ergens...

Maar wellicht is ZFS gewoon de prijs die je over moet hebben voor data security. Ik heb een hoop om uit te zoeken.

De spinrite tip zal ik zeker ook toepassen. Overigens laat die HD bij een check geen hw fouten zien, toch zijn enkele bestanden beschadigd.

Dank voor de antwoorden!

[ Voor 3% gewijzigd door droner op 05-11-2015 13:36 ]

[marcop82]

Ik ga ook akkoord met het advies wat hier gegeven wordt. Er zijn namelijk geen onfeilbare opslagmedia, en hier moet je ook rekening mee houden. ZFS is inderdaad een goede keuze om dit voor een deel op te vangen maar als er teveel corrupt is, gaat het nog fout natuurlijk. Harddisks, optische media (CD, DVD, BD), tape en flash geheugen hebben allemaal in meer of mindere mate last van tijd (>2 jaar) en zijn dan ook onbetrouwbaar voor archivering "op de plank".

Cloudoplossingen halen dat probleem weg doordat de ondersteunende bedrijven het onderhoud en backup onder hun verantwoordelijkheid nemen maar hoe lang blijft de gekozen cloudoplossing bereikbaar ? Echter is het een mogelijke oplossing als "tweede" backup voor langdurige opslag.

Een ZFS NAS opzetten is niet voor iedereen weggelegd, met wat pech moet je gaan prutsen in Linux of BSD, aangezien er zover ik weet nog steeds geen consumentgerichte ZFS NAS toestellen bestaan. Het kan ook gemakkelijk en probleemloos gaan natuurlijk, maar bij issues beland je snel in de command line om de issues op te lossen.

[droner]

Inmiddels heb ik deze (gratis) tool gevonden om checksums mee te genereren en verifiëren, volgens de maker is de tool verschrikkelijk snel: http://corz.org/windows/software/checksum/

ZFS is erg duur en relatief complex om te realiseren, vanwege Windows en zeker gezien ik bijv. onlangs nog 2 (MyBook) 5TB schijven heb aangeschaft (=deel archief + backup van dat deel). Ik geloof zeker dat ZFS uiteindelijk dé oplossing voor SDC is maar ik heb behoefte aan een tussenoplossing. Zoals ik eerder al suggereerde voorzie ik een workflow als volgt: (ik werk dus met 2 disks: archief en backup)

- creëer checksums voor alle files zodra ze het archief in gaan (gebeurt zo ongeveer iedere dag)
- gebruik een synch tool voor de backup (ongeveer 1x per week, FreeFileSynch bevalt vooralsnog prima) MAAR: verifieer alle checksums op de archiefdisk voordat je FFS runt

Op deze manier zou ik vóór het moment van backup synching dus uitvinden of een bestand in het archief beschadigd is en zo voorkomen dat een beschadigd bestand gebackupped wordt. Als het gaat om een bestand wat al eerder gebackupped is kan ik de back-up terugzetten, als het gaat om een nieuw bestand dan is het origineel wellicht nog wel te achterhalen.

Wat de back-up disk betreft zal ik een periodieke check doen: eens per maand een volledige checksum verify van alle bestanden. Wellicht dan voor de zekerheid ook meteen de archiefdisk even in z'n geheel doen (tenzij ik pas nog een backup heb gemaakt). Op datzelfde moment wellicht ook even een HD check uitvoeren van beide schijven (zodat het 1 periodiek klusje wordt), wellicht met SpinRite?

NB: ik weet dat ik eigenlijk sowieso een off-site back-up nodig heb (bijv. brandgevaar), dat even terzijde.


Een paar vragen waar misschien iemand nog iets over kan/wil zeggen:

1. zie ik in bovenstaande iets over het hoofd? (naast de off-site backup)
2. kan ik e.e.a. nog gemakkelijker maken?
3. welk checksum algoritme is voor dit doel aan te bevelen, MD5, SHA1 of BLAKE2?
4. is het inderdaad slim om SpinRite te gebruiken voor een maandelijkse health check - verkleint dat niet de levensduur van mijn disk, of is het wellicht gewoon overbodig? NB: het gaat dus om externe 5TB disks, is wellicht ook erg tijdrovend?

[BartNL]

Elke week een checksum draaien lijkt mij alleen te doen wanneer je het automatiseert. Je hebt er daarnaast alleen wat aan wanneer je voor alle bestanden een backup hebt.
Ik zou in die richting eerder PAR files (of iets dergelijks) maken. Daarmee heb je tenminste een herstel mogelijkheid.

[droner]

Deze checksum tool is te automatiseren. Nog aardiger zou het zijn als ie geïntegreerd zou zijn in de backup (synch) tool, maar ik denk dat ik die wel aan elkaar kan batchen.

De enige files waar niet 100% zeker een back-up van bestaat zijn de files die in het archief geplaatst zijn sinds de laatste backup synch (bij eens per week backuppen dus de files van de laatste week). Meestal staan die nog wel op een live disk.

[BugBoy]

Heb je er wel eens aan gedacht om bijvoorbeeld iets als Amazon Cloud Drive te gaan gebruiken? Dat kost €60 per jaar en dan hoef je je niet meer druk te maken over backups. Een ander alternatief in die hoek is Amazon Glacier. Dat is supergoedkoop, maar het duurt een paar uur als je bij je bestanden wilt. Maar als offline backup is dat eigenlijk prima.

Ik heb zelf een FreeBSD server draaien met ZFS. Op zich is dat redelijk okee, maar dan moet je wel regelmatig "scrubben" om fouten te kunnen detecteren en oplossen. En als er twee schijven tegelijk uitklappen (bijv. spanningspiek) dan ben je nog steeds de klos. Een offline backup vind ik eigenlijk de enige acceptabele optie als je 99.99999% zeker wilt zijn...

[Gomez12]

Periodieke technische verificatie gaat hier heel weinig tegen doen, verificatie werkt eigenlijk alleen in een werkend systeem wat het kan detecteren en er iets mee kan doen.

Als je zo'n externe schijf in de kluis legt en die een half jaar later gaat kopiëren en die kopie gaat verifiëren dan heeft je verificatie tool geen idee wat de goede inhoud was, die weet alleen wat hij nu ziet, dus als die een half-text-bestand leest en een half text-bestand ook aanwezig is op de kopie dan klopt je verificatie.

[droner]

@BugBoy: dank voor de tip, ben helaas niet zo kapot van cloud 'oplossingen' tenzij ik die cloud zelf in bezit en controle heb. En je hebt gelijk dat ik ook een offsite backup zou moeten hebben.

@Gomez12: Als ik alle bestanden op de archiefdisk check (checksum verification) voordat ik daar een back-up van maak, dan zou ik denken dat ik redelijk verzekerd ben (of zeg maar gerust verzekerd) tegen het risico dat ik reeds beschadigde bestanden naar de backup schrijf. Op de backup wil ik dus iedere maand ook alle data verifiëren - wekelijks gebeurt dat al door mijn backup / synch tool (FFS) die de backup vergelijkt met de archiefdisk (welke inhoud identiek moet zijn), maandelijks vervolgens minimaal een volledige checksum verfication (schijnt met Corz zo gepiept te zijn) en een tech check van beide schijven (evt. SpinRite, zie m'n vraag 4.)

Die backup schijf verdwijnt dus nooit maanden in een kluis maar wordt sowieso iedere week gecheckt en bijgewerkt op backup / synch niveau. Ik zie niet hoe ik dan in de situatie zou kunnen komen die jij omschrijft? Trouwens ook niet als hij wel een half jaar in die kluis zou zitten, ik heb toch altijd nog de (semi-live) archiefdisk waarmee hij vergeleken wordt? De backup schijf wordt alleen losgekoppeld als hij 100% is, de kans dat op de archiefschijf en backup schijf dan spontaan exact dezelfde fouten ontstaan lijkt me niet vreselijk groot.

[ Voor 14% gewijzigd door droner op 05-11-2015 23:19 ]

[Puch-Maxi]

Het is wel een goed punt eigenlijk, je kunt wel back-ups maken, maar kloppen je back-ups wel? Zo heb ik ooit als stagiair periodiek back-ups (handmatig) teruggezet om te controleren of de data klopte .

[Renault]

En nog even een kanttekening: je constateert nu dat een deel van je bestanden al beschadigd is. Als je nu checksums gaat toepassen "bevries" je als het ware voor al je bestanden de huidige toestand, beschadigd of niet.
Wellicht is het wenselijk om voor locaties waarop je zeker weet dat meedere bestanden beschadigd zijn (bv. de in de eerste post aangehaalde oude harddisk) éérst een DD (disk duplicate) backup te maken (want nu werkt de schijf nog, morgen misschien niet meer) en dan op de originele oude schijf (want daarop zijn de magnetische randvoorwaarden voor herstel aanwezig) met tools (bv. Spinrite) een herstelpoging te doen, waarna je "het herstelde resultaat", zijnde de best mogelijke originelen, gebruikt voor checksum en daarna opslag?

[magnifor]

Anoniem: 15758 schreef op woensdag 04 november 2015 @ 21:20:
De oplossing is vrij simpel: een filesystem van de 3e generatie, dus ZFS, Btrfs of ReFS. Alleen ZFS is echt volwassen genoeg om gebruikt te worden, dus voor consumenten is een ZFS NAS de enige betrouwbare methode voor gegevensopslag. Alle andere oplossingen, zijn gevoelig voor corruptie.

Btrfs wordt officieel ondersteund door Synology voor haar high-end modellen. Dus hoe kom je tot de conclusie dat Btrfs niet volwassen genoeg zou zijn?

https://www.synology.com/en-global/dsm/btrfs

Met DSM 6 wordt waarschijnlijk het aantal ondersteunde modellen uitgebreid inclusief de DS415+ wat kwa prijs nog redelijk te betalen is:

http://techgage.com/wp-co...rfs-Supported-Systems.jpg
pricewatch: Synology DiskStation DS415+

[ Voor 6% gewijzigd door magnifor op 06-11-2015 12:26 ]

[Anoniem: 15758]

jan99999 schreef op woensdag 04 november 2015 @ 23:44:
-Met ZFS in raid(moet raid zijn), dan heb je checksum en reparatie van je files

Hier heb je geen redundantie voor nodig. Ook een enkele schijf in ZFS biedt redundante metadata zodat het filesystem zelf niet beschadigd kan raken door bad sectors of een corrupte sector op de schijf. Dezelfde bescherming kun je je bestanden geven met copies=2.

Maar dit betreft errorcorrectie. Waar vrijwel niemand het over heeft maar wat mijns inziens veel belangrijker is, is errordetectie. Daar begint alle bescherming mee. Heb je geen correctie maar wel detectie, dan weet je in elk geval wat er corrupt is en wat niet. Echt belangrijke bestanden kun je dan vanuit backup terughalen. Minder belangrijke bestanden kun je goed missen of opnieuw downloaden, maar dan weet je in elk geval wat je mist.

En je moet ook meerdere keren per jaar je hd's testen, de sectoren herschrijven, zodat de info ook bewaard/ververst wordt, van iemand gehoord dat dit 4x per jaar zou moeten zijn, of dit war is weet ik niet,

Spinrite is een programma om je sectoren te verversen, deze kijkt ook niet of linux of windows op je schijf staat. Probeer spinrite eens op je slechte hd, heel soms kan spinrite deze repareren.

Spinrite is verouderd en heeft geen relevantie meer vandaag de dag.

Handmatig je sectoren verversen is ook niet nodig; veel schijven doen dat zelf al - dat heet BGMS: Background Media Scanning. Voor ZFS heb je dat niet nodig en wil je dat ook niet. Eens per week/maand een scrub is voldoende. Elke weak sector of bad sector wordt automatisch opgemerkt en gefixed.

droner schreef op donderdag 05 november 2015 @ 13:34:
Mijn zorgen zijn bevestigd en de oplossing is dus duidelijk: ZFS.

Maar wellicht is ZFS gewoon de prijs die je over moet hebben voor data security. Ik heb een hoop om uit te zoeken.

Zo denk ik er wel over.

marcop82 schreef op donderdag 05 november 2015 @ 14:13:
ZFS is inderdaad een goede keuze om dit voor een deel op te vangen maar als er teveel corrupt is, gaat het nog fout natuurlijk.

Nee hoor - want de detectie werkt nog altijd. En dat is het belangrijkste. Bovendien, afgezien van het falen van meerdere schijven tegelijk, is het vrijwel uitgesloten dat bad sectors door de beveiliging heenkomen. De kans daarop is heel klein, omdat van alle miljoenen sectoren precies de verkeerde combinatie van sectoren onleesbaar moet zijn. Je bent dus vrijwel immuun voor on-disk corruptie.

Een ZFS NAS opzetten is niet voor iedereen weggelegd, met wat pech moet je gaan prutsen in Linux of BSD

Als je Windows kunt installeren of een simpel systeempje kunt bouwen, is een ZFS NAS heel makkelijk te doen. Zodra je hardware draait, heb je binnen 5 minuten een ZFS platform draaiend, je ZFS pool aangemaakt en een Samba share aangemaakt. Vanaf dat moment draai je een ZFS NAS. Als je meer dingen wilt, kan het wel iets ingewikkelder worden, maar de basis is eigenlijk kinderspel. Omdat ZFS alles wat het tegenkomt automatisch repareert, heb je er ook geen omkijken naar en hoef je ook geen onderhoud te plegen. Alleen een periodieke scrub en dat valt veelal automatisch te configureren.

droner schreef op donderdag 05 november 2015 @ 19:11:
ZFS is erg duur en relatief complex om te realiseren

ZFS zelf is gratis en doordat het ontworpen is voor goedkope consumentenhardware heb je ook minder hardwarekosten dan legacy-oplossingen.

Complex is het ook niet, tenzij je zeer specifieke wensen hebt of geavanceerde functies wilt gebruiken. Daarnaast, de oplossingen die ik hoor in dit topic klinken toch behoorlijk veel complexer en tijdrovender dan even snel een ZFS NAS in elkaar flansen. Dat is echt zo gedaan.

magnifor schreef op vrijdag 06 november 2015 @ 12:19:
Btrfs wordt officieel ondersteund door Synology voor haar high-end modellen. Dus hoe kom je tot de conclusie dat Btrfs niet volwassen genoeg zou zijn?

Omdat ik mij niet laat indoctrineren door bedrijven die hun eigen belangen hebben. En mag ik wijzen op Ext4 wat ook 'officieel ondersteund' was door Ubuntu met alle corruptiebugs tot gevolg? Laat je niet zo misleiden - zij hebben geen keuze dus is dit de enige optie die ze hebben.

Synology kan ZFS niet out of the box meeleveren door licentie-issues. Dus is Btrfs hun enige keus voor een 3e generatie filesystem. Omdat hun huidige opslagtechnologie (Ext4+mdraid+SHR) ernstig verouderd is, is er extra druk om een 3e generatie filesystem te gebruiken. Ook al is Btrfs nog helemaal niet volwassen genoeg voor grootschalig gebruik in commerciële producten.

[droner]

Voor mij zou ZFS toch een flinke investering in zowel geld en tijd betekenen (terwijl ik nog maar pas 2 spiksplinternieuwe MyBooks heb aangeschaft), plus ik ben niet zo enthousiast over de schaalbaarheid (zoals ik daar tot nu toe kennis van genomen heb). Dat valt voor mij op dit moment dus definitief af. Wel erg bedankt voor de uitleg, vond het erg interessant om even te bekijken.

Intussen ben ik dus van mening dat mijn alternatieve aanpak met checksums en periodieke checks voldoende bescherming biedt tegen SDC, wat ook niemand heeft weerlegd.

@Renault: bedankt voor de waarschuwing, iets dergelijks moet ik voor die disk idd doen en gaat ook gebeuren.

Wel zit ik nog steeds met de vragen:

1. zie ik in bovenstaande aanpak iets over het hoofd? (naast de off-site backup)
2. kan ik e.e.a. nog gemakkelijker maken?
3. welk checksum algoritme is voor dit doel aan te bevelen, MD5, SHA1 of BLAKE2?
4. is het inderdaad slim om SpinRite te gebruiken voor een maandelijkse health check - verkleint dat niet de levensduur van mijn disk, of is het wellicht gewoon overbodig? NB: het gaat dus om externe 5TB disks, is wellicht ook erg tijdrovend?

[marcop82]

Anoniem: 15758 schreef op vrijdag 06 november 2015 @ 12:44:
[...]

Nee hoor - want de detectie werkt nog altijd. En dat is het belangrijkste. Bovendien, afgezien van het falen van meerdere schijven tegelijk, is het vrijwel uitgesloten dat bad sectors door de beveiliging heenkomen. De kans daarop is heel klein, omdat van alle miljoenen sectoren precies de verkeerde combinatie van sectoren onleesbaar moet zijn. Je bent dus vrijwel immuun voor on-disk corruptie.

Dan ga je ervan uit dat er nog steeds meer dan één backup is natuurlijk, we hadden het hier toch over langetermijn backup ? Dan zal ZFS alleen niet de boel kunnen rechthouden als er teveel corrupt is. Dan heb je inderdaad versions=2 nodig wat niet iedereen weet in te stellen of weet dat het nodig is. Of een 2de backup maar ik denk dat je bij een langetermijn backup niet nog een andere langere termijn backup hebt
ZFS is goed maar ook niet magisch, er moet nog steeds ergens correcte data vanaf kunnen.

[...]

Als je Windows kunt installeren of een simpel systeempje kunt bouwen, is een ZFS NAS heel makkelijk te doen. Zodra je hardware draait, heb je binnen 5 minuten een ZFS platform draaiend, je ZFS pool aangemaakt en een Samba share aangemaakt. Vanaf dat moment draai je een ZFS NAS. Als je meer dingen wilt, kan het wel iets ingewikkelder worden, maar de basis is eigenlijk kinderspel. Omdat ZFS alles wat het tegenkomt automatisch repareert, heb je er ook geen omkijken naar en hoef je ook geen onderhoud te plegen. Alleen een periodieke scrub en dat valt veelal automatisch te configureren.

Maar welke Windows gebruiker weet wat een pool is, scrubben of samba ? Laat de gemiddelde gebruiker maar eens paswoord-protected shares in orde brengen. Misschien bij sommige distros is 1 of 2 zaken makkelijk maar niet bij ze allemaal is het zo simpel als Windows installeren. Ik ken genoeg mensen die hun weg in Windows veel beter kennen dan 95% van de mensheid maar zet ze iets voor waar specifieke Linux universe kennis voor nodig is en ze haken af omdat ze het niet snappen of de tijd ervoor willen opbrengen. Daarom vind ik het nog steeds zo spijtig waarom Synology en andere populaire NAS fabrikanten nog geen ZFS NAS hebben in hun aanbod.

[droner]

@marcop82: inderdaad & thx voor het begrip, ik val in de categorie van Windows gebruikers die je omschrijft

Terug bij mijn alternatieve oplossing en vragen daarover, op vraag 3 heb ik inmiddels het antwoord: md5 is absoluut de beste keuze, want voldoet 100% voor dataverificatie en is veruit het snelste (want het simpelste) om mee te werken. SHA1 en BLAKE2 voegen crypto toe, alleen interessant wanneer je ook nog wilt voorkomen dan kwaadwillenden expres met je checksums knoeien - geen risico waar ik me tegen poog te wapenen.

Wat vraag 2 betreft: FFS + Corz checksum vormen msschien een aardige gratis oplossing maar inmiddels zie ik dat er ook backup/synch tools zijn die gewoon met checksums werken. Suggesties zijn welkom.

Geen antwoord op vraag 1 kan ik denk ik zien als een goed teken.

Mocht iemand nog iets kunnen zeggen over vraag 4 (wel of niet met enige regelmaat via Spinrite sectoren overschrijven t.b.v. langere levensduur schijf), heel graag,

[ Voor 12% gewijzigd door droner op 08-11-2015 12:53 ]

[droner]

Anoniem: 15758 schreef op vrijdag 06 november 2015 @ 12:44:
[...]
Spinrite is verouderd en heeft geen relevantie meer vandaag de dag.

Handmatig je sectoren verversen is ook niet nodig; veel schijven doen dat zelf al - dat heet BGMS: Background Media Scanning. Voor ZFS heb je dat niet nodig en wil je dat ook niet. Eens per week/maand een scrub is voldoende. Elke weak sector of bad sector wordt automatisch opgemerkt en gefixed.
[...]

Ik heb intussen eens wat gezocht naar dat BGMS (schijnt ook vaak BMS genoemd te worden) maar dat lijkt zeker niet in alle HD's geïmplementeerd te zijn en ik kan nergens vinden of dat in WD MyBooks het geval is (dat zijn dus USB drives he!)

Daarnaast: wat bedoel je precies met 'scrubben'? Als ik dat opzoek kom ik op 'wissen' uit, kan me bijna niet voorstellen dat je dat bedoelt? Het overpompen van 5TB aan data kost (via USB) nogal wat tijd en is daardoor zeker niet iets wat ik iedere week zou willen doen - vanwege die tijd die het kost, vanwege het idee dat je gedurende die tijd slechts 1 kopie van je data hebt (omdat je 1 van de schijven gewist hebt) en vanwege de inspanning die de disk daarvoor moet leveren (= misschien minder levensduur?). Bovendien zou ik dat dan dus voor beide schijven moeten doen waardoor ik zo'n beetje de hele week bezig ben om data heen en weer te pompen, geen aantrekkelijk of zelfs werkbaar vooruitzicht

Iets meer uitleg zou prettig zijn.

[Anoniem: 15758]

Scrub slaat op ZFS - in die context betekent het heel wat anders. Een scrub op een ZFS pool betekent dat de integriteit van alle bestanden en datasets wordt gecontroleerd. Het equivalent van een 'chkdsk' dus. Na een scrub weet je zeker dat alle bestanden corruptievrij zijn, tenzij je natuurlijk een melding krijgt bestand X is corrupt. Dat kan ZFS weten aan de hand van de checksums. Legacy filesystems kunnen dit niet weten en kunnen enkel constateren dat het filesystem zelf inconsistent is. Maar corruptie an-sich zal ongemerkt voorbij gaan.

[jeroen3]

Als ik grote hoeveelheden bestanden archiveer (zip/iso) dan zorg ik altijd voor een setje parity files.
Bijvoorbeeld met http://multipar.eu/

Soms gebruik ik ExactFile om wat md5sums aan te maken. Maar daar heb je in feite niets aan, behalve de indicatie dat je bestand kapot is. Met parity files kun je tenminste nog een paar defecte sectoren herstellen.

[Barnes]

Een andere oplossing zou snapraid (http://www.snapraid.it/) kunnen zijn. Moet je nog wel investeren in 1 of 2 harde schijven voor parariteit. Maar dan is je data wel beschermd. Ik heb zelf deze oplossing draaien in een computer met een task om te scrubben. Hierdoor wordt alle data 1x in de 6 weken geraakt en gecontroleerd.
Deze tool heeft me al 2x mijn data gered en ben er zeer content mee. Het is simpel in gebruik en kost niks. Zowel op windows en linux te gebruiken.

[Brent]

Momenteel checksum ik 'handmatig' het hele filesystem van mijn persoonlijke files (archief, werk, fotos, muziek, software, etc). Heb altijd dit willen verbeteren door een script met PAR, zodat ik rotte bits ook misschien nog terug kan krijgen. Bestaande PAR tools gaan altijd uit van sets bestanden (DVD's oid), terwijl ik weleens een filetje hier of daar aanpas/verwijderen/toevoeg. Als iemand zo'n programma weet, hou ik me aanbevolen.

[droner]

Als je alles dubbel bewaart en nooit iets van kopie 1 naar kopie 2 kopieert zonder eerst de checksum te verifiëren, dan heb je, zodra een bestand beschadigd raakt, dus altijd nog 1 werkende versie. Ik denk dat je dan geen PARs nodig hebt.

Even doordenkend zijn PARs dus eigenlijk alleen zinvol om als tweede versie te bewaren in plaats van een complete kopie - en is het gebruik van PARs voor backups dus eigenlijk ook alleen een kwestie van besparen op HD ruimte.

Of maak ik dan een denkfout?

[jan99999]

Par is geen backup.
Een backup is, 3 kopieen, en je mag minder doen, maar dan is het geen backup.

En par is goed om files te repareren, meer niet, heeft niks met een backup te maken, maakt je backup wel steviger.

[Brent]

jan99999 schreef op woensdag 11 november 2015 @ 05:25:
Par is geen backup.
Een backup is, 3 kopieen, en je mag minder doen, maar dan is het geen backup.

En par is goed om files te repareren, meer niet, heeft niks met een backup te maken, maakt je backup wel steviger.

Maar bitrot is dezer dagen dan ook een minstens zo grote uitdaging als goede backups hebben. Met TB schijven heb je gegarandeerd rotte bits, en checksums zijn de enige manier om dat zelfs maar te weten, en of meerdere backups of PAR kan je helpen corrigeren.

[jeroen3]

Jep. Want een schijf heeft "maximaal minder dan" 1 defecte bits per 10^14 bits (100 triljoen).
Een 4TB schijf heeft 32 triljoen bits, dus je bent al bij "minder dan" 1 defecte bit na 3.125 keer volledig schrijven.
En dat is dan een kans, het kan zijn dat de fout zich bij de tweede bit al voordoet.

[droner]

OK, dus we kunnen m.i. concluderen dat checksums absoluut essentieel zijn, en dat je óf een complete back-up óf een PAR set nodig hebt om fouten, zodra die zich voordoen (en die gaan zich voordoen), te kunnen repareren.

Om fouten tijdig op te merken moet er sowieso steeds een checksum verification gedaan worden vóór het maken van iedere backup (omdat je anders misschien fouten meekopieert) en als er niet vaak genoeg back-ups gemaakt worden, ook periodiek - en dat geldt voor zowel archief als de back-up daarvan. Ook moet je regelmatig een hw health check doen van alle disks en evt. tijdig een schijf vervangen.

Ik gebruik vooralsnog dus FreeFileSynch voor het mirroren van de backup, Corz checksum voor de (md5) checksums, CrystalDiskInfo en (win 7) Checkdisk voor de disk hw checks, beschadigde bestanden worden handmatig gefixt door bestanden van de back-up terug te zetten (of v.v.).


Welke software setups gebruiken jullie?
En hoe gaan jullie met de checksums om; maak je die voor de hele schijf, of per folder, of per bestand enz.?

[Barnes]

Kijk eens naar Snapraid. Dat doet het allemaal, en werkt makkelijker dan par bestanden.

[droner]

Dank voor de tip, maar is Snapraid niet voor raid/arrays bedoeld? Ik werk met 2 losse externe schijven.

[Brent]

Het voordeel van checksum files en/of PAR is dat het fs onafhankelijk is, en inderdaad een stuk praktischer voor persoonlijk gebruik (nog niet praktisch genoeg ). Een storage array bouwen is een heel andere oplossing, en perkt je enorm in. Een 'systeem' waarin je gewoon je files moved naar een andere schijf en zo nu en dat checkt en/of PARt is een stuk prettiger (voor mij).

[Gomez12]

Brent schreef op vrijdag 13 november 2015 @ 11:34:
Het voordeel van checksum files en/of PAR is dat het fs onafhankelijk is, en inderdaad een stuk praktischer voor persoonlijk gebruik (nog niet praktisch genoeg ). Een storage array bouwen is een heel andere oplossing, en perkt je enorm in. Een 'systeem' waarin je gewoon je files moved naar een andere schijf en zo nu en dat checkt en/of PARt is een stuk prettiger (voor mij).

In de praktijk die ik veelal zie werken checksum files en/of PAR niet omdat het berust op menselijke discipline en die gaat ook eroderen. Die schijf + backup-schijf met alle foto's van 10 jaar terug die wordt even in de kast gelegd voor een jaartje en dan heeft die opeens bad-files en dan wordt de backup schijf erbij gepakt maar die lag in dezelfde kast en heeft ook bad-files maar dan net weer andere.

En met usb-schijven heb je ook nog simpelweg eens te maken met de fysieke tijd die het gewoon kost om 5TB oid te benaderen waardoor die backup-schijf draaien toch altijd "lang" duurt en deze week even niet uitkomt, maar volgende week echt wel.

Een storage array die doet dit gewoon continue en constant.

[Brent]

Gomez12 schreef op vrijdag 13 november 2015 @ 13:52:
Een storage array die doet dit gewoon continue en constant.

ZFS met een scrub cronjob? Als je dat kunt, kun je ook je checksums cronjobben

Punt is, deze twee oplossing zijn niet gelijk.

[Gomez12]

Brent schreef op vrijdag 13 november 2015 @ 14:25:
[...]
ZFS met een scrub cronjob? Als je dat kunt, kun je ook je checksums cronjobben

Punt is, deze twee oplossing zijn niet gelijk.

ZFS heb ik in principe iets wat 24/7 aanstaat, checksums gebeurt imho veel meer aan de client-kant die niet 24/7 aanstaat en je dus opeens iets moet gaan regelen dat een checksum onderbroken kan worden, dat een checksum moet gaan resumen (anders komt hij nooit klaar als hij telkens opnieuw begint etc)

[Brent]

Gomez12 schreef op vrijdag 13 november 2015 @ 14:29:
[...]

ZFS heb ik in principe iets wat 24/7 aanstaat, checksums gebeurt imho veel meer aan de client-kant die niet 24/7 aanstaat en je dus opeens iets moet gaan regelen dat een checksum onderbroken kan worden, dat een checksum moet gaan resumen (anders komt hij nooit klaar als hij telkens opnieuw begint etc)

ZFS scrubt standaard niet dacht ik, dus dat helpt je niets zonder cronjob.

[droner]

Ik zit nog steeds met FFS, Cor'z, CDI en Checkdisk te kijken, heb geen enkele moeite om de back-ups zelf up2date te houden (dat gaat immers nooit om 5TB ineens maar alleen om de aanvullingen/wijzigingen) maar zou wel graag een betere integratie van de functies vinden... al ben ik bang dat geen enkele andere checksum tool zo snel is als Corz.

Cronjobs (of in mijn geval Task Scheduler) kan ik natuurlijk wel inzetten maar daar heb ik weinig aan aangezien processen afhankelijk zijn van de uitkomst van elkaar. Bovendien wil ik de disks niet continu powered on laten.

ZFS (of andere array oplossing) is (nu) gewoon echt geen optie voor mij Gomez21.. zie eerdere posts daarover.

Ik wil dus graag van 4 tools naar minder, Snapraid is volgens mij niet van toepassing, iemand nog andere ideeën?