[Løst] Daglig offsite backup av store filer

[petterg]

Jeg ser etter egnede måter for offsite backup av vm-diskfiler. Dvs filer på størrelse 10-300GB. Onsitebackupen tar en full kopi over NFS til linuxserveren. Dvs at jeg trenger å bruke denne onsite fulle backupen til å lage en inkrementell (til nød differensiell) offsite backup. Her sliter jeg med å finne egnede løsninger.

 

Rsync har visse ulemper. Bl.a. er den dårlig egnet for store filer, og lagringn blir ukomprimert.

 

Det jeg ser for meg som en mulig løsning er at man har en førstebackup som legges både på onsite og offsite server. Når onsite backup får en ny full kopi diffes denne med førstebackupen, diffen komprimeres og sendes offsite for lagring. Dette bør kunne funke helt til diffen blir stor.

 

Noen bedre forslag?

 

Edit: Jeg vil gjerne lagre historikk om det ikke tar for mye plass.

 

 

Løsning: obnam

Endret 16. juli 2014 av petterg

[Rusher]

Crashplan

[rockPaperScissors()]

CrashPlan er typisk live-backup løsning, og krever derfor en god del ressurser. Du kan bruke det for offsite (skytjeneste) og onsite backup (gratis). For VM bilder så må du vurdere om du ønsker å bare kjøre CrashPlan fra onsite backup serveren slik at CrashPlan får tid nok til å håndtere komplette "snapshots" før filene endres.. Ellers er CrashPlan ett "installer og glem" produkt, veldig greit sånn sett.

[petterg]

Kan ikke si at jeg fikk følelsen av å være på rett sted da jeg leste om crashplan. Den retter seg mot backup av dokumenter på arbeidstasjoner. Det er noe som rsync/rdiff/rsnapshot/unison allerede gjør minst like bra (hvis man ser bort fra markedsføringen). Store filer hvor bare en liten del endres er et ganske annet fagområde.

[rockPaperScissors()]

Nah, CrashPlan er mye mer enn rsync/rdiff/rsnapshot/unison. Jeg liker at du får backup i tid, og backup-filene er krypterte. Men du har rett i at CrashPlan er mer for vanlige brukere. 300GB backup offsite vil ta mange dager å laste opp, skytjenesten deres makser ikke linja for å si det mildt. Men på den andre siden koster det jo ikke allverden.

[petterg]

Å sende til en skytjeneste er uansett uaktuellt. Jeg skal ha full kontroll på hvem som har fysisk og remote tilgang til serverene. Initiell backup gjøres med alle servere på samme lokasjon. Så flyttes backupserver til sin lokasjon. Med inkrementell overføring får den kanskje 300MB overført pr dag. Uten inkrementell overføring ville det blitt et par TB per dag og rimelig uaktuellt å gjennomføre.

[rockPaperScissors()]

CrashPlan støtter inkrementell og differensiell backup, og du kan ta backup til din egen server og flere backup mål etter behov.

[Rusher]

Crashplan gjør alt du etterspør.

[siDDis]

ZFS snapshots har moglegheiter for inkrementell backup.

 

Men er Rsync er godt eigna for store filer, og du kan komprimere dataen med -z flagget.

[petterg]

zfs snapshot og backup ser ut som den idelle måten å gjøre dette på!

Noen som vet hvordan den avgjør om en blokk er endret? Hvis man f.eks har en kopi av fil A liggende ved et snapshot, og senere kopierer (og overskriver) denne filen med en identisk kopi av samme fil med samme navn, vil diff ved neste snapshot inneholde hele fil A, 0 byte eller noe imellom?

[siDDis]

Overskriver du heile filen så vil neste snapshot innehalde heile fila.

Men! Bruker du deduplisering, så vil bare endringar sidan forrige gong vere med. Men deduplisering er treigt, svært tregt. Du vil ha ein skriveytelse på 5-20MB i sekundet, avhenging av kor mykje ram serveren har.

 

Eg trur du kjem lengre med å bruke rsync. Det er truleg fleire options som kan hjelpe deg med overføringa.

Alternativer er rdiff, rbackup og rsnapshot.

[hernil]

Selv vil jeg foreslå å kikke på btrfs. Meget mye likt med zfs, men f.eks deduplisering krever mindre ram. Du kan også synke diffen av et snapshot mot et annet btrfs-filsystem. Noe som nok vil være midt i blinken for din del for backup av store filer. VM-filene vil sikkert i snitt bare endre seg et par hundre megabyte, toppen et par giga og da har du plutselig en helt overkommelig datamengde å ta backup av. Btrfs har fordelen av å være fleksibelt for utvidelse i ettertid, men skal du bruke dette i prod og trenger noe annet enn raid 0/1 eller kombinasjoner av disse så ville jeg nok heller satset på zfs.

 

Andre ting som kan være verdt å kikke på er zsync (rsync-ish for store filer) og eventuelt btsync (avhengig av om de har fått på plass så de ikke synker hele filen for hver gang). Crashplan ville jeg holdt meg langt unna for annet enn personlig bruk. Kjørte det for offsite backup av en filserver og i tillegg til å bruke nærmere 100% cpu på flere kjerner så endte den etterhvert opp med å ikke ta backup av mer enn 1/3 av filene over lengre tid, uten å si ifra til oss. Hadde ting gått til helvete lokalt før vi oppdaget det hadde vi gått på en grundig smell!

[petterg]

btrfs var totalt fremmed for meg. Meget god ide! Det ser ut til å ha et godt potensiale for dette formålet. Leser nå på denne:

http://marc.merlins.org/perso/btrfs/post_2014-03-22_Btrfs-Tips_-Doing-Fast-Incremental-Backups-With-Btrfs-Send-and-Receive.html

 

 

Btw: Hva er forskjellen på rbackup og rdiff-backup?

[endrebjo]

zfs snapshot og backup ser ut som den idelle måten å gjøre dette på!

Noen som vet hvordan den avgjør om en blokk er endret? Hvis man f.eks har en kopi av fil A liggende ved et snapshot, og senere kopierer (og overskriver) denne filen med en identisk kopi av samme fil med samme navn, vil diff ved neste snapshot inneholde hele fil A, 0 byte eller noe imellom?

ZFS endrer eller overskriver aldri blokker siden all skriving gjøres som copy-on-write. Det vil si at når du overskriver den gamle filen med en ny en, så blir den skrevet til en helt annen plass på disken, også blir filpekeren etterpå flyttet til denne plassen. Så det fungerer dessverre dårlig med block-level snapshots i ditt tilfelle.

 

Men hele opplegget med å i utgangspunktet ta en full kopi hele imaget er det som er det virkelige problemet her. Denne praksisen fører til at du må hacke sammen den inkrementelle biten selv. For meg høres det ut som at du prøver å lappe på noe hvor du egentlig burde ha begynt i andre enden. Hvorfor kan ikke backupen gjøres inkrementelt allerede på hovedserveren? Det er den som vet best hva som er forandret og ikke. F.eks gjennom zfs snapshots. Uansett hvilken plattform applikasjonen kjører på kan du f.eks ha et iSCSI-SAN med UNIX/BSD og ZFS i bunn hvor ZFS enkelt tar seg av inkrementell backup til både onsite og offsite backup vha snapshots.

Endret 29. juni 2014 av endrebjo

[petterg]

Hovedserver er ESXI. Ingen mulighet til zfs der.

Å kjøre iscsi vil kreve en ekstra varmeproduserende server, som betyr nødvendig investering i kjøleanlegg, som igjen betyr mer uønsket støy. Backupserveren nå slår seg på om natta, og skrur seg av igjen når backup er fullført. Den lager altså varme kun en kort periode på et tidspunkt hvor sola ikke bidrar til varme.

 

Takk for forklaringen om copy-on-write. Da er jeg tilbake på at rdiffbackup eller rbackup (hva er forskjellen på dem?) er best egnet.

[siDDis]

http://superuser.com/questions/386025/what-is-the-difference-between-rsnapshot-and-rdiffbackup

[petterg]

http://superuser.com/questions/386025/what-is-the-difference-between-rsnapshot-and-rdiffbackup

 

 

I Would add, for the sake of completeness that there exists rbackup which is just a wrapper script around rdiff-backupto ease snapshot management, more like rsnapshot's way of managing snapshots (easier to configure)

 

Det er det eneste jeg har lest om forskjellen på rbackup og rdiffbackup. Alle andre steder står det at de er tilnærmet like, og listet opp noen av likhetene.

[petterg]

Løsningen heter obnam. Den funker overraskende bra på min lille test. Det mest imponerende er at den takler litt like filer veldig bra. F.eks:

snapshot av vm -> vm-snap1.bak

noen timer senere, et nytt snapshot av vm -> vm-snap2.bak

 

obnam sendte 4,7GB med data ved backup av den første filen. Det var en diskfil på 16GB med 5,8GB brukt. Obnam hoppet da altså elegant over de ubrukte områdene, og komprimerte det resterende tålelig greit.

 

Deretter skulle den ta den andre filen. Da sendte den kun 90MB, selv om filen heter noe annet, ligger parallelt med den første og har både annen størrelse og annet tidstempel.

 

På en 20mbit linje brukte den 46 minutter på første fil. Den andre var ferdig allerede da jeg så på den etter 3-4 minutter.

[Gavekort]

dsf

Endret 16. juli 2014 av Gavekort

[hernil]

Kult!