Corruptie bestanden en controle van backups

[gelukkie]

Sinds ik een halfjaar geleden de bestanden van mijn interne harde schijf(2) naar een usb schijf heb gezet ben ik de externe usb schijf (1) als primair gaan gebruiken (handig tussen meerdere pc’s). Als extra ‘backup’ kopieer/ mirror ik de nieuwe bestanden nog wel naar de interne schijf van de pc die eerst als primair werkte.

Nu kwam ik er onlangs achter dat een aantal foto’s op de externe schijf (1) corrupt waren. De files waren ook op de interne schijf van die pc corrupt. Ik denk dus dat de corrupte files op schijf 1 tijdens de eerste kopie zijn overgenomen de interne bronschijf. Gelukkig had ik nog een externe backupschijf (schijf 3) waar de bestanden niet corrupt waren.

Vervolgens heb ik van die laatste schijf (3) een SFV bestand gemaakt (enkele honderden GB’s, dat duurde ca 6 uur via usb 2.0). Dat SFV bestand heb ik vervolgens gebruikt om mijn externe werkschijf (1) te controleren (duurde uur of 3, usb 3.0) . Daaruit kwamen ca 30 verschillen/ corrupte bestanden op de 83000. Niet gigantisch veel, maar toch vervelend. Ik heb de bestanden vervangen en schijf 1 moet nu volgens mij weer goed zijn. Echter blijkt de interne schijf (2) meer corrupte bestanden te bevatten, ik gok dus dat deze schijf slecht aan het worden is of gevoeliger is voor corruptie van software omdat deze is ingebouwd en altijd aanstaat…

Tot slot heb ik nog een vierde schijf (4) die ik op een externe locatie bewaar en regelmatig mirror aan schijf 1. Ook deze schijf (usb 2.0) wil ik laten controleren met het pasgemaakte SFV bestand van schijf 3).

Omdat ik regelmatig nieuwe foto’s maak en af en toe een oude aanpas gaat het SFV bestand snel achter de feiten aanlopen. Overigens check ik bij een mirror altijd handmatig of er geen foto’s worden overschreven waar ik niet heb aangezeten, en eigenlijk klopt dat altijd.

Aangezien het maken van de SFV van schijf 3 erg lang duurde, en dan heb ik alleen de map met foto’s gedaan en niet de complete schijf, ben ik benieuwd wat de juiste manier van aanpakken is. Is het een goed startpunt om vanaf nu schijf 1 aan te houden als basis voor de SFV? Van schijf 1 dan, zeg één keer per jaar, een SFV te maken en die vervolgens te controleren op de andere schijven? Zit ik zo ‘safe’, werk ik zo juist en het meest snel of denk ik te ingewikkeld?

Volgens mij is voorkomen van corruptie een illusie?

[begintmeta]

Je kan corruptie zoveel mogelijk uitsluiten, als je ECC-RAM neemt is vrijwel het hele pad dat de foto's moeten afleggen voorzien van foutdetectie, alleen de standaard consumentenschijven zijn dat niet helemaal (of tenminste: ze melden fouten niet altijd). Hiervoor zou je handmatig de bestanden regelmatig kunnen checksummen of dit overlaten aan een bestandsysteem met data-checksums (bijvoorbeeld ZFS, btrfs, ReFS). Ook zijn media laagdrempelig beschikbaar waarvan wordt geclaimd dat ze erg robuust zijn (bijvoorbeeld de M-DISC, die zou je eventueel extern kunnen archiveren om de kans op corruptie nog wat te verkleinen.

[gelukkie]

Bedankt, bij toevoegingen aan de backups laat ik tegenwoordig de bestanden ook controleren. Maar betreft een corruptiecheck van de hdd's, is de werkwijze de juiste en meest efficiente? Mijn kennis reikt niet zover dat ik weet hoe ik de bestandsystemen met datachecks moet inzetten, via google kwam ik hier ook niet echt uit.

[jan99999]

Ook je software kan fouten geven, firewall en virusscanner/spyware scanner, zitten overal tussen, dus deze kunnen ook je files beschadigen. Ook updates, drivers die vernieuwd worden, kunnen files gaan beschadigen.

Kopieren met de hand is geen backup oplossing, dus gebruik backup software die ook het origineel kontroleert tav de backup.

Zelf eens gelezen dat je de hd meerdere keren per jaar, alle sectoren moet gaan verversen om zo te kontroleren of de backup nog goed is, maar hier gaat natuurlijk veel tijd in zitten.

[gelukkie]

Ik gebruikte eerst een aantal jaren Synctoy, maar die controleert volgens mij niet. Sinds een jalf jaar gebruik ik syncbackfree en daar heb ik wel de controle optie gevonden. Als ik nu backup zie ik dat de bestanden worden gecontroleerd. Handmatig bekijk ik alleen of op de backup niet bestanden worden overschreven waar ik niet mee heb gewerkt.

