Linux commando: tar

Vrijwel iedereen die Linux gebruikt heeft weleens tar -xzf iets.tar.gz getypt zonder zeker te weten wat die letters betekenen. Dat is een prima startpunt, en het is waar de meeste mensen blijven staan. Dat gat doet ertoe, want tar is het gereedschap dat een website inpakt voor een verhuizing, dat de software uitpakt die je downloadt, en dat de backup maakt die je ooit onder druk zult moeten terugzetten.

2. Waar komt de naam vandaan?

tar is kort voor tape archive, bandarchief.

tar  =  Tape ARchive

Dat is geen voetnoot uit de geschiedenis. Het is het ene feit dat vrijwel elke ontwerpkeuze in het gereedschap verklaart, want een magneetband kun je alleen van begin tot eind lezen.

Niemand in dit publiek heeft een bandstation, en het formaat is nog steeds volledig om zo'n apparaat heen gebouwd. Dat is het weten waard, want het maakt van een lijst eigenaardigheden een reeks gevolgen.

De vlaggen zijn ook het onderwerp van de bekendste grap in Unix-documentatie: xkcd 1168, waarin iemand binnen zestig seconden uit het hoofd een tar-archief moet uitpakken of de wereld vergaat. Het is grappig omdat die letters werkelijk lastig te onthouden zijn, en de reden staat in hoofdstuk 3: ze dateren van voor de afspraken die ze logisch gemaakt zouden hebben.

4. Eenvoudige toepassingen

4.1 De drie commando's die je echt nodig hebt

Begin met een map die site heet. Deze drie commando's dekken het meeste dagelijks gebruik:

$ tar -czf site.tar.gz site/     # create, compressed with gzip
$ tar -tzf site.tar.gz           # list the contents
$ tar -xzf site.tar.gz           # extract into the current directory

Lees de letters als een zin en ze zijn niet langer willekeurig: create zipped file, table of the zipped file, extract the zipped file. De f komt altijd als laatste, omdat de archiefnaam erachter volgt.

GNU tar accepteert de vlaggen ook zonder streepje, en zo hebben de meeste mensen het geleerd. Daarom zien de vlaggen er in voorbeelden zo vreemd uit:

$ tar czf site.tar.gz site/     # identical to -czf, and much older syntax

Dit is een overblijfsel van het oorspronkelijke commando uit 1979, dat het begrip streepje niet kende. Beide vormen werken; gebruik degene die je makkelijker onthoudt.

4.2 Wat -f werkelijk doet

De vlag -f benoemt het archief. Laat hem weg en tar valt terug op zijn standaard uit 1979, en dat is standaarduitvoer, want daar zat het bandstation. Moderne GNU tar vangt de voor de hand liggende fout af:

$ tar cz site
tar: Refusing to write archive contents to terminal (missing -f option?)
tar: Error is not recoverable: exiting now

Die bescherming geldt alleen als de terminal de bestemming is. Leid het om en tar doet vrolijk wat je vroeg, wat af en toe precies is wat je wilt:

$ tar cz site > site.tar.gz     # works, and is exactly what -f does
$ tar cf - site | ssh backup-server 'cat > site.tar'

Het enkele streepje in -f - betekent "gebruik standaarduitvoer", en het is de basis van elke pipe in paragraaf 6.4.

Nog een foutmelding is het herkennen waard, want de formulering helpt de eerste keer niet:

$ tar cf
tar: Old option 'f' requires an argument.

Dat betekent dat je -f schreef en vergat te zeggen welk bestand.

4.3 Compressie toevoegen

Een letter kiest de compressor. tar comprimeert zelf niets; hij draait het externe programma en stuurt de stroom erdoorheen.

Let op dat -j en -J alleen in hoofdlettergebruik verschillen, en dat het verschillende compressors zijn. Dat is een echte bron van verwarring, en daarom zijn de lange vormen in scripts de moeite waard.

Je kunt tar het ook uit de bestandsnaam laten afleiden met -a (kort voor auto-compress):

$ tar caf backup.tar.xz site/    # picks xz because of the extension
$ tar caf backup.tar.zst site/   # picks zstd

$ file backup.tar.xz
backup.tar.xz: XZ compressed data, checksum CRC64

Voor uitpakken is dit allemaal niet nodig. Moderne GNU tar herkent de compressie aan het bestand zelf, dus tar xf kan met elk formaat hierboven overweg:

$ tar xf anything.tar.gz     # works
$ tar xf anything.tar.xz     # also works, no -J needed

De gewoonte om xzf te typen is onschuldig, maar hij is niet nodig, en hij laat je in de steek op de dag dat iemand je een .tar.bz2 geeft.

De losse letters geven je elke compressor op zijn standaardinstellingen en verder niets. Wil je een ander niveau, of een compressor waar tar geen letter voor heeft, dan neemt -I (lange vorm --use-compress-program) een compleet commando:

$ tar -I 'zstd -19' -cf archive.tar.zst dir/    # maximum zstd compression
$ tar -I 'gzip -1'  -cf archive.tar.gz  dir/    # fastest gzip, for a big local copy
$ tar -I pigz       -cf archive.tar.gz  dir/    # parallel gzip, if installed

De aanhalingstekens doen ertoe zodra het commando argumenten heeft. Dit is ook de eerlijke versie van wat -z altijd al deed: tar heeft altijd een ander programma gedraaid en de stroom erdoorheen gestuurd.

4.4 De lijst lezen

Voeg -v toe (kort voor verbose) aan -t en je krijgt een lijst die op ls -l lijkt, met een belangrijk verschil:

$ tar -tvzf site.tar.gz
drwxrwxr-x peter/peter       0 2026-08-23 16:20 site/
drwxrwxr-x peter/peter       0 2026-08-23 16:20 site/logs/
-rw-rw-r-- peter/peter       9 2026-08-23 16:20 site/logs/error.log
-rw-rw-r-- peter/peter      14 2026-08-23 16:20 site/index.php
hrw-rw-r-- peter/peter       0 2026-08-23 16:20 site/hardlink.php link to site/index.php
drwxrwxr-x peter/peter       0 2026-08-23 16:20 site/images/
-rw-rw-r-- peter/peter  200000 2026-08-23 16:20 site/images/data.txt

De eigenaarskolom is gebruiker/groep in plaats van twee losse kolommen, en die namen staan in het archief. Ze zijn wat de bestanden waren op de machine die het archief maakte, niet wat ze op de jouwe zullen worden. Paragraaf 6.1 gaat over wat er bij het uitpakken werkelijk gebeurt.

Kijk naar de vijfde regel. Het typeteken is h, de grootte is 0, en de regel zegt link to site/index.php. tar merkte dat twee namen naar hetzelfde bestand wezen en sloeg de inhoud maar een keer op. Dit is een van de redenen dat een tar-archief van een echt systeem vaak kleiner is dan je verwacht, en een van de redenen dat het een systeem getrouw terugzet.

6. Gevorderde toepassingen

6.1 Permissies, eigendom en de umask

"Waarom veranderden de permissies toen ik dit uitpakte?" is een van de meest gestelde tar-vragen, en het antwoord is een regel die vrijwel niemand verteld wordt.

Als je uitpakt als gewone gebruiker, past tar je umask toe. Hier zijn twee bestanden, waarvan een bewust voor iedereen schrijfbaar is:

$ ls -l perm/
-rw-rw-rw- open.txt
-rw------- secret.txt

$ ( umask 077; tar xf perm.tar -C pout1 )
$ ls -l pout1/
-rw------- open.txt          <-- was 666, now 600
-rw------- secret.txt

Het archief bewaarde 666 getrouw. De umask haalde de bits voor groep en anderen er onderweg naar buiten af. Voeg -p toe (kort voor preserve permissions) en de vastgelegde modus wint:

$ ( umask 077; tar xpf perm.tar -C pout2 )
$ ls -l pout2/
-rw-rw-rw- open.txt          <-- preserved
-rw------- secret.txt

Het naslagwerk legt de andere helft van de regel vast: -p en --same-owner zijn de standaard voor de superuser. Hetzelfde commando levert dus een ander resultaat op afhankelijk van wie het draait, en precies daarom gedraagt een restore met sudo zich anders dan een restore in je eigen account.

Met eigendom werkt het net zo. Het archief bewaart namen en nummers:

$ tar -tvf perm.tar
-rw------- peter/peter  0 2026-08-23 16:24 ./secret.txt

$ tar -tvf perm.tar --numeric-owner
-rw------- 1000/1000    0 2026-08-23 16:24 ./secret.txt

Als gewone gebruiker kun je een bestand niet weggeven, dus alles wat je uitpakt is van jou, wat het archief ook zegt. Als root zet tar de vastgelegde eigenaar terug, en hij zoekt eerst op naam. Dat is meestal goed, en af en toe heel verkeerd: als www-data UID 33 is op de oude server en UID 82 op de nieuwe, dan is zoeken op naam precies wat je wilt. Bestaan de accounts helemaal niet op het doel, gebruik dan --numeric-owner zodat de nummers letterlijk teruggezet worden.

Een archief legt permissies en eigendom vast; het dwingt ze niet af. Wat je bij het uitpakken werkelijk krijgt hangt af van wie tar draait en wat zijn umask is.

Voor het verhuizen van een website tussen servers is dit het verschil tussen een werkende restore en een middag chown:

$ sudo tar -xzpf site.tar.gz -C /var/www --numeric-owner

Naast de klassieke Unix-bits is er een tweede laag metagegevens waar een volledige systeembackup van kan afhangen, en tar heeft voor elk onderdeel een schakelaar:

$ tar --help | grep -E 'acls|xattrs|selinux'
      --acls                 Enable the POSIX ACLs support
      --no-acls              Disable the POSIX ACLs support
      --no-selinux           Disable the SELinux context support
      --no-xattrs            Disable extended attributes support

Of deze standaard aan staan hangt af van hoe jouw tar gebouwd is en van het bestandssysteem eronder, en daarom noemt de helptekst zowel de in- als de uitschakelende vorm. Voor een gewone website die niets in uitgebreide attributen bewaart maakt het niets uit. Voor een systeembackup wel, en de enige manier om het te weten is archiveren, terugzetten in een testmap, en vergelijken. Neem hier niets aan.

6.2 Symbolische links, en de vlag die je backup verdubbelt

Standaard bewaart tar een symbolische link als symbolische link. Hij legt vast waar de link naartoe wijst en verder niets, en dat is bijna altijd wat je wilt:

$ ls -l
current -> releases/2026-08

$ tar cf sym.tar current releases
$ tar tvf sym.tar
lrwxrwxrwx peter/peter  0 2026-08-23 16:32 current -> releases/2026-08
drwxrwxr-x peter/peter  0 2026-08-23 16:32 releases/
drwxrwxr-x peter/peter  0 2026-08-23 16:32 releases/2026-08/
-rw-rw-r-- peter/peter  8 2026-08-23 16:32 releases/2026-08/index.php

Dat is de standaardindeling bij uitrollen: een symlink current die naar een gedateerde releasemap wijst. Het archief houdt de opzet intact, en terugzetten geeft je dezelfde structuur terug.

-h (lange vorm --dereference) verandert dit. tar volgt elke link en archiveert wat er aan de andere kant staat:

$ tar chf symh.tar current releases
$ tar tvf symh.tar
drwxrwxr-x peter/peter  0 2026-08-23 16:32 current/
-rw-rw-r-- peter/peter  8 2026-08-23 16:32 current/index.php
drwxrwxr-x peter/peter  0 2026-08-23 16:32 releases/
drwxrwxr-x peter/peter  0 2026-08-23 16:32 releases/2026-08/
hrw-rw-r-- peter/peter  0 2026-08-23 16:32 releases/2026-08/index.php link to current/index.php

current is nu een echte map met een echte kopie. In dit kleine voorbeeld was tar slim genoeg om de verdubbeling op te merken en de tweede kopie als harde link op te slaan, maar dat werkt alleen omdat beide uiteinden in hetzelfde archief zaten.

Het gevaar zit in het geval waarin dat niet zo is. Een symlink die buiten de map wijst die je archiveert wordt een volledige kopie van waar hij naar wijst:

$ ls -l /var/www/site/uploads
uploads -> /mnt/storage/media        # 40 GB of images on another volume

$ tar chzf site.tar.gz /var/www/site  # -h: now archiving 40 GB, not 200 MB

Dit is een echt veelvoorkomende manier waarop een backup 's nachts groeit zonder zichtbare reden. Gebruik -h bewust, wanneer het archief op zichzelf moet staan en de lezer de linkdoelen niet heeft, en laat hem er de rest van de tijd af.

6.3 Sparse bestanden

Een sparse bestand heeft een grote logische omvang maar gebruikt niet zoveel schijf, omdat het bestandssysteem de lege gebieden als gaten vastlegt in plaats van nullen op te slaan. Schijfimages van virtuele machines en sommige databasebestanden zijn de gebruikelijke voorbeelden:

$ truncate -s 100M sparse.img
$ du -h --apparent-size sparse.img
100M
$ du -h sparse.img
0

Honderd megabyte aan bestand, nul bytes op schijf. tar weet niets van de gaten tenzij je het hem vertelt, en het verschil is niet subtiel:

$ tar cf plain.tar sparse.img
$ ls -l plain.tar
104867840

$ tar cSf sparse.tar sparse.img       # -S, --sparse
$ ls -l sparse.tar
10240

Zonder -S leest tar de gaten als de nullen die het bestandssysteem meldt en schrijft hij ze allemaal in het archief: 104 megabyte. Met -S legt hij de gaten als gaten vast en is het archief tien kilobyte, een factor tienduizend.

Het kost dat -S tar elk bestand op gaten laat onderzoeken, en dat is verspilde moeite op een map met gewone webbestanden. Zet hem aan als het archief schijfimages of databasebestanden bevat, en laat hem er anders af. Compressie verbergt een deel hiervan (een reeks nullen comprimeert goed) maar niet de tijd die het lezen en schrijven ervan kost.

6.4 tar als pipe

Omdat tar stromen leest en schrijft, laat hij zich combineren. -f - betekent standaardinvoer of -uitvoer, en die ene afspraak geeft je drie echt nuttige commando's.

Kopieer een mappenboom en behoud alles:

$ tar cf - source/ | tar xf - -C /destination

Twee keer tar, een pipe, geen tijdelijk bestand. Anders dan cp -r behoudt dit harde links, sparse bestanden en permissies precies, omdat beide uiteinden hetzelfde formaat spreken.

Verplaats een boom naar een andere machine, zonder hem ergens op te slaan:

$ tar czf - /var/www/site | ssh user@newserver 'tar xzf - -C /var/www'

Dit is het goed begrijpen waard, want het lost een echt probleem op: je hebt aan geen van beide kanten schijfruimte nodig voor een tussenliggend archief. De compressie gebeurt op de verzendende machine, dus het bespaart ook bandbreedte. Voor een eenmalige verhuizing van een website is het vaak sneller en eenvoudiger dan rsync, dat pas het betere gereedschap is als je de overdracht gaat herhalen.

Kijk in een archief zonder het uit te pakken:

$ tar xzf backup.tar.gz -O var/www/site/configuration.php | grep password

Alle drie volgen uit dezelfde beslissing uit 1979 dat de standaarduitvoer een apparaat is en geen bestand.

6.5 Formaten, en de muur van 100 tekens

De oorspronkelijke header uit 1979 reserveerde precies 100 bytes voor de bestandsnaam. Dat was royaal voor een systeem met korte paden, en het werd een probleem zodra mappen dieper werden. Er bestaan nu drie formaten, en GNU tar schrijft standaard het derde:

De grens is niet theoretisch. Een bestandsnaam van 124 tekens wordt door ustar ronduit geweigerd:

$ tar cf u.tar --format=ustar aaaa...124-characters...txt
tar: aaaa...: file name is too long (cannot be split); not dumped
tar: Exiting with failure status due to previous errors
$ echo $?
2

$ tar cf g.tar aaaa...124-characters...txt     # gnu, the default
$ echo $?
0

In de praktijk zul je nooit ustar kiezen. De keuze die de moeite waard is, is pax voor alles wat je jaren wilt bewaren, want dat is de echte standaard en het bewaart tijdstempels op volledige precisie in plaats van afgerond op de seconde.

$ tar --format=pax -czf archive.tar.gz site/

6.6 Toevoegen, en waarom nooit aan een .tar.gz

Omdat een archief een stroom met een eindmarkering is, kun je eraan toevoegen door die markering te overschrijven. -r (kort voor append) doet dat:

$ tar cf plain.tar site/index.php
$ tar rf plain.tar site/logs/error.log
$ tar tf plain.tar
site/index.php
site/logs/error.log

-u (kort voor update) doet hetzelfde maar voegt alleen bestanden toe die nieuwer zijn dan de kopie die al in het archief zit. Geen van beide haalt iets weg: een "bijgewerkt" bestand wordt toegevoegd, en de oude versie blijft staan. Herhaald bijwerken maakt een archief dat eeuwig groeit en meerdere versies van hetzelfde pad bevat, waarbij tar de laatste uitpakt die hij tegenkomt.

Op een gecomprimeerd archief werkt hier niets van:

$ tar rf site.tar.gz site/logs
tar: Cannot update compressed archives
tar: Error is not recoverable: exiting now
$ echo $?
2

De reden is structureel. gzip levert een doorlopende stroom op, dus er is geen manier om de eindmarkering te vinden zonder alles uit te pakken, en geen manier om er voorbij te schrijven zonder opnieuw te comprimeren. Moet je aan een gecomprimeerd archief toevoegen, dan pak je uit, voegt toe, en comprimeert opnieuw. In de praktijk maak je een nieuw archief.

Verwijderen kan ook niet. tar kan nooit een lid uit een archief halen, op band noch op schijf, om dezelfde reden.

6.7 Incrementele backups

GNU tar kan een volledige backup maken en daarna alleen archiveren wat veranderd is. De toestand staat in een snapshotbestand dat je met -g meegeeft:

$ tar czf full.tgz -g snapshot.snar data
$ tar tzf full.tgz
data/
data/one.txt

$ touch data/two.txt

$ tar czf incr.tgz -g snapshot.snar data
$ tar tzf incr.tgz
data/
data/two.txt

Het tweede archief bevat alleen het nieuwe bestand. Het snapshotbestand is wat het laat werken, en het is ook de zwakke plek: raak je het kwijt, dan heeft tar geen idee meer wat hij al geback-upt heeft, dus de volgende run wordt stilletjes weer een volledige backup. Bewaar het naast de archieven.

Terugzetten betekent het volledige archief uitpakken en daarna elke aanvulling op volgorde, en dat is precies zo kwetsbaar als het klinkt. Incrementele tar is het kennen waard; voor iets belangrijks doet gereedschap dat zijn eigen geschiedenis bijhoudt, zoals restic of borg, minder pijn.

6.8 Reproduceerbare archieven

Pak dezelfde bestanden twee keer in en je krijgt twee verschillende archieven. Aan de inhoud veranderde niets; aan de metagegevens wel:

$ tar cf r1.tar d ; touch d/a.txt ; tar cf r2.tar d
$ sha256sum r1.tar r2.tar
4871b10e9a0df295ddd3da758d774ca9527b2381cb16ced15149230f9d0fe40f  r1.tar
c3e4021cbbf022087435c0c98e52fc37adebcbb1ca17537c0d714af92e404c25  r2.tar

Tijdstempels, eigendom en de volgorde waarin het bestandssysteem de mapregels teruggaf komen allemaal in het archief terecht. Zet ze allemaal vast en het resultaat wordt deterministisch:

$ tar --sort=name --mtime='UTC 2026-01-01' --owner=0 --group=0 --numeric-owner -cf p1.tar d
$ touch d/a.txt d/b.txt
$ tar --sort=name --mtime='UTC 2026-01-01' --owner=0 --group=0 --numeric-owner -cf p2.tar d
$ cmp p1.tar p2.tar && echo IDENTICAL
IDENTICAL

De tijdstempels zijn tussen de twee runs bewust veranderd en de archieven zijn nog steeds byte voor byte gelijk. Dat maakt van "is er sinds de vorige release eigenlijk iets veranderd?" een vergelijking van controlegetallen in plaats van een discussie.

Twee details over --mtime. Schrijf UTC voor de datum, anders volgt het stempel de tijdzone van de machine die het archief bouwde en zijn twee identieke builds in verschillende landen het oneens. En houd de aanhalingstekens: omdat de waarde een spatie bevat, splitst de shell deze vlaggen als je ze in een variabele zonder aanhalingstekens zet, en meldt tar 2026-01-01: Cannot stat: No such file or directory. Moet het in een variabele, gebruik dan --mtime=@0, want daar zit geen spatie in.

Nog een detail is het weten waard, want het is het omgekeerde van wat mensen verwachten: tar czf is reproduceerbaar, maar tar cf gevolgd door gzip niet. gzip legt de oorspronkelijke bestandsnaam en wijzigingstijd in zijn header vast, en als hij uit een pipe leest is er geen van beide om vast te leggen:

$ hexdump -C reproducible.tar.gz | head -1
1f 8b 08 00 00 00 00 00  00 03 ...        <-- flags 00, timestamp all zeros

$ gzip -k plain.tar ; hexdump -C plain.tar.gz | head -1
1f 8b 08 08 a3 07 8b 6a  00 03 74 2e 74 61 72 00   |.......j..t.tar.|
                                                    <-- flag 08, a timestamp,
                                                        and the filename

Een bestand op schijf comprimeren bewaart de naam en de tijd; een stroom comprimeren kan dat niet. Bouw je het archief toch in twee stappen, gebruik dan gzip -n om beide weg te laten.

6.9 Controleren of het archief goed is

tar heeft drie afsluitcodes, en het is de moeite waard om er in een script op te testen:

-d (kort voor diff, ook --compare) controleert een archief tegen het bestandssysteem:

$ tar df cmp.tar
site/index.php: Mod time differs
site/index.php: Size differs
$ echo $?
1

Direct na het maken van een archief gedraaid bewijst dit dat het archief overeenkomt met wat er op schijf staat. Het vervangt geen echte restoretest, maar het kost een commando.

--totals toont wat er geschreven is, en dat is een goedkope controle in een backupscript:

$ tar cf /dev/null --totals site
Total bytes written: 10240 (10KiB, 89MiB/s)

De waarde van dat getal is niet het getal zelf maar de stabiliteit ervan. Een nachtelijke backup die maandenlang ongeveer evenveel schrijft en ineens een tiende daarvan schrijft, vertelt je iets, en het is de enige waarschuwing die je gaat krijgen.

Geen van beide vertelt je of het archief een maand later nog intact is op de schijf waar je het naartoe kopieerde. Schrijf daarvoor een controlegetal ernaast op het moment dat je het maakt:

$ sha256sum backup.tar.gz > backup.tar.gz.sha256

# before you rely on it, wherever it has ended up
$ sha256sum -c backup.tar.gz.sha256
backup.tar.gz: OK

Een controlegetal beantwoordt precies een enkele vraag: zijn dit dezelfde bytes die geschreven zijn? Het zegt niets over de vraag of de juiste bestanden erin zijn gegaan. De drie controles stapelen, de goedkoopste eerst: tar tf archief > /dev/null bewijst dat de structuur leesbaar is, het controlegetal bewijst dat de bytes het overleefd hebben, en echt uitpakken in een testmap bewijst dat de backup een backup is. Alleen de laatste is bewijs.

8. Best practices

• Toon voordat je uitpakt. tar tzf archief.tar.gz | head kost een seconde en vertelt je of het archief een map op het hoogste niveau heeft, waar de bestanden terechtkomen, en of het is wat je denkt.
• Of gebruik gewoon --one-top-level. Onvoorwaardelijk. Het is ongevaarlijk bij nette archieven en het maakt tarbommen onmogelijk.
• Zet --exclude voor de paden. Deze opties zijn positioneel. Moderne tar waarschuwt en stopt met code 2, maar alleen als iemand de uitvoer leest.
• Gebruik -C in plaats van cd. Het werkt bij zowel maken als uitpakken, het is expliciet, en het voorkomt dat een backupscript afhangt van de map waarin het gestart werd.
• Vecht niet tegen de melding over de voorste schuine streep. Absolute paden worden voor je veiligheid weggehaald. Maak het archief met -C /var/www site in plaats van het volledige pad te noemen.
• Zet terug als root met -p en denk aan --numeric-owner. Permissies en eigendom overleven alleen als degene die uitpakt het recht heeft ze te zetten, en accountnummers komen tussen servers zelden overeen.
• Weet wat -h gaat meenemen. Symlinks worden standaard als links bewaard, en dat is vrijwel altijd goed. -h volgt ze, en een enkele link naar een ander volume kan de omvang van een backup vermenigvuldigen.
• Voeg -S toe als het archief schijfimages of databasebestanden bevat. Zonder die vlag wordt een sparse bestand van 100 MB 100 MB aan nullen in het archief in plaats van tien kilobyte.
• Zet de metagegevens vast voor alles wat je uitbrengt. --sort=name --mtime='UTC ...' --owner=0 --group=0 --numeric-owner maakt het archief byte voor byte gelijk tussen builds, zodat een controlegetal de vraag "is er iets veranderd?" beantwoordt.
• Schrijf een controlegetal naast het archief als je het maakt. sha256sum backup.tar.gz > backup.tar.gz.sha256 is de enige manier om later te weten dat de bytes de kopieerslag overleefd hebben.
• Pak alles wat je niet zelf maakte uit in een nieuwe lege map, als jezelf. Moderne tar blokkeert de ontsnappingstrucs met paden, maar niets houdt een archief tegen om te overschrijven wat er al in de map staat die jij koos.
• Voeg nooit toe aan een gecomprimeerd archief. Het kan niet werken. Maak een nieuw archief.
• Kies de compressor bewust. gzip als iemand anders het moet kunnen openen, xz als het vaak gedownload wordt, zstd als het elke nacht draait en jij de enige afnemer bent.
• Controleer de afsluitcode in scripts. 0 is goed, 1 betekent dat er iets onder je handen veranderde, 2 betekent dat het archief onvolledig kan zijn. Een backupscript dat dit negeert meldt in beide gevallen succes.
• Dump de database apart. tar over een draaiende databasemap levert een bestand op dat op een backup lijkt en het niet is.
• Test de restore, niet het archief. tar df en --totals zijn goedkope controles; geen van beide bewijst dat je de site opnieuw kunt opbouwen. Alleen ergens uitpakken en kijken doet dat.

$ man 1 tar               # the full manual, options grouped by mode
$ tar --help              # a much shorter summary
$ tar --show-defaults     # what your build assumes when you say nothing
$ info tar                # the GNU manual, far more detailed than the man page

10. Samenvatting

tar is een programma dat gebouwd is voor hardware die al decennia niemand meer gebruikt, en het is nog steeds het juiste antwoord op "zet deze map in een bestand" op elk Unix-systeem ter wereld.

• tar betekent tape archive. Vrijwel elke eigenaardigheid volgt uit het feit dat een band een stroom is die je alleen van begin tot eind kunt lezen.
• Hij plakt aan elkaar; hij comprimeert niet. -z, -j, -J en --zstd sturen het resultaat door een apart programma, en daarom bestaat de extensie uit twee delen.
• Drie modi, waarvan er altijd precies een geldt: -c maken, -t tonen, -x uitpakken. -f benoemt het archief, en zonder die vlag schrijft tar naar standaarduitvoer.
• Uitpakken heeft geen compressievlag meer nodig. tar xf zoekt het formaat zelf uit.
• Op echte gegevens gaf xz de beste grootte en gzip de beste uitwisselbaarheid, terwijl zstd in beide richtingen het snelst was. bzip2 werd op elk punt verslagen.
• -C kiest de map bij zowel maken als uitpakken; --strip-components haalt de map met het versienummer weg die broncodereleases gebruiken.
• --exclude is positioneel en moet voor de paden staan, anders doet het stilzwijgend niets en stopt tar met code 2.
• Absolute paden worden met opzet weggehaald, zodat uitpakken altijd gebeurt waar jij bent.
• Permissies worden vastgelegd maar door je umask gefilterd, tenzij je -p meegeeft, en dat is alleen voor root de standaard. Eigendom wordt op naam gezocht.
• Symlinks worden als links bewaard; -h volgt ze wel, en dat kan de omvang van een backup stilletjes vermenigvuldigen.
• -S gaat om met sparse bestanden. Zonder die vlag schrijft een image van 100 MB waar niets in staat 100 MB aan nullen.
• Archieven zijn niet vanzelf reproduceerbaar, maar vijf vlaggen maken ze byte voor byte gelijk tussen builds.
• Moderne GNU tar blokkeert de klassieke uitpakaanvallen al. Wat hij niet blokkeert is overschrijven van wat er al in de map staat die jij koos.
• tar laat zich als pipe combineren: twee keer tar kopieert een boom, en een keer over ssh verhuist een site zonder ergens een tijdelijk bestand.
• Een .tar.gz is een solide archief: kleiner dan een zip, maar zonder index, dus een bestand eruit halen kost evenveel als alles uitpakken.
• Kijk voordat je uitpakt, of geef --one-top-level mee, en een tarbom kan je nooit meer verrassen.

Dit is het spiekbriefje dat je wilt bewaren:

tar czf out.tar.gz dir/        create, gzip
tar caf out.tar.xz dir/        create, compressor chosen by extension
tar tzf out.tar.gz             list (ALWAYS do this before extracting)
tar tvzf out.tar.gz            list with sizes, owners and modes
tar xf out.tar.gz              extract (format detected automatically)
tar xf out.tar.gz -C /target   extract somewhere else
tar xf out.tar.gz --one-top-level    never be tarbombed again

-c create   -t list   -x extract   -f FILE   -v verbose
-h follow symlinks (CHECK first)   -S sparse files (disk images)
-z gzip     -j bzip2  -J xz        --zstd    -a by extension
-C DIR      change directory (create AND extract)
-p          keep permissions exactly (default only for root)

--strip-components=1           drop the wrapper directory
--exclude='*.log'              BEFORE the paths, or it does nothing
--exclude-vcs                  drop .git, .svn and friends
--numeric-owner                restore UIDs, not names, across servers
--one-top-level                unpack into a directory named after the archive
--format=pax                   the standard format, for long-term archives
--exclude-from=list.txt        patterns from a file, kept in version control
-I 'zstd -19'                  any compressor, with its own options
-g snapshot.snar               incremental backup state

--sort=name --mtime='UTC 2026-01-01' --owner=0 --group=0 --numeric-owner
                               byte-identical archives between builds

tar cf - src | tar xf - -C dst          copy a tree, keeping hard links
tar czf - dir | ssh host 'tar xzf -'    move a site, no temp file
tar xzf a.tgz -O path/to/file           read one file out, without unpacking
tar df archive.tar                      compare archive against disk
tar tf archive.tar >/dev/null           cheap "is it corrupt" check
sha256sum a.tgz > a.tgz.sha256          prove the bytes survive the copy
tar tvf unknown.tgz | less              ALWAYS, before unpacking a stranger's

exit 0 ok | 1 files differ or changed while reading | 2 fatal

Backups en verhuizingen zijn de twee klussen waarbij tar stilletjes het meeste werk doet, en allebei zijn ze niet beter dan de restore die niemand getest heeft. Wil je dat de archieven die je server maakt archieven zijn waarmee je echt een website kunt herbouwen, dan is dat precies het soort rustige werk waar ik graag bij help.