[Linux] Compressed incremental backups

[JeRa]

Ik heb het beheer over een aantal accounts waarbij ik per account de bestanden wil backuppen. Dit wil ik doen door één keer per week (maandag) een full backup te doen en de rest van de dagen (dinsdag - zondag) alleen de verschillen per account te backuppen om ruimte (en uiteindelijk ook dataverkeer) te besparen.

Dit alles wil ik gecomprimeerd hebben, bijvoorbeeld in het bzip2 formaat. Om een incremental backup te maken moet ik weten wat de verschillen zijn tussen nu en de vorige backup, en dat kan voor zover ik weet op twee manieren:
- binary diff (heb ik het liefste)
- datum laatste wijziging in acht nemen

Nu is er met tar wel het één en het ander mogelijk, maar structurele verschillen in de bestanden (zoals verwijderde bestanden/directories) zijn voor zover ik weet lastig vast te leggen in incremental backups. Nu heb ik genoeg programmeerkennis aan boord om zelf bovenstaand idee uit te werken en te implementeren, maar ik doe graag niet 2x hetzelfde werk en ik weet vrij zeker dat ooit iemand iets soortgelijks heeft willen uitvoeren. Dus weet iemand of zoiets mogelijk is met standaard beschikbare tools?

De hogere backupstrategie (waar de backups op te slaan, hoe te versturen etc.) is overigens al bepaald, het gaat me puur om het lokale backuppen.

[RgR]

Hier is een HOWTO Backup van de Gentoo- wiki. Het stukje over flexbackup is volgens mij precies wat je zoekt:

I use the following crontab to create my backups:

0 3 1-7 * * flexbackup -set all -full -w 7
0 3 * * 6 flexbackup -set all -differential
0 3 * * 1-5 flexbackup -set all -incremental

This will perform a full backup on the first Sunday of every month, a differential backup every Saturday, and an incremental backup every day of the week. All backups are performed at 3am.

Hier is meer informatie te vinden over flexbackup.

[JeRa]

Erg bedankt voor de suggestie. Ik heb het programma uitgeprobeerd, maar heb ontdekt dat er een verschil is tussen de full en de incremental backups. Ik quote uit mijn OP:

Nu is er met tar wel het één en het ander mogelijk, maar structurele verschillen in de bestanden (zoals verwijderde bestanden/directories) zijn voor zover ik weet lastig vast te leggen in incremental backups.

Als ik een directory backup, vervolgens een subdirectory uit die directory verwijder en een incremental backup maak, dan ziet hij geen verschil. Dat houdt dus in dat als ik de laatste backup zou restoren, ik de inmiddels verwijderde directory weer terugkrijg - en dat wil ik niet. Als gebruikers zelf bestanden weggooien dan is dat hun eigen fout en kunnen ze op aanvraag een oudere backup terugkrijgen, maar standaard moeten die verwijderde bestanden dus niet blijven bestaan in de backup.

Ook kan ik geen methode vinden om de incremental backups te maken a.d.h.v. binary diffs, dit hangt waarschijnlijk samen met het bovenstaande probleem?

[GoTman]

rdiff is mischien ook wel intresant om naar te kijken.
http://www.nongnu.org/rdiff-backup/

[JeRa]

GoTman schreef op dinsdag 23 januari 2007 @ 16:00:
rdiff is mischien ook wel intresant om naar te kijken.
http://www.nongnu.org/rdiff-backup/

Die heeft hetzelfde probleem als flexbackup, alhoewel rdiff-backup wél gecomprimeerde binary diffs kan maken toch bedankt.

[GoTman]

hmmz eigenlijk is dat best wel stom.
je moet dus eigenlijk gewoon 1 x week een full backup maken.
en die de rest van die week bij houden met incremental backups.

[JeRa]

GoTman schreef op dinsdag 23 januari 2007 @ 16:41:
hmmz eigenlijk is dat best wel stom.
je moet dus eigenlijk gewoon 1 x week een full backup maken.
en die de rest van die week bij houden met incremental backups.

Ja...dat wil ik dus ook gaan doen. Maar als iemand nou midden in die week een map met foto's van 200 MB weggooit en die ook niet meer terug wil zien, en ik restore de backups, dan staat die map er doodleuk weer.

Oh en tweede punt van rdiff-backup, de initiële backup was niet gecomprimeerd (de incremental backups wel).

[ Voor 10% gewijzigd door JeRa op 23-01-2007 16:49 ]

[Verwijderd]

Waarom gebruik je niet gewoon hardlinks i.c.m. rsync? Dan heb je weliswaar wat meer moeite met compressie, maar wel een heel eenvoudige manier om incrementeel te maken: elke backup is "compleet", maar d.m.v. hardlinks wordt dezelfde bit nooit twee keer opgeslagen. Just think about it...

[JeRa]

Verwijderd schreef op dinsdag 23 januari 2007 @ 21:02:
Waarom gebruik je niet gewoon hardlinks i.c.m. rsync? Dan heb je weliswaar wat meer moeite met compressie, maar wel een heel eenvoudige manier om incrementeel te maken: elke backup is "compleet", maar d.m.v. hardlinks wordt dezelfde bit nooit twee keer opgeslagen. Just think about it...

Een backup hardlinken is in mijn opzicht een beetje nutteloos
- hardlinken kan alleen op dezelfde partitie en dus op dezelfde schijf: schijf kapot, backup + originele bestanden weg
- als ik toch ga rsyncen kan ik net zo goed meteen de brondirectory pakken

rdiff-backup is bij nader inzien toch goed, maar die kan voor zover ik kan zien niet overweg met een compressed full backup. De incremental backups zijn wel compressed en verwijderde bestanden of mappen worden ook niet teruggezet.

[Verwijderd]

JeRa schreef op dinsdag 23 januari 2007 @ 21:24:
[...]

Een backup hardlinken is in mijn opzicht een beetje nutteloos
- hardlinken kan alleen op dezelfde partitie en dus op dezelfde schijf: schijf kapot, backup + originele bestanden weg
- als ik toch ga rsyncen kan ik net zo goed meteen de brondirectory pakken

rdiff-backup is bij nader inzien toch goed, maar die kan voor zover ik kan zien niet overweg met een compressed full backup. De incremental backups zijn wel compressed en verwijderde bestanden of mappen worden ook niet teruggezet.

Nee hoor, hardlinken kan ook op een andere partitie (zelfs een andere pc). Ik gebruik het hier ook. Elke dag draai ik onder windows een scriptje wat bepaalde mappen rsynct met een externe hardeschijf die aan een openwrt router hangt. Hij copieerd alleen de verschillen en toch heb ik uiteindelijk steeds een complete backup.
Zit je alleen nog met het compressen. Is dat echt nodig?

[JeRa]

Verwijderd schreef op dinsdag 23 januari 2007 @ 21:33:
[...]


Nee hoor, hardlinken kan ook op een andere partitie (zelfs een andere pc). Ik gebruik het hier ook. Elke dag draai ik onder windows een scriptje wat bepaalde mappen rsynct met een externe hardeschijf die aan een openwrt router hangt. Hij copieerd alleen de verschillen en toch heb ik uiteindelijk steeds een complete backup.

Als ik hardlink op een andere partitie dan wordt de vrije ruimte op die partitie minder met de hoeveelheid data die ik hardlink, dus in feite is dat toch gewoon kopiëren? Wat is het voordeel?

Zit je alleen nog met het compressen. Is dat echt nodig?

Niet persé, maar daar kan ik op zich nog wel omheen werken door een wrapper library voor rdiff-backup te schrijven die compressie na het backuppen toepast en vlak voor het restoren of het maken van een incremental backup

[Verwijderd]

JeRa schreef op dinsdag 23 januari 2007 @ 21:48:

Als ik hardlink op een andere partitie dan wordt de vrije ruimte op die partitie minder met de hoeveelheid data die ik hardlink, dus in feite is dat toch gewoon kopiëren? Wat is het voordeel?

Een hardlink neemt ook ruimte in beslag natuurlijk (ongeveer 4k ofzo). Het voordeel hiervan lijkt me logisch, als het bestand hetzelfde is copieerd hij het niet over maar maakt hij een hardlink naar de al bestaande data. Sync je bijvoorbeeld een film van 700MB die je al een keer hebt gecopieerd dan krijg je een alleen een hardlink van 4k (scheelt toch wel aardig ) naar het al bestaande bestand.

[JeRa]

Verwijderd schreef op dinsdag 23 januari 2007 @ 22:51:
[...]


Een hardlink neemt ook ruimte in beslag natuurlijk (ongeveer 4k ofzo). Het voordeel hiervan lijkt me logisch, als het bestand hetzelfde is copieerd hij het niet over maar maakt hij een hardlink naar de al bestaande data. Sync je bijvoorbeeld een film van 700MB die je al een keer hebt gecopieerd dan krijg je een alleen een hardlink van 4k (scheelt toch wel aardig ) naar het al bestaande bestand.

Ik geloof dat je me niet echt begrijpt heb je het eigenlijk al eens geprobeerd?

code:

ln: creating hard link `{target partitie B}' to `{source partitie A}': Invalid cross-device link

En als je dit via backupprogramma's doet zal het programma deze fout detecteren en het dus gewoon kopiëren.

Check je vrije ruimte op je partities maar eens, als jij cross partitions hard links denkt gemaakt te hebben, heb ik het vermoeden dat het gewoon kopieën zijn

[ Voor 15% gewijzigd door JeRa op 23-01-2007 23:29 ]

[Verwijderd]

JeRa schreef op dinsdag 23 januari 2007 @ 23:28:
[...]

Ik geloof dat je me niet echt begrijpt heb je het eigenlijk al eens geprobeerd?

code:

ln: creating hard link `{target partitie B}' to `{source partitie A}': Invalid cross-device link

En als je dit via backupprogramma's doet zal het programma deze fout detecteren en het dus gewoon kopiëren.

Check je vrije ruimte op je partities maar eens, als jij cross partitions hard links denkt gemaakt te hebben, heb ik het vermoeden dat het gewoon kopieën zijn

Aha op die fiets. Ik gebruikt het ln commando niet maar een paramter van rsync (--delete).
Zoiets dus, dit een regel uit het cmd scriptje wat ik elke dag draai:
rsync -va --delete --link-dest=../%tijd_vorige_backup% "/cygdrive/pad/naar/backup/" 192.168.0.2::backup/%tijd_huidige_backup%/

%tijd_vorige_backup% en %tijd_huidige_backup% komen uit een ander scriptje wat doet wat de naam aangeeft. Deze regel zorgt ervoor dat op de externe schijf elke backup in een nieuwe map terecht komt met de datum van de backup.

[ Voor 36% gewijzigd door Verwijderd op 23-01-2007 23:43 ]

[JeRa]

Verwijderd schreef op dinsdag 23 januari 2007 @ 23:36:
[...]


Aha op die fiets. Ik gebruikt het ln commando niet maar een paramter van rsync (--delete).
Zoiets dus, dit een regel uit het cmd scriptje wat ik elke dag draai:
rsync -va --delete --link-dest=../%tijd_vorige_backup% "/cygdrive/pad/naar/backup/" 192.168.0.2::backup/%tijd_huidige_backup%/

%tijd_vorige_backup% en %tijd_huidige_backup% komen uit een ander scriptje wat doet wat de naam aangeeft. Deze regel zorgt ervoor dat op de externe schijf elke backup in een nieuwe map terecht komt met de datum van de backup.

rsync zal uiteindelijk dezelfde kernel filesystem functies moeten aanroepen om een hardlink te maken, en ln is hier alleen een frontend voor probeer eens op jouw manier een backup te maken van 800MB op verschillende partities, als het goed is zul je zien dat je gewoon 800MB aan schijfruimte kwijtraakt.

[Verwijderd]

JeRa schreef op woensdag 24 januari 2007 @ 00:03:
[...]

rsync zal uiteindelijk dezelfde kernel filesystem functies moeten aanroepen om een hardlink te maken, en ln is hier alleen een frontend voor probeer eens op jouw manier een backup te maken van 800MB op verschillende partities, als het goed is zul je zien dat je gewoon 800MB aan schijfruimte kwijtraakt.

Hier ff een screenshot van de inode nummers van 2 bestanden. Deze zijn gelijk dus zijn het hardlinks.


Je kunt idd geen hardlinks naar een andere partitie maken. Een oplossing is om dit voor het rsyncen te doen. Je maakt op de machine waar de backups staan eerst gewoon hardlinks van de laatste backup. Vervolgens heb je dus 2 dezelfde backups (1 echte en 1 hardlinked). Vervolgens rsync je op die hardlinked backup. De bestanden die verschillend zijn worden dan overschreven.
In het ongunstigste geval zijn alle bestanden verschillend en heb je de hardlinks voor niets gemaakt.

[ Voor 6% gewijzigd door Verwijderd op 24-01-2007 00:41 ]

[Verwijderd]

Ik geloof dat we een beetje langs elkaar heen praten. Mijn aanname is dat je 1 backuppartitie hebt, en dat je daar incrementeel en soms volledig heen wil backuppen. Maak de volgende setup:

/backups/latest/
/backups/history/[datum]

en voer een rsync uit vanaf welke computer dan ook ter wereld naar /backups/latest. Vervolgens kun je de informatie in /backups/latest hardlinken naar /backups/history/2007-01-24 en heb je van elke dag een "volledige" backup, zonder dat een bit dubbel wordt opgeslagen.

De truuk hier, is dat rsync bestanden niet wijzigt/vervangt als ze niet veranderd zijn. Ongewijzigde zaken worden dus niet naar /backups/latest gesynced, en bestanden die meerdere malen in /backups/history voorkomen (maar door de tijd heen niet zijn veranderd), worden dus ook maar 1 keer opgeslagen.

Mocht ik je alsnog verkeerd begrijpen, dan geef ik het op.

[DiedX]

http://www.bacula.org

Kan alles wat je wilt, maar is WEL even wat werk om in te stellen.

[laurencevde]

Ik geloof dat jullie beiden niet echt snappen wat rsync nou precies doet met die hardlinks, of jullie lopen langs elkaar heen te praten.
Het kopieert de aangepaste bestanden naar de nieuwe backup-dir, en maakt in die dir voor de bestanden die niet aangepast zijn hardlinks naar dat bestand in de vorige backup-dir.(dus niet naar het originele bestand). Hierdoor is elke inremental backup een full backup, zonder dusdanig veel ruimte in te nemen.
Op deze manier moet de incremental backup dus wel op dezelfde partitie verblijven als de full backup.

hardlinks zijn trouwens niets meer dan een nieuwe naam naar hetzelfde bestand. Je kunt GEEN hardlinks maken naar een ander filesystem.

[JeRa]

@CyberKnutselaar & launrencevde

Ik snap wel hoe rsync omgaat met hardlinks, maar het is nog niet wat ik zoek. Ik zoek een universele manier om een full backup gecomprimeerd op te slaan, met daarnaast gecomprimeerde binary diffs.

Ik heb namelijk wat bestanden van diverse MB's (wel goed comprimeerbaar) die elke keer maar in een paar KB aan inhoud veranderen, maar door programma's als rsync en flexbackup worden die bestanden dus in hun geheel opnieuw opgeslagen in de incremental backup. Ik moet hierbij vermelden dat de ruimte voor backups op livelocatie schaars is.

@ DiedX

Bedankt, ik zal er eens naar kijken

[Pommi]

Ik ben hier momenteel ook mee bezig voor mijn werk. Web/Mail-servers worden op dit moment gebackupt door het tarren van de homedirs deze worden naar een offsite locatie ge-scp't. Dit kan natuurlijk beter

Dit vind ik een hele interessante link:
http://deb.riseup.net/backup/

De schrijver geeft hiermee de aanleiding tot het programmeren van backupninja (wat overigens niet is wat ik zoek), maar geeft wel een aardig overzicht van de bestaande tools. Het enige dat niet klopt is dat rsnapshot een push style heeft, maar een pull style.

De keuze die je voor jezelf moet maken is of je (qua besparing van ruimte) gaat voor compressie (waarbij het backuppen over het algemeen trager is) of hardlinks (waarbij het volume kan oplopen wanneer er veel wijzigingen zijn).

Ik denk zelf dat ik voor hardlinks ga, aangezien het heel gemakkelijk werkt. Het restoren is ook een fluitje van een cent. De tool die je hierbij gebruikt is een 2e vraag. Ik zou dan de volgende opties hebben: rsnapshot, rsback, snapback2, rlbackup of een eigen script.

[ph0t0nix]

DiedX schreef op woensdag 24 januari 2007 @ 19:42:
http://www.bacula.org

Kan alles wat je wilt, maar is WEL even wat werk om in te stellen.

Volgens de manual van bacula niet:

Files deleted after a Full save will be included in a restoration. This is typical for most similar backup programs (we have a project to correct this).

[ph0t0nix]

JeRa schreef op woensdag 24 januari 2007 @ 20:22:
Ik zoek een universele manier om een full backup gecomprimeerd op te slaan, met daarnaast gecomprimeerde binary diffs.

Ik heb namelijk wat bestanden van diverse MB's (wel goed comprimeerbaar) die elke keer maar in een paar KB aan inhoud veranderen, maar door programma's als rsync en flexbackup worden die bestanden dus in hun geheel opnieuw opgeslagen in de incremental backup.

Dat is een vrij ongewone manier van back-uppen, volgens mij. Ook bacula (zie hierboven) kan dat niet.

Ik denk dat de verwarring komt door het gebruik van het woord "incrementeel".
Normaal gezien is een incrementele backup een backup van alle complete files die sinds de vorige backup (incremental of full) veranderd zijn. Ook al is dat maar 1 byte.

Jij bedoelt met "incremental" dat verschillen per file gebackupt worden (alleen die ene veranderde byte). Meer zoals je met een versbeheersysteem als RCS of subversion doet (vandaar dat je binairy diffs wilt maken).

Misschien moet je op de een of andere manier de inhoud van de accounts dagelijks in een subversion repository stoppen (hoewel ik niet weet of subversion bij verschillen in een binaire file ook daadwerkelijk alleen de bindiff opslaat, of toch de hele vernieuwde file).