Vervelend dat het allemaal zo tijdrovend is inderdaad..

[Tsurany]

Wat je kan overwegen is om een kleine ZFS server te nemen. Een zelfbouw computer met daarop bijvoorbeeld FreeNAS. Via het ZFS filesystem wordt corruptie voorkomen en kan bitrot ook hersteld worden. Als je dan incrementele backups maakt naast je originele backup heb je altijd meerdere versies van je foto's en voorkom je dat je corrupte foto's over de originele heen schrijft.
Als je dan deduplication gebruikt via ZFS kost het je ook amper extra opslagruimte.

Dan kan je geheel vertrouwen op automatische backups omdat je storage server actief corruptie voorkomt en je door verificatie in de backup software zorgt dat bestanden altijd corruptievrij worden weggeschreven. Als je dan ook nog gewijzigde bestanden als nieuw bestand neerzet zit je helemaal safe.

[ Voor 27% gewijzigd door Tsurany op 22-08-2015 18:26 ]

[dik_voormekaar]

Gebruik quickpar of multipar

[ Voor 28% gewijzigd door dik_voormekaar op 22-08-2015 18:34 ]

[gelukkie]

Een speciale server bouwen vind ik voor nu iets te ingewikkeld, daarnaast gebruik ik mijn externe schijf ook misschien 10x per maand om wat foto's te bewerken en toe te voegen, het bekijken doe ik eigenlijk altijd via een aantal uploads op Flickr. Ik gebruik mijn pc's verder heel weinig omdat ik alles op mijn iPad doe.

Die Par bestanden klinkt interessant. Als ik het goed begrijp maak ik hiermee een bestand dat wanneer nodig een fotofile kan repareren? Eigenlijk is dit een soort SFV alternatief dat ook kan repareren? Ik kan dit natuurlijk vanaf nu voor elke map gaan maken en dan voor de afgelopen jaren een bestand per jaar (grootste map is ca 35gb). Ik wordt niet echt wijs of ik bijvoorbeeld voor 2013 voor elke submap automatisch zo'n par kan laten maken.

[gelukkie]

Zojuist Multipar getest en dat werkte goed. Heb een par gemaakt van de goede folder, daarna kon dmv het bestand de folder met beschadigde jpg's worden gerepareerd.

Blijft betreft dit punt alleen de vraag wat handig is: een .par per jaar of iets dieper in de structuur, per fotomap. En als ik eens in de zoveel tijd wil testen op kapotte bestanden, kan dat dan best allemaal via de .par of moet ik overal ook nog een sfv van maken?

[Tsurany]

Je kan het beste op het hoogst mogelijke niveau werken, dat werkt het eenvoudigst. Zorg voor het juiste percentage aan repair blocken (10% is wel aardig) en je zit goed. Als je wilt testen kan je gewoon die par bestanden gebruiken, sfv is niet nodig omdat parity zowel checksums als repairblocks heeft.

[jeroen3]

Ik geef belangrijke mappen altijd via Multipar herstelbestanden. Voornamelijk iso en zip is vatbaar voor corruptie, dus die bewaar ik altijd met redundatie. Ik probeer dit een veelvoud clusters te houden.
Maar je kunt allerlei bestanden gebruiken. Het duurt soms alleen wat lang, en het is geoptimaliseerd voor grote archieven voor gebruik op usenet.

Ik ben ooit op zoek geweest naar software die dergelijke pariteit, in niet-imaged backups verwerkte, maar die heb ik nooit gevonden.

syncback kan ook op checksum basis vergelijken. Het duurt langer, maar dan weet je wel dat je Back-up nog intact. Ik weet niet hoeveel sneller dat is vergeleken met een volledige Back-up.

[ Voor 16% gewijzigd door jeroen3 op 23-08-2015 15:05 ]

[gelukkie]

Merk wel dat het lastig inschatten is wat de juiste instellingen zijn. Ik ben nu bijvoorbeeld bezig met de 2014 map(63gb). Als ik de map kies in multipar geeft ie standaard 1,3% efficientie en het bestand wordt dat 400gb.. %repairblokken heb ik dan op 10.

Als ik aan de blokgrootte ga schuiven wordt het te maken bestand een stuk kleiner (kleinste is ca 7,5gb met heel veel blokken, nog vrij groot?). Het minimaal aantal te repareren bestanden wordt bij groot aantal blokken groter, terwijl de max aantal lager wordt. Daarnaast gaat mijn pc er ruim 18 uur over doen om dat bestand van 7,5gb te maken.. Dat lijkt mij vrij lang. Als het aantal blokken lager wordt en het bestand groter gaat dit wat sneller.

Zijn er bepaalde 'ideale' instellingen? Via Google kon ik die niet vinden.

[ Voor 20% gewijzigd door gelukkie op 23-08-2015 18:43 ]