Tar - selectief een 20GB tarball uncompressen

[Verwijderd]

Wij maken voor onze klanten dagelijks backups van alle servers. Indien een klant wil dat we een website terugzetten, dan is dit mogelijk. Echter pakken we momenteel een tarball van 30GB eerst uit, waarna we hem pas kunnen terugzetten.

Ik heb al gekeken op http://unixhelp.ed.ac.uk/CGI/man-cgi?tar en veel gezocht op Google. Dus hierbij mijn vraag aan jullie:

Hoe pak ik slechts "/home" uit van een 30GB tarball?
tar -xcvf tarfile.tar.gz = totaal uncompressen
Echter wat als ik slechts 15mb nodig heb op een bepaalde locatie?

[BCC]

Tar gzip is twee stappen. Eerst mik je alles in 1 file (Tape Archive) en dat gzip je vervolgens (GnuZip). Volgens mij is het onmogelijk in je tape archive te trekken zonder hem eerst te unzippen, but please do prove me wrong

Ander backupschema? Al naar rdiff-backup gekeken?

[ Voor 10% gewijzigd door BCC op 06-05-2008 20:48 ]

[Osiris]

Wat is er mis met:

tar xvf tarfile.tar.gz home

Werkt hier prima in een mini-testcaseje

[TrailBlazer]

eerst met tar tvf kijken wat er in zit en dan kan je gewoon een selectie eruit vissen hoor.

code:

epia:/home/testje# ls
all.tar
epia:/home/testje# tar tvf all.tar
-rw-r--r-- root/root         0 2008-05-06 20:51 1
-rw-r--r-- root/root         0 2008-05-06 20:51 10
-rw-r--r-- root/root         0 2008-05-06 20:51 2
-rw-r--r-- root/root         0 2008-05-06 20:51 3
-rw-r--r-- root/root         0 2008-05-06 20:51 4
-rw-r--r-- root/root         0 2008-05-06 20:51 5
-rw-r--r-- root/root         0 2008-05-06 20:51 6
-rw-r--r-- root/root         0 2008-05-06 20:51 7
-rw-r--r-- root/root         0 2008-05-06 20:51 8
-rw-r--r-- root/root         0 2008-05-06 20:51 9
epia:/home/testje# tar xvf all.tar 3 4 5
3
4
5
epia:/home/testje# ls
3  4  5  all.tar
epia:/home/testje#

ja ik weet het ik werk als root en ik zal branden in de hel.

[ Voor 80% gewijzigd door TrailBlazer op 06-05-2008 20:57 ]

[Verwijderd]

Het gaat wel een stuk langzamer heb ik het gevoel.
tar -zxvf log.tar.gz log/httpd

Het werkt inderdaad perfect!
Maar ongelooflijk langzaam als ik het probeer bij een grote tarball.
Alsof hij op volgorde de hele tarball afloopt

[TrailBlazer]

dat zou best kunnen omdat een tape ook nogal sequentieel is. Mischien eens naar een andere backup methode gaan kijken.

[Verwijderd]

Ik gebruik een SuperMicro Server met 2x "Samsung SpinPoint 500 GB SATA-II 7200 RPM" in RAID(0).

[TrailBlazer]

ik bedoel gewoon tar is eigenlijk niet zo'n heel handige tool om er specifieke files uit te trekken. Het is gemaakt voor tape drives die alleen maar sequentieel werken. Die scannen gewoon de hele tape en halen er dan de bestanden af die je wil hebben.

[RemcoDelft]

Verwijderd schreef op dinsdag 06 mei 2008 @ 21:06:
Alsof hij op volgorde de hele tarball afloopt

Dat zou me op zich niks verbazen, gezien het feit dat de de tar zelf ook nog gecomprimeerd is...

[TrailBlazer]

Ja hij zal dus alsnog het hele bestand moeten decompressen en dan pas gaan kijken welke je wil hebben. Omdat je geen 30 gb aan geheugen hebt zal die wel gaan swappen dus alsnog traag.

Je backup methode is gewoon iet geschikt om indivudele files te restoren. Een incremental backup is al een hele verbetering lijkt me.

[Verwijderd]

Allemaal bedankt voor jullie hulp! Het is nu helemaal duidelijk.

De huidige oplossing is erop gericht dat bij een hardware-storing, de sites zo snel mogelijk weer online kunnen op een andere server.

Het komt weleens voor dat een klant data per ongeluk heeft verwijderd. Tegen een vergoeding van EUR 35,00 halen wij dan hun data op basis van de server-image van de backupserver terug.

Het is niet anders. Ik zal de vertraging moeten accepteren. Het is nog steeds 2x zo snel als alles uitpakken.

[ Voor 13% gewijzigd door Verwijderd op 06-05-2008 21:30 ]

[Osiris]

TrailBlazer schreef op dinsdag 06 mei 2008 @ 21:19:
Ja hij zal dus alsnog het hele bestand moeten decompressen en dan pas gaan kijken welke je wil hebben. Omdat je geen 30 gb aan geheugen hebt zal die wel gaan swappen dus alsnog traag.

Euhm, is dat zo? Werken gzip/bzip2 niet in blocks of iets dergelijks? Want dan zou het op normale PC's 'onmogelijk' zijn om bijvoorbeeld een DVD-tje te gzip/bzip2-en.

quote: http://en.wikipedia.org/wiki/DEFLATE

A Deflate stream consists of a series of blocks. Each block is preceded by a 3-bit header:

Staat niet bij hoe groot een block is though, maar dat zal wel geen 30 GB zijn

[ Voor 19% gewijzigd door Osiris op 06-05-2008 21:39 ]

[TrailBlazer]

ok dan zat ik daar mis.

[RemcoDelft]

TrailBlazer schreef op dinsdag 06 mei 2008 @ 21:19:
Ja hij zal dus alsnog het hele bestand moeten decompressen en dan pas gaan kijken welke je wil hebben.

Is het wellicht een optie om de gz en tar om te draaien?
Dus: eerst alle files afzonderlijk comprimeren, en daarna pas tot tar verwerken?

[TrailBlazer]

sowieso kan je natuurlijk net zo goed gewoon per klant een tar file maken lijkt me. Ik heb geen idee hoeveel klanten je hebt maar er zijn zat mogelijkheden om het allemaal wat flexibeleren te maken natuurlijk.

[Verwijderd]

Dat is geen optie bij webservers met 300 klanten.

In het geval van een backup per klant dien je dan 300 backup te uncompressen, indien je naar een nieuwe server migreert of een totale server restored.

Dan is het makkelijk per service een backup te maken. In ons geval:
/usr/local/psa
/var/www
/var/qmail
/var/lib/mysql
/var/named
/etc

[ Voor 6% gewijzigd door Verwijderd op 06-05-2008 22:08 ]

[berties]

Wanneer je met slechts enkele (bijvoorbeeld maandelijkse) volledige backups werkt en met dagelijkse incrementele dan heb je veel minder last van dit soort problemen. De kans dat de files die je nodig hebt in de incrementele backups zitten zijn dan vele malen groter en de tijd om deze uit te pakken is ook vele malen kleiner.
Wat een goede verhouding is tussen de incrementele en volledige backups zal je zelf moeten bepalen.
De volgende opbouw zou bijvoorbeeld een mogelijkheid zijn,
1
11
111
112
113
12
121
122
123
13
131
132
133
2
21
enz

Waarbij 1 en 2 en 3 enz volledige backups zijn en de rest incrementele backups.
Vervolgens is 11 een incr. backup van 1 en 12 van 11, 21 van 2.
Zo kun je met drie lagen er voor zorgen dat de hoeveelheid volledige backups minimaal is.

Zorg er wel voor dat je een overzicht hebt welke files waarin zitten, dat is ook makkelijker. Je kunt bijvoorbeeld naast 1.tar.gz ook een 1.files.log hebben met daarin een lijst van welke files er in zitten. Zo heb je ook snel gevonden wat waarin zit.

[Osiris]

Verwijderd schreef op dinsdag 06 mei 2008 @ 22:07:
Dat is geen optie bij webservers met 300 klanten.

In het geval van een backup per klant dien je dan 300 backup te uncompressen, indien je naar een nieuwe server migreert of een totale server restored.

Dan is het makkelijk per service een backup te maken. In ons geval:
/usr/local/psa
/var/www
/var/qmail
/var/lib/mysql
/var/named
/etc

Euhm, correct me if I'm wrong, maar de totale te (un)compressen data blijft toch hetzelfde ongeacht de manier waarop je kiest te compressen? (Klanten apart, services apart e.d.) Enige wat je wel krijgt is wat meer overhead, maar de overhead van gzip/bzip2 lijkt me te verwaarlozen als je niet voor elk 2-byte-bestandje apart gaat compressen. (Dat lijkt me sowieso onhandig.)

Dat je eventueel 300 backups moet uncompressen is natuurlijk probleemloos met een scriptje wat je binnen vijf minuten in elkaar geschreven hebt of wildcard te fixen lijkt me.

[Soultaker]

Het tar-formaat is heel simpel; gewoon een hoop bestanden aan elkaar geplakt met vóór elk bestand een header waarin de oorspronkelijke bestandsnaam staat (allerlei varianten als pax, cpio etc. zijn in principe hetzelfde). Vandaar dat je het hele bestand door moet lopen om bestanden te vinden die je nodig hebt.

Osiris schreef op dinsdag 06 mei 2008 @ 21:33:
Euhm, is dat zo? Werken gzip/bzip2 niet in blocks of iets dergelijks? Want dan zou het op normale PC's 'onmogelijk' zijn om bijvoorbeeld een DVD-tje te gzip/bzip2-en.

De meeste compressiemethoden werken wel met blocks, maar dan nog weet je niet wáár je in het bestand moet zijn, dus heeft selectief uitpakken geen zin. In bestandsformaten zoals zip zit er op een vaste plek een index met een overzicht van welke bestanden wáár staan en dan kun je dus alleen de blocks uitpakken die je nodig hebt, maar in een tar-bestand ontbreekt die index. Dát is het probleem (en niet zozeer de compressie).

Overigens maak ik zelf voor mijn backups altijd een text index erbij (de uitvoer van tar tf backup.tar dus) zodat ik snel kan opzoeken welke bestanden er in het archief zitten. Daar wordt het uitpakken niets sneller van maar je hoeft dan in ieder geval niet het hele bestand door om te zien wat er überhaupt in zit.

[Osiris]

Soultaker schreef op dinsdag 06 mei 2008 @ 22:19:
[...]

De meeste compressiemethoden werken wel met blocks, maar dan nog weet je niet wáár je in het bestand moet zijn, dus heeft selectief uitpakken geen zin. In bestandsformaten zoals zip zit er op een vaste plek een index met een overzicht van welke bestanden wáár staan en dan kun je dus alleen de blocks uitpakken die je nodig hebt, maar in een tar-bestand ontbreekt die index. Dát is het probleem (en niet zozeer de compressie).

Daar ging 't block-verhaal ook niet over, iemand beweerde dat je 30+ gig aan (virtueel) geheugen nodig had om een ditto bestand te decompressen. Terwijl dat dus niet noodzakelijk is als je met blocks werkt.

[TrailBlazer]

Verwijderd schreef op dinsdag 06 mei 2008 @ 22:07:
Dat is geen optie bij webservers met 300 klanten.

In het geval van een backup per klant dien je dan 300 backup te uncompressen, indien je naar een nieuwe server migreert of een totale server restored.

Dan is het makkelijk per service een backup te maken. In ons geval:
/usr/local/psa
/var/www
/var/qmail
/var/lib/mysql
/var/named
/etc

Ik zie hier het probleem niet om elke dag 300 nieuwe files aan te maken. Je maakt gewoon per klant een directory aan voor de backups en that's it. Hoe vaak migreer/restore je een server nou helemaal. Eerst zet je gewoon je OS en apps terug. Daarna restore je gewoon al je klanten. Je zal hier wat voor moeten scripten maar dat mag geen probleem zijn natuurlijk.

[RemcoDelft]

Verwijderd schreef op dinsdag 06 mei 2008 @ 22:07:
Dat is geen optie bij webservers met 300 klanten.

Juist bij 300 klanten!

code:

#!/bin/bash
cd /webdir
for i in `ls`
clear; echo $i' wordt nu gecomprimeerd
do tar -cvvf - $i | bzip2 -z -9 > /backupdir/$i.tar.bz2
done

En meteen de zwaarst mogelijke bzip2 compressie i.p.v gzip
Eventueel kan je "nice bzip2" doen.

[ Voor 12% gewijzigd door RemcoDelft op 06-05-2008 22:41 ]

[Confusion]

Verwijderd schreef op dinsdag 06 mei 2008 @ 22:07:
Dat is geen optie bij webservers met 300 klanten.

In het geval van een backup per klant dien je dan 300 backup te uncompressen, indien je naar een nieuwe server migreert of een totale server restored.

En het probleem daarmee is...?

[pistole]

Je kan ook iets als BackupExec enzo gebruiken...

offtopic:
sorry, moet er ff uit. NEEEE, geen bexec!!!

Inderdaad, gewoon per klant / vhost / {alle vhosts startend met een letter uit het alfabet} een aparte tarball maken. Voor het overzicht pleur je al die tarballs in een mapje met een mooie naam (20080506 voor vandaag, bijvoorbeeld)

[igmar]

Heel fijn, maar met z'n 60 GB aan websites geen oplossing meer kan ik je vertellen. Wij hebben een stuk maatwerk geschreven dat de sites apart in tar.bz2 files zet. Op die manier kan ik per site dingen terugzetten, en hoef ik geen hele 60 GB uit te pakken.

Mijn advies : Spendeer er een dag aan. Ik had het in PHP vrij vlot geschreven.

[Rainmaker]

Mijn advies zou zijn: gebruik een "echte" backup oplossing, of gebruik een ander compressieformaat. Geen 2-staps compressie (eerst tar, dan gz), maar direct compressie.

Waarom bijvoorbeeld niet "gewoon" zip?

[Confusion]

igmar schreef op woensdag 07 mei 2008 @ 09:20:
Heel fijn, maar met z'n 60 GB aan websites geen oplossing meer kan ik je vertellen.

Rainmaker schreef op woensdag 07 mei 2008 @ 09:51:
Mijn advies zou zijn: gebruik een "echte" backup oplossing, of gebruik een ander compressieformaat. Geen 2-staps compressie (eerst tar, dan gz), maar direct compressie.

Zullen we ophouden met nutteloze antwoorden te geven waarin niet staat uitgelegd waarom we iets vinden? Aan jullie allebei de vraag: waarom dan?

Waarom bijvoorbeeld niet "gewoon" zip?

Want 'gewoon' zip doet niet zowel archivering als compressie? Of weet je eigenlijk gewoon niet wat 'tar' doet?

[Soultaker]

Een aantal nadelen van het klassieke zip-formaat:

1. compressie is waarschijnlijk slechter omdat kleine bestanden afzonderlijk gecomprimeerd worden en de index niet comprimeerd wordt;
2. 4GB limiet aan bestanden (en het zipbestand zelf )
3. file modes blijven niet bewaard ()
4. ACLs blijven niet bewaard
5. extended attributes blijven niet bewaard

Er zijn overigens ook wat extensies die een aantal van deze nadelen wegwerken; WinZIP ondersteunt bijvoorbeeld een 64-bits formaat dat geen limiet op grootte heeft, maar open-source ZIP utillities ondersteunen dat dan weer niet. Dan ben je beter af met een formaat wat wel goed ondersteund wordt, óf als je toch een minder-dan-alomvertegenwoordigd formaat gebruikt kun je ook voor iets als 7-zip kiezen wat tenminste wél goed comprimeerd.

Het grote voordeel van een standaard archiver is de index waarmee je selectief bestanden kunt uitpakken. Verder is het model van een platform-specifieke archiver (die alle relevante metadata bewaart) en een losse compressor prima werkbaar.

[psyBSD]

Mischien zoek je zoiets?:

code:

gunzip -c backup.tar.gz | tar -xf - -C $DEST_DIR /home

Ok, laat maar... was al voorgesteld.

[ Voor 16% gewijzigd door psyBSD op 07-05-2008 13:23 ]