Poll
image

Hoe vaak test jij je backups?

maandag 14 december 2020, 10:58 door Redactie, 12 reacties
Nooit
24.26%
Regelmatig
30.43%
Incidenteel
35.32%
Ik maak geen backups
10%
Reacties (12)
14-12-2020, 17:31 door Briolet
Elke 2e maandag per decennium is ook regelmatig. (-:
14-12-2020, 22:29 door Anoniem
Telt 1 Time Machine bestand terugzetten mee?
15-12-2020, 03:31 door Anoniem
Ik verwijder backup 2 pas nadat ik backup 1 getest heb vlak voordat ik een nieuwe maak. Bij een nieuwe backup 1 wordt de oude nr 2. Mocht er iets falen bij het maken van een nieuwe backup, dan heb ik oude 1 en 2 nog op 2 verschillende media.
15-12-2020, 09:11 door Anoniem
Af en toe, dus incidenteel kijk ik wel eens in de backup (in mijn geval natuurlijk ook offline) of zo ongeveer alles er in staat wat ik recent heb aangemaakt of gewijzigd. Soms kopieer en plak ik zo'n bestand en test het dan. Op Windows betreft dat een Iperius backup en in Linux een Grsync backup.
Maar ik nog nooit getest om een backup volledig terug te zetten. Gek hé? Het is een irreële angst dat de backup toch niet compleet is en je bestanden kwijtraakt.
Herkent iemand dat wantrouwen? Want dat is het eigenlijk.
15-12-2020, 12:35 door Anoniem
Ik gebruik het A-B systeem van mijn vader van toen hij nog werkte. Hij had een floppy disk met A erop en een floppy disk met B erop. De oudste werd altijd overschreven met de nieuwste backup.

Zelf roteer ik drie USB A sticks. Maar dat mogen er ook meer zijn. Volgens het A-B systeem van mijn vader.

Heel soms, schrijf ik een CD of DVD met backups. Een paar keer per jaar doe ik dat.

Mijn backups bestaan uit een .zip file van de c:\users\naam directory en deze test ik eenmaal na het schrijven naar USB stick. Daarna nooit meer. De CD's en DVD's zijn backups die ik lang wil bewaren. Omdat ik ze niet goed kan vernietigen worden dat er steeds meer en nooit minder.

Ik maak geen solid archives met .zip, want dan betekent een klein foutje in het begin, dat je de rest van de backup niet meer kan terughalen. Dat is slecht.

Voor ik een backup maak controleer ik mijn PC op virussen zodat ik geen virussen backup. Na de backup update ik alle software voor zover dat nog niet gebeurd was. Ook ruim ik bestanden op na de backup waarvan ik niet zeker wist of ze weg konden (tijdelijke bestanden en dergelijke).

In de cloud zet ik niets want dat is buiten mijn controle. Zo heb ik gelezen dat mensen al hun foto's kwijt waren geraakt toen Microsoft besloot hun Microsoft Account te blokkeren. Dat wil je niet.

Mijn methode heeft meerdere nieuwe computers overleefd en ik ben maar weinig data kwijt geraakt in al die jaren. Tussendoor heb ik ook nog uitstapjes naar Linux gemaakt waar ik dezelfde methode gebruikte om mijn data veilig te stellen.
15-12-2020, 20:24 door passer
Ik kontroleer ze nooit: ik maak om de week backups en dadelijk na het maken kopieer ik die naar mijn tweede schijf. Ik bewaar ook steeds de laatste 4 backups (+ nog om de zoveel tijd eentje op een niet-verbonden-schijf.
Moest er al een backup brak zijn, dan heb ik er altijd nog 3 andere (in het dubbel dus)
16-12-2020, 12:49 door Anoniem
Sinds er niet gespecificeerd staat of het prive of zakelijk betreft bij deze de meer interessante.

We maken gebruik van checksum controle en delta controles.
Elke herstart van een cluster wordt er automatisch een volle scan verricht en los daarvan elke dag een rapportage van backup sync status en verwachte degradatie ten opzichte vorige dag.

Elke maand worden de clusters getest op database, mail en file replicatie met een bestand van 4GB en elk kwartaal mirroren we een geheel cluster op een schone infrastructuur om disaster recovery te verifieren. De controle met elke keer exacte bestands grote geeft een goede indicatie hoelang recovery zou duren per account.

Bij geconstateerde problemen pakt een uitwijk locatie binnen kwartier de replicaties over en bij critifal failure hebben we nog twee losse backup diensten die als reserve op de achtergrond draaien. Deze worden een keer per maand getest en kunnen in tegenstelling tot de hoofdservice enkel gehele accounts terugzetten of gehele servers.

Fysieke opslag gaat gemiddeld zeven jaar mee voor we ze moeten vervangen dus de startup kosten zijn hoog maar de benodigde begroting daalt ook rap per jaar. En alles ligt altijd nog lager dan dat we moeten gaan uitleggen dat Pietje zijn mailtje is kwijt geraakt of Jantje zijn contracten.


Persoonlijk in twintig jaar gelukkig nog maar twee disaster recoveries meegemaakt maar kan niks anders adviseren dan please controleer je backup, draaiboek en hardware regelmatig want moment dat het misgaat ben je te laat.

En voor de gene die gebruik maakt van CD, DVD's voor backup houdt rekening met oxidatie en andere chemische reacties. Dit opslag medium is compleet ongeschikt voor langdurige opslag tenzij je het koel, droog en luchtdicht bewaard. De kwaliteit van de opslag fluctueert enorm van 5 tot 100 jaar shelflife. Ik zou het persoonlijk niet riskeren.

USB sticks zijn een goed alternatief ervoor qua kosten zelfs lager en vele malen makkelijker met eventueel goede kans op recovery van data mocht er toch schade zijn aan het medium.
16-12-2020, 13:20 door MathFox
Ik backup ook alleen configuratie en datafiles, voor systeemsoftware vertrouw ik op Debian netinstall.

Ik heb een eigen script dat met rsync kopieert naar een file server (daily, weekly, monthly); af en toe (maandelijks) maak ik een kopie van de backup boom op een externe HD.
16-12-2020, 14:51 door [Account Verwijderd]
Hoe vaak test jij je backups?

Elke keer als ik er een terug moet zetten hahahaha :)
16-12-2020, 17:10 door Anoniem
Het toeval wil dat ik een van mijn backupschijven nu aan het testen ben.

Ik werk met btrfs op Linux. Daarmee kunnen snapshots van een filesysteem gemaakt worden, die naar keuze read-write of read-only zijn. Voor backups maak je read-only snapshots. Dat doe je op een gemount filesysteem en dat is nagenoeg direct klaar. Een snapshot is een subvolume binnen het btrfs-filesysteem waarvan je de snapshot maakt en is benaderbaar (voor wie leesrechtern erop heeft) als een directory.

Subvolumes zijn met "btrfs send" en "btrfs receive" te kopiëren, op de lokale machine naar een andere schijf of over een netwerk. Als twee opeenvolgende snapshots aan de zendende kant bestaan en de oudste van de twee aan de ontvangende kant kan een volledige snapshot worden geconstrueerd aan de ontvangende kant door alleen de verschillen door te geven.

Die snapshots kunnen dus als backups op een of meer backup-schijven worden geplaatst, waarbij de initiële backup een langdurige operatie is en de vervolg-backups veel sneller gebeuren. In dat opzicht gedragen ze zich als incrementele backups, maar elke backup is op de backupschijf een subvolume die zich weer laat benaderen als een read-only directory die de complete kopie van het gebackupte filesysteem ontsluit. In dat opzicht gedraagt het qua benadering zich als een full backup (maar de snapshots delen wel de datablokken van ongewijzigde bestanden). Omdat het bepalen van de verschillen tussen twee snapshots niet gebeurt door bestanden te vergelijken maar op basis van onderliggende btrfs-opslagstructuren is het bepalen wat de verschillen zijn veel sneller dan vergelijking van bestanden, en zelfs dan het doorlopen van de directory-tree van een groot filesysteem om te inventariseren welke bestanden er staan. Oudere snapshots kunnen eenvoudig verwijderd worden.

Voor het testen van de backups vertrouw ik voornamelijk op het "btrfs scrub"-commando, dat, alweer op het niveau van de onderliggende btrfs-structuren, controleert of de checksums van de opslag kloppen. Daarnaast kijk ik voor de volledigheid of ik de directorystructuren zie die ik verwacht en of een paar losse bestanden op de backup identiek zijn aan het origineel. Maar als scrub geen fouten oplevert garandeert dat eigenlijk al dat het hele filesysteem integer is. Zo'n scrub is wat ik nu heb draaien. Die duurt ruim 2 uur voor een ongeveer half gevuld USB3-schijfje van 2TB.

Gebruikers van zfs hebben soortgelijke mogelijkheden, natuurlijk, dat heeft tot voorbeeld gediend voor btrfs. Wat inmiddels op Windows beschikbaar is aan dit soort mogelijkheden overzie ik niet. NTFS heeft dit soort mogelijkheden in ieder geval niet.
16-12-2020, 19:41 door Anoniem
Door Anoniem: En voor de gene die gebruik maakt van CD, DVD's voor backup houdt rekening met oxidatie en andere chemische reacties. Dit opslag medium is compleet ongeschikt voor langdurige opslag tenzij je het koel, droog en luchtdicht bewaard. De kwaliteit van de opslag fluctueert enorm van 5 tot 100 jaar shelflife. Ik zou het persoonlijk niet riskeren.

Goede punten. Maar mijn oom had een elektronica reparatie bedrijfje en hij zei dat DVD spelers voor audio superieur waren aan CD spelers voor audio. De datadichtheid van een CD is natuurlijk een stuk lager als van een DVD.

Op een CD doosje staat hoe je er mee om moet gaan. Elke keer dat je deze uit zijn doosje haalt om te testen komen er kleine krasjes op en andere beschadigingen.

Ik bewaar CD's en DVD's privé in het donker op een koel plekje. In een dichte kast om precies te zijn. (Zon-)licht is funest voor CD's. Je ziet ze dan helemaal geel worden is mijn ervaring. Hoewel ze vaak dan nog steeds leesbaar zijn.

Door CD's en DVD's op de een na hoogste snelheid te branden (met bijvoorbeeld het gratis CDBurnerXP minimal), voorkom je een hoop ellende. En als er af en toe een bitje omvalt, dan heb ik nog vele oude backups waar het bestand misschien wel goed op staat. Punt is dat ik mijn backups terug zet op het moment dat ik ze nodig heb. Ik start dus elke nieuwe computer of installatie met een maagdelijke user directory, wat ook nog de backup snelheid flink verhoogd.

Anoniem 12:35
19-12-2020, 19:00 door Anoniem
hd's tijdelijk
cdr éénmalig bechrijfbaar voor belangerijke bestand met apparte lezer en schrijf toestel
Ik heb verschillende niveaus en checksystemen. controle op enkele mp3 bestanden op wijzigingen ook enkele tekstbestanden met md5 en sha1 die onder het vizier van een programma staan honningpot principe mp3 zijn zeer delicaat voor crime.
Ik doe soms backups met ant script beveiligde bestanden met sleutels
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.