Gør som jeg siger, ikke som...

Det sidste jeg gør inden jeg går i seng, er at starte en "stow" fra min laptop til min filserver.

"Stow" er en backup-facilitet jeg selv skrev for mange år siden, som bla.a laver de-duplikering og gør time-travel muligt.

Men igår væltede den med en eller anden fejl i Berkeley DB og efter at have gravet lidt i det, kunne jeg konstatere at min "btree" fil var syg og at der ikke findes nogle værktøjer til at reparere en gammel 1.85 DB fil med.

Æv, Bæv!

Totalt set ligger der omkring 70GB og omkring 3 mio filer i mit "stow" arkiv og de ældste filer er vist nok fra omkring 2000, men jeg mener at erindre at en stak endnu ældre backup'er er fyldt derned også.

Det siger sig selv at jeg ikke har planer om bare at smide det hele væk.

Heldigvis har jeg hørt en lille smule efter mig selv, så langt de fleste data er selvforklarende og derfor kan man med en passende mængde CPU tid genopbygge indexet igen, bortset fra de filer der er "composited" og som er ramt af DB::btree fejlen.

I teorien burde en DB fil ikke kunne gå i skudder-mudder, men i teorien er der ikke mange af de ting der sker i praksis der kan ske.

Der er naturligvis tale om en designfejl: DB filen er bare et index/cache, så alle data burde også ligge andre steder end der, men det var så dejlig nemt lige at proppe dem derned og så hente dem derfra igen når et off-line media skulle genereres.

Jeg er gået i gang med en helt ny version af stow, denne gang i python og denne gang med rigtige recoverable data strukturer.

Så kan jeg lære det kan jeg...

phk

Kommentarer (34)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Rasmussen

rigtige recoverable data strukturer

Noget du selv skriver fra bunden af, eller findes der et bibliotek til formålet?
Hvordan definerer du en recoverable datastruktur? selv contained, eller kræves der input fra bruger/andre data?
Det må jo i sagens natur bygge på en dynamisk datastruktur, så hvorledes vil du håndtere memory corruption eller anden hardware fejl? Løbende check mod en hash, gemme redundant data etc.

Jeg spørger af personlig interesse, da jeg til dagligt beskæftiger mig med HA database baserede systemer, så emnet er super relevant:-)

Baldur Norddahl

Der er en grund til at bånd er så gode: I tilfælde som dette vil du bare kunne finde et ældre bånd og indlæse. Det giver dig naturligvis ikke de nyeste data, men alt det gamle er redet.

Jeg har ikke fidus til rene "online" backup strategier. Tænk hvis man fik virus, blev hacket, udsat for seriøs hardware fejl eller bare rammer en bug - og pludselig er det hele væk eller korrupt. Det kan selv den bedste datastruktur ikke beskytte imod.

Hvis backuppen absolut skal ligge på en harddisk, så skal det være på en ekstern harddisk der fjernes og lægges i skabet. Offsite selvfølgelig.

Jeg er selv i den heldige situation, at have adgang til en server som der laves rigtig backup til bånd af. Jeg laver daglig backup af min laptop dertil. Jeg bruger det indbyggede backup i Ubuntu, det er udmærket.

Anonym

Jeg har selv brugt juleferien til at omlægge min egne backup rutiner.

Tidligere tog jeg lokale backups til Time Machine (Mac - hovsa backup hvis man lige kommer til at slette et eller andet), Chronosync til NAS (basalt set en rsync med en GUI), og så backup af digitale billeder til Amazon S3 via Arqbackup.

Men backuppen til S3 var ved at blive lidt dyr pga pladsforbrug med billederne, så der skulle ske noget.

Jeg har fået sat en NAS op ved mine svigerforældre, som de tager backup til, og så var det jo oplagt at jeg endelig fik taget mig sammen til at sætte noget backup mellem de to.

Så nu er rutinerne:
Jeg har en række backups, som jeg har delt op i krypterede sparsebundles liggende på vores NAS, hver nat sker der en rsync af den mappe de ligger i hjem til mine svigerforældre. De selvsamme data bliver også hver nat kopieret til en USB disk koblet på vores NAS.

Ved mine svigerforældre sker der en lokal crashplan backup (jeg kunne simplethen ikke finde et gratis backup program til windows jeg stolede nok på, så det endte foreløbig med den nemme løsning - jeg skal nok finde noget rsync til deres windows maskinener, men det bliver senere). Denne crashplan backup ligger så på deres NAS og der bliver taget rsync hjem til vores NAS hver nat.

Nu er det så planen at prøve at køre med dette i nogle uger og så teste en komplet restore (sikkert i vmware), og se om er sikkert nok at droppe S3 backuppen.

Forbindelsen mellem de to NAS er fiber. Vi har en 60/60 og de har en 40/40 (måske "kun" en 30/30, men ser jeg på trafikken matcher det mest 40/40 fra deres siden af)

Anonym

rsync køre glimrende i cygwin, og hvis man er plaget af en windos maskine kan man jo alligevel ikke leve uden cygwin og windos eller ej hvem kan leve uden rsync

Jeg må gå i google mode og se om jeg ikke kan finde en god rsync wrapper til Windows - min svigerfar vil meget gerne have at han kan se at programmet kører (systray ikon), så jeg kan ikke have et eller andet cmd script - eller hvad man bruger på windows disse dage - kørende helt i baggrunden (hvilket jeg selv ville foretrække).

Thue Kristensen

men jeg mener at erindre at en stak endnu ældre backup'er er fyldt derned også.

Det lyder mere som en opbevaring end som en "backup", siden data kun eksisterede i dit stow-arkiv.

Jeg bruger selv rdiff-backup (som kan varmt anbefales!) til backup, men jeg er paranoid til at have sat mit script op til en gang imellem at lægge en kopi af de vigtigste data separat fra rdiff-arkivet, hvis nu arkivet bliver korrupt.

Thue Kristensen

rdiff-backup har også den dejlige egenskab, at den opbevarer den primære back som som et ganske almindeligt filsystem, og så opbevarer historien i binært format.

Dvs at det problem som du har med et korrumperet indeks simpelthen ikke kan forekomme for den seneste backup (med mindre hele filsystemet går i stykker, men det problem har stow jo også).

Casper Bang

En kammerat og jeg har længe gerne villet have et alternativ til Dropbox der virker på samme måde, men egen server-infrastruktur.

Det er rigtigt at der ikke er nogen god åben filsynkroniseringsservice protokol, men som alternativ kan man leje en lille dedicated server og køre SFTP og mounte drev transparent. Denne løsning har den fordel at du aldrig render ind i synkroniseringsissues (filerne er ej distribuerede kopier) og giver max. upload/download da din service provider normalt sidder på nogle fede linier. Denne løsning har jeg med tilfredshed brugt i årevis, sågar fra Windows via ExpanDrive. Ulempen er at løsningen ikke er delta-baseret, så man skal helst ikke arbejde med alt for voldsomme filer.

Men mon ikke vi er en del der venter på at Google launcher GDrive og (forhåbentlig) en åben protokol dertil. :)

Rasmus Rask

tjek evt. Deltasync for at få en Rsync Windows klient

Sidst jeg kiggede på Deltasync på Windows, havde jeg problemer med ikke-ASCII tegn i fil- og mappenavnene.

Filerne blev kopieret over, men ÆØÅ og visse andre specielle tegn blev vist som firkanter. Det var Windows ikke glad for at tilgå efterfølgende.

Så vidt jeg kunne læse mig til, skyldes det manglen på unicode-support i et af de underliggende komponenter.

Dengang havde jeg ikke tid/evner/begge til at løse det. Har andre været dygtigere end mig på det punkt?

Martin Skøtt

Jeg bruger selv Tarsnap og det er jo ganske nemt, men prøv lige at restore data. Det tager helt uhyggeligt langt tid - har været oppe på 30-45 minutter for ca. 100Mb.

Colin er klar over problemet, men hvis man regner med at lave mange restores så skal man lige tænke sig om inden man comitter sig til Tarsnap.

Klavs Klavsen

Jeg bruger også selv rdiff-backup - men den har ikke den dejlige feature som gør Stow unik (og som gør at jeg har overvejet at skifte til den til nogen ting) - nemlig at opdage når en fil "bare er flyttet/duplikeret".

Det er simpelthen noget rsync (og rsync libs - som rdiff-backup anvender) ikke understøtter.

Det generer mig hver gang jeg eller min kone får sorteret lidt i vores mange GB store samling familie billeder/film - alt det vi har flyttet - bliver uploadet (igen) til mit offline backup - via vores sølle 2mb upload link :(

Lars Bjerregaard

Hej PHK

Jeg kan se at den nye Python version af stow ligger her - https://github.com/bsdphk/PyStow - og at du senest har arbejdet på den for 9 måneder siden. Hvordan skrider den frem? Er den brugbar allerede nu?

Stow ser interessant ud, og ligner for mig "den rigtige/smarte måde" at tage backup på. Hvis jeg ikke tager fejl, burde det også være trivielt at bruge rsync til at lave mirrors/kopier af sine backuparkiver til andre lokationer.

Log ind eller Opret konto for at kommentere