Incrementeel backupen met rsync

[Keiichi]

Wellicht een niet al te handig gekozen titel, omdat rsync eigenlijk al incrementeel backupt.

Momenteel maak ik elke dag backups via rsync naar een andere server toe. Nadeel hiervan is dat ik slechts 1 moment opname heb. Door op extra momenten rsync te laten draaien naar verschillende directories kan ik backups van verschillende dagen hebben. Maar die vereist de nodige ruimte.

Is het ook mogelijk om een directory als 'basis' directory te gebruiken en een andere directory alleen maar weg te schrijven wat daadwerkelijk veranderd is?

[blaataaps]

--link-dest, of handmatig met cp -al, of een handig frontend voor sync gebruiken.

[soczol]

Je zou eens kunnen kijken naar rsnapshot.

Deze tool maakt handig gebruik van rsync en hardlinks om een "snapshot" tree te bouwen. Alleen als een file gewijzigd is dan zal deze via rsync opgehaald worden. Is een file ongewijzigd, dan wordt er simpelweg een link gemaakt naar deze file in de vorige snapshot, deze is immers nog precies hetzelfde.

Deze constructie zorgt ervoor dat je wel altijd een 'complete' snapshot hebt van datgene wat je wilt backuppen, maar dus niet met vele kopietjes van dezelfde files komt te ziten - enkel files die ook daadwerkelijk gewijzigd zijn zullen fysiek op je disk aanwezig zijn

[ Voor 8% gewijzigd door soczol op 05-02-2009 12:38 ]

[mithras]

Ikzelf ben meer met rdiffbackup bezig. Het is GNU software wat imho heel fijn werkt voor incrementele backups / restore punten

[Verwijderd]

rsnapshot en rdiffbackup zijn twee prachtige stukjes software voor dit soort doeleinden.

[Keiichi]

Ik heb even naar rdiffbackup gekeken.

Dat ziet er erg goed uit

[gertvdijk]

rdiffbackup werkt inderdaad voortreffelijk, maar het heeft m.i. één groot nadeel: de protocollen tussen de verschillende versies zijn niet backwards compatible. Zo kreeg ik laatst een update via etch-backports waardoor ineens stilzwijgend de backups met een Ubuntu 8.04 machine niet meer draaiden met zeer cryptische foutmeldingen en vage Python errors. Bij nader onderzoek bleek dus de Etch versie te oud, de Etch-backports te nieuw en de verschillen tussen hardy-updates en hardy-backports waren te klein. Een oude versie op de Hardy doos ging niet vanwege dependency errors en de etch-backports is nieuwer dan die in de Jaunty repo's. Een 'oude' Jaunty package handmatig installeren bracht te oplossing. Maar het blijft dus opletten... Echt stom dat ze niet even gewoon backwards compatibility inbouwen...
Daarnaast kan je de oude gebackupte data niet meer gebruiken na een upgrade... Dus dan ben je je hele incrementele geschiedenis kwijt.

[ Voor 18% gewijzigd door gertvdijk op 05-02-2009 18:08 ]

[Keiichi]

gertvdijk schreef op donderdag 05 februari 2009 @ 18:06:
rdiffbackup werkt inderdaad voortreffelijk, maar het heeft m.i. één groot nadeel: de protocollen tussen de verschillende versies zijn niet backwards compatible. Zo kreeg ik laatst een update via etch-backports waardoor ineens stilzwijgend de backups met een Ubuntu 8.04 machine niet meer draaiden met zeer cryptische foutmeldingen en vage Python errors. Bij nader onderzoek bleek dus de Etch versie te oud, de Etch-backports te nieuw en de verschillen tussen hardy-updates en hardy-backports waren te klein. Een oude versie op de Hardy doos ging niet vanwege dependency errors en de etch-backports is nieuwer dan die in de Jaunty repo's. Een 'oude' Jaunty package handmatig installeren bracht te oplossing. Maar het blijft dus opletten... Echt stom dat ze niet even gewoon backwards compatibility inbouwen...
Daarnaast kan je de oude gebackupte data niet meer gebruiken na een upgrade... Dus dan ben je je hele incrementele geschiedenis kwijt.

Ik zal daar eens wat beter naar kijken. Opzich heb ik van automatische updates geen last. Draai slackware en compile alles zelf

Zijn er mensen met concrete ervaringen met rsnapshot? Die heb ik nog onaangeraakt gelaten, maar dat hoeft niet. Ben immers toch nog orienterend.

[Verwijderd]

Hmm, bij nader inzien lijkt rsnapshot de betere keus. Hier een mooie vergelijking:

http://www.saltycrane.com...linux-rsnapshot-vs-rdiff/

[arjanH]

Ik doe het met rsync zo (incremental backup van een smb locatie):

#!/bin/sh
# contact: mail@***********

echo "Backup wordt gestart, " `date`;

# mount netwerk schijf (G:), -r voor read-only
mount -r -o username=Backup,password=****** //192.168.131.1/groups /smb

rsync -vaz /smb/ /data/backup-server01/backup/today >> /data/backup-server01/logs/`date "+%d%m%y-%H"`.log

# haal de netwerk schijf weer weg.
umount /smb

cp -al /data/backup-server01/backup/today /data/backup-server01/backup/`date "+%d%m%y-%H%M"`
echo `date` >> /data/backup-server01/log.txt


staat in een scriptje welke dmv cron wordt uitgevoerd. is gemakkelijk terug te zoeken op datum.

[ Voor 30% gewijzigd door arjanH op 11-02-2009 18:53 ]

[stat]

Misschien ligt het aan mij, maar deze functionaliteit zit toch in Rsync? Ik ben er nog niet zolang mee bezig, maarals je het 1ste example script neemt op http://samba.anu.edu.au/rsync/examples.html, dan wordt een kopie bewaart van de bestanden die veranderd zijn. It works for me...

[Keiichi]

stat schreef op woensdag 11 februari 2009 @ 18:32:
Misschien ligt het aan mij, maar deze functionaliteit zit toch in Rsync? Ik ben er nog niet zolang mee bezig, maarals je het 1ste example script neemt op http://samba.anu.edu.au/rsync/examples.html, dan wordt een kopie bewaart van de bestanden die veranderd zijn. It works for me...

Het kopieren van bestanden gebeurd incrementeel ja. Maar volgens mij heb je bij die examples dat je 7 complete snapshots als het ware hebt.

[CyBeR]

Ligt eraan wat je precies wilt. Met rsnapshot heb je, een beetje verstopt, directe file trees omdat er hard links gebruikt worden voor alles. Maar dat houdt wel in dat een grote file van 3GB waarin een paar bytes gewijzigd worden in elke snapshot de hele 3GB inneemt. Met name bij mbox files is dit bijvoorbeeld onhandig. (Ja, er is maildir, maar het principe he). Met rdiff-backup heb je één tree die je, als 't nodig is, direct kunt kopieren en gebruiken mocht je dus echt alles kwijt zijn. Voor a la carte restores van kleinere onderdelen van de tree, omdat je een enkele file aangepast hebt drie weken geleden en je wilt die versie terug, moet je even via rdiff-backup werken. Daar staat dan wel tegenover dat rdiff-backup alleen de verschillen in files opslaat, en dat nog gzipt ook. Dus je hebt dan niet meer het probleem van 3GB files met kleine wijzigingen.

Welke het beste is ligt dus puur aan je situatie.

[stat]

Nee, ik weet zeker (heb het namenlijk zelf geprobeerd) dat alleen de veranderde bestanden bewaard worden. Dus in de locatie die je opgeeft staat altijd de laatste versie van alles, in de backupdir staat het overschreven bestand. Probeer het zou ik zeggen. Succes ermee!
Ik heb het draaien vanuit windows, en gebruik een batch bestond om automatisch een directory met de dag van de week te maken.

Ik poste net iets later dan CIber. Inderdaad, dit systeem heeft als nadeel dat bv zo'n mailbestand 7x op de schijf komt. Maar de hoeveelheid getransferde data is dus wel klein (namenlijk steeds alleen het nodige). Hangt inderdaad af van je situatie.

[ Voor 24% gewijzigd door stat op 11-02-2009 20:15 ]

[CyBeR]

stat schreef op woensdag 11 februari 2009 @ 20:13:
Nee, ik weet zeker (heb het namenlijk zelf geprobeerd) dat alleen de veranderde bestanden bewaard worden. Dus in de locatie die je opgeeft staat altijd de laatste versie van alles, in de backupdir staat het overschreven bestand. Probeer het zou ik zeggen. Succes ermee!

Ja, dat klopt. Alleen veranderde bestanden. Dat ontken ik niet Ik stel dat als een bestand veranderd is, zelfs al is 't maar 1 byte in een file van een paar gigabyte (metadata in een film, ik zeg maar wat) dan moet met rsnapshot die hele file opnieuw als geheel gebackupped worden (en als geheel over 't netwerk heen gezet geloof ik ook). Dat is omdat rsnapshot gewoon met hardlinks steeds naar dezelfde file op het filesystem wijst. rdiff-backup doet dat niet maar slaat alleen de verschillen op.

Mijn ervaring is overigens ook dat rdiff-backup een stuk minder load op je machine oplevert.

Oh je had 't niet tegen mij

[ Voor 3% gewijzigd door CyBeR op 11-02-2009 20:17 ]