Ungereimtheiten mit tar -u

[KBDCALLS]

Erstelle ich ein kleines Archiv und kopiere ich eine x beliebige Datei oder Verzeichnis in das Ursprungsverzeichnis hinein , dann landen nur die hinzugekommen Dateien im Archiv

• Code: Alles auswählen

  tar -cvf test.tar  PDF  

und das Update

• Code: Alles auswählen

  tar -uvf test.tar  PDF  

funktioniert so wie gedacht.

aber das hier dann nicht mehr.

• Code: Alles auswählen

  tar  -uvf busterhome.tar /mnt/buster/home 

das ganze landet dann nochmals im Archiv. So ist die Update Funktion nicht zu gebrauchen , wenns nur bei kleineren Archiven funktioniert. Oder stört sich Tar an /mnt. Den Fehlerkanal in eine Datei schreiben lassen. hat auch nichts erhellendes gebracht. Außer das ihm die Sockets nicht gepasst haben

[GregorS]

Ich habe schon ein Problem damit, zu verstehen, was Du meinst. Was heißt „Archiv erstellen“ und was meinst Du mit „Ursprungsverzeichnis“? Ist „PDF“ in den Beispielen eine Datei oder das Verzeichnis, das einem ungefragt ins home-Verzeichnis gerotzt wird?
Ich würde Dein Szenario gerne nachstellen können aber dafür müsstest Du's genauer beschreiben.

[KBDCALLS]

Das war jetzt eigentlich kein Hexenwerk. PDF war ein Verzeichnis mit gemeint welches ich extra angelegt hatte und einige Dateien hineinkopiert. Nach dem ersten Durchlauf hab ich dann noch ein paar dazukopiert und tar dann mit der Optionion -u noch mal laufen lassen. Geb ja zu habs der einfachheithalber PDF genannt , hutzliputz wäre vieleicht besser gewesen.

[HumiNi]

Das war jetzt eigentlich kein Hexenwerk.

Verwirrend sind immerhin die beiden unterschiedlichen Archivnamen.

[KBDCALLS]

Das sind ja auch zwei paar Stiefel . Das erste sollte nur als Test dienen, wärend letzteres ein Backup sein sollte. Und da das nicht so funktionierte wie gedacht der Test mit dem extra angelegten Verzeichnis und wenigen Dateien.

[Meillo]

Mal ein paar Gedanken von mir:

Ich wuerde vermuten, dass das Problem vielleicht daran liegt, was als ``neuer'' interpretiert wird.

Hast du dieses Homeverzeichnis read-only gemountet und zweimal hintereinander den Befehl ausgefuehrt?

Kannst du das gleiche Verhalten bei anderen grossen Verzeichnissen reproduzieren? Es waere interessant, herauszufinden, wo zwischen der einen Datei und dem ganzen Homeverzeichnis das Problem beginnt.

So wirklich gut kenne ich mich mit tar nicht aus und mit dem Update-Mechanismus noch weniger, aber hast du die Beschreibung genau gelesen:

-u, --update
only append files newer than copy in archive

Das Wort ``append'' bedeutet, dass die neueren Dateien nicht ersetzt werden, sondern dass sie zusaetzlich hinten angefuegt werden. Dazu muss man tar als ``Tape Archiver'' sehen, wo am Band nur sequenziell hinten weitergeschrieben wird. Vielleicht ist tar gar nicht das passende Tool fuer deinen Anwendungszweck.

[HumiNi]

Du gibst als "Datei" ein Verzeichnis (/mnt/buster/home) an. Hatte dieses denn einen neueren Zeitstempel als das im Verzeichnis vorhandene?

[KBDCALLS]

Prinzipiel ist doch Tar für Full-Backups gedacht, und sollte sich doch von ein paar Gbyte nicht ins straucheln bringen lassen.

[heisenberg]

Ich finde es schon schwierig handhabbar bzw. ineffizient, wenn in einem Archiv mehrere Versionen einer Datei rein kommen. Das ist ja wirklich noch ein Relikt aus Zeiten der Bandlaufwerke.

Da würde ich doch für jedes Backup lieber eine eigene Datei erstellen. Und lieber cpio als tar (u. a. wegen des möglichen Checksummenformates). Dann habe ich Zugriff auf alle Versionen.

[KBDCALLS]

Du gibst als "Datei" ein Verzeichnis (/mnt/buster/home) an. Hatte dieses denn einen neueren Zeitstempel als das im Verzeichnis vorhandene?

Da kann sich eigentlich nix ändern, da das Verzeichnis nur gemountet wird und beide durchläufe direkt hinteinander gemacht werden . Auch wenn ich read only mounte passiert das selbige . Vermute da läuft irgendein Puffer über. Warum auch immer.

[KBDCALLS]

Ich finde es schon schwierig handhabbar bzw. ineffizient, wenn in einem Archiv mehrere Versionen einer Datei rein kommen. Das ist ja wirklich noch ein Relikt aus Zeiten der Bandlaufwerke.

Da würde ich doch für jedes Backup lieber eine eigene Datei erstellen. Und lieber cpio als tar (u. a. wegen des möglichen Checksummenformates). Dann habe ich Zugriff auf alle Versionen.

Anscheinend ist Tar von der schieren Anzahl der Dateien überfordert. Das wäre aber auch für ein Bandlaufwerk suboptimal.

[heisenberg]

und das Update funktioniert so wie gedacht. ... aber das hier dann nicht mehr: ... /mnt/...home

Was meinst Du damit "funktioniert nicht mehr?"

[KBDCALLS]

Mit ein handvoll Dateien in einem Verzeichnis funktioniert das Update , es werden nur die neu hinzugekommen Datein gesichert. Soll ein komplettes Home oder gar das gesamte System gesichert werden dann nicht mehr. Im ersten Durchlauf wird gesamten Home gesichert , im Update Lauf wird nochmal alles hinten drangehängt ans Archiv. Obwohl sich nichts geändert hat, selbst wenns ro gemountet ist.

[heisenberg]

Ich habe das jetzt mal ausprobiert. Funktioniert bei mir einwandfrei. Ich habe mal ein paar Excludes eingefügt, dass das nicht all zu lange dauert:

Code: Alles auswählen

$ tar -cvf /backup/tmp/backuptest-1.tar --exclude=./nc --exclude=./.thunderbird \
    --exclude=./.cache --exclude=./.local --exclude=./.config --exclude=./.mozilla \
    --exclude=./thunderbird --exclude=./.kde --exclude=./.wine --exclude=./ownCloud --exclude=./typo3 .

$ tar -tvf /backup/tmp/backuptest-1.tar | wc -l
58424

$ touch bla
$ tar -uvf /backup/tmp/backuptest-1.tar --exclude=./nc --exclude=./.thunderbird \
    --exclude=./.cache --exclude=./.local --exclude=./.config --exclude=./.mozilla \
    --exclude=./thunderbird --exclude=./.kde --exclude=./.wine --exclude=./ownCloud --exclude=./typo3 .
./bla

$ touch .bashrc
$ tar -uvf /backup/tmp/backuptest-1.tar --exclude=./nc --exclude=./.thunderbird \
    --exclude=./.cache --exclude=./.local --exclude=./.config --exclude=./.mozilla \
    --exclude=./thunderbird --exclude=./.kde --exclude=./.wine --exclude=./ownCloud --exclude=./typo3 .
./.bashrc

$ tar -tvf /backup/tmp/backuptest-1.tar | wc -l
58426

Nachtrag:

Ich habe jetzt die Excludes weg gelassen. Geht immer noch einwandfrei. Jetzt kommen ein paar geänderte Dateien vom Firefox-Cache dazu:

Code: Alles auswählen

$ tar -uvf /backup/tmp/backuptest-1.tar .
... (ganz viele Zeilen) ...

$ tar -tvf /backup/tmp/backuptest-1.tar | wc -l 
313831

$ tar -uvf /backup/tmp/backuptest-1.tar . | wc -l
275

[Meillo]

Was sagt denn:

Code: Alles auswählen

tar --version

Wie ist /mnt gemountet?

Code: Alles auswählen

mount | grep /mnt

... nicht dass das am Ende dann irgendwelche NFS-Eigenheiten oder so sind.

Kannst du das Verhalten auch mit einem grossen nicht gemounteten Verzeichnis reproduzieren?

Letztlich muss man in so Faellen halt alle moeglichen Kombinationen durchprobieren, um rauszufinden, was einen Einfluss haben koennte.

Wie ist es also wenn du z.B. nur /mnt/buster/home/KBDCALLS/Downloads oder so ins Archiv steckst: tritt das Problem dann auch auf?

Usw ...

[chrbr]

Interessant ist doch der Fall, daß man eine nicht geänderte Datei nochmals an tar mit der Option -u übergibt. Beispiel mit einer Datei, die hier "rumliegt":

Code: Alles auswählen

[I] chris@thinkpad ~> tar -cvf backup.tar left_ptr
a left_ptr
[I] chris@thinkpad ~> tar -tvf backup.tar left_ptr
-rw-r--r--  0 chris  chris   20736  7 Feb. 23:59 left_ptr
[I] chris@thinkpad ~> tar -uvf backup.tar left_ptr
a left_ptr
[I] chris@thinkpad ~> tar -tvf backup.tar left_ptr
-rw-r--r--  0 chris  chris   20736  7 Feb. 23:59 left_ptr
-rw-r--r--  0 chris  chris   20736  7 Feb. 23:59 left_ptr

Die Datei left_ptr wird also angehängt, obwohl sie nicht geändert worden ist. Ich bin gerade allerdings unter FreeBSD und ZFS unterwegs.

Interessant ist die GNU Dokumentation https://www.gnu.org/software/tar/manual ... -to-update.

Code: Alles auswählen

Unfortunately, you cannot use ‘--update’ with magnetic tape drives. The operation will fail.

Vorraussetzung von Update ist ja, daß der Zeitstempel der Dateiänderung sowohl aus dem Archiv als auch aus dem aktuellen Dateisystem richtig ermittelt wird. Im tar Quellcode, den man von https://savannah.gnu.org/projects/tar/ beziehen kann, gibt es auch einen Block für Selbsttests unter tar-1.34/tests. Dort wird auch - wie auch immer - die Update Funktion getestet. Ausprobiert habe ich das aber noch nicht.

[ernohl]

Soll ein komplettes Home oder gar das gesamte System gesichert werden dann nicht mehr. Im ersten Durchlauf wird gesamten Home gesichert , im Update Lauf wird nochmal alles hinten drangehängt ans Archiv. Obwohl sich nichts geändert hat, selbst wenns ro gemountet ist.

Ich kann deine Beobachtung bestätigen.

Code: Alles auswählen

erno@gauner:/workdir$ tar cf test.tar /Daten/erno
tar: Entferne führende „/“ von Elementnamen
erno@gauner:/workdir$ tar tvf test.tar | wc -l
5294
erno@gauner:/workdir$ tar uf test.tar /Daten/erno
tar: Entferne führende „/“ von Elementnamen
tar: Entferne führende „/“ von Zielen harter Verknüpfungen
erno@gauner:/workdir$ tar tvf test.tar | wc -l
10588

[Nachtrag:] /Daten/erno ist kein moint point.

Ich kann heisenbergs Empfehlung nur unterstützen. Meine echten Datensicherungen zu diesem Verzeichnis sehen so aus (gehören ein paar Scripte dazu):

Code: Alles auswählen

...
-rw-r--r-- 1 root root 263365434 Jun 13 07:37 Daten_erno.tar.240613_0736
-rw-r--r-- 1 root root       348 Jun 13 07:37 Daten_erno.log.240613_0736
-rw-r--r-- 1 root root     57438 Jun 14 08:10 Daten_erno-diff.tar.240614_0810
-rw-r--r-- 1 root root       354 Jun 14 08:10 Daten_erno.log.240614_0810
-rw-r--r-- 1 root root   1437615 Jun 15 08:53 Daten_erno-diff.tar.240615_0853
-rw-r--r-- 1 root root       356 Jun 15 08:53 Daten_erno.log.240615_0853
-rw-r--r-- 1 root root    106192 Jun 16 11:45 Daten_erno-diff.tar.240616_1145
-rw-r--r-- 1 root root       355 Jun 16 11:45 Daten_erno.log.240616_1145
-rw-r--r-- 1 root root      1252 Jun 19 07:48 Daten_erno-diff.tar.240619_0748
-rw-r--r-- 1 root root       353 Jun 19 07:48 Daten_erno.log.240619_0748
-rw-r--r-- 1 root root   1292013 Jun 20 08:17 Daten_erno-diff.tar.240620_0817
-rw-r--r-- 1 root root       356 Jun 20 08:17 Daten_erno.log.240620_0817
-rw-r--r-- 1 root root    106069 Jun 22 07:51 Daten_erno-diff.tar.240622_0751
-rw-r--r-- 1 root root       355 Jun 22 07:51 Daten_erno.log.240622_0751
-rw-r--r-- 1 root root    282373 Jun 26 08:39 Daten_erno-diff.tar.240626_0839
-rw-r--r-- 1 root root       355 Jun 26 08:39 Daten_erno.log.240626_0839
-rw-r--r-- 1 root root     96869 Jun 28 08:30 Daten_erno-diff.tar.240628_0830
-rw-r--r-- 1 root root       354 Jun 28 08:30 Daten_erno.log.240628_0830
-rw-r--r-- 1 root root    203066 Jun 29 08:08 Daten_erno-diff.tar.240629_0808
-rw-r--r-- 1 root root       355 Jun 29 08:08 Daten_erno.log.240629_0808
-rw-r--r-- 1 root root    111346 Jun 30 11:45 Daten_erno-diff.tar.240630_1145
-rw-r--r-- 1 root root       355 Jun 30 11:45 Daten_erno.log.240630_1145
-rw-r--r-- 1 root root      2112 Jul  1 08:06 Daten_erno-diff.tar.240701_0806
-rw-r--r-- 1 root root       353 Jul  1 08:06 Daten_erno.log.240701_0806
-rw-r--r-- 1 root root   1059438 Jul  2 07:49 Daten_erno-diff.tar.240702_0749
-rw-r--r-- 1 root root       356 Jul  2 07:49 Daten_erno.log.240702_0749

[Meillo]

https://savannah.gnu.org/projects/tar/

Danke fuer den Link. Ich habe mal einen kleinen Blick in den Code geworfen. Da habe ich diese Stelle gesehen: https://git.savannah.gnu.org/cgit/tar.g ... are.c#n533

Probier' mal aus, das Verzeichnis mit einem relativen Pfad anzugeben. Vielleicht findet er derzeit `/mnt/buster/home' im Archiv nicht, weil es dort `mnt/buster/home' heisst. Nur so als Idee ...


Zudem kannst du dir mal die Option `--warning' anschauen. Ich weiss bloss nicht, was man da als Argument angeben muss. Dann sollten weitere Informationsmeldungen kommen, vermute ich.

[KBDCALLS]

Das scheint es tatsächlich zu sein. Tar stößt sich an dem Verzeichnis. Drauf gekommen bin ich indem ich das Archiv mit -d verifiziert habe. Angeblich wurde keine Datei aus dem Verzeichnis im Archiv gefunden. Waren die Dateien in dem Vereichnis aus dem ich tar aufgerufen habe. Wurde beim anschießenden -d alles gefunden. Ist das jetzt ein Bug oder Feature?

[Meillo]

Ist das jetzt ein Bug oder Feature?

Ein Sicherheitsfeature, siehe: https://en.wikipedia.org/wiki/Tar_(computing)#Tarbomb und die Option `-P', um das Entfernen von fuehrenden Slashes abzuschalten (was aber eigentlich nie sinnvoll ist).

[chrbr]

Ich habe nun doch mal den Quellcode kompiliert. Nun habe ich also die GNU-Version von tar, es gibt nämlich auch andere Versionen .

Schon der Selbsttest ist glücklich. Die Option -u funktioniert wie unten gezeigt auch. Im Code sind Bemerkungen mit # nachträglich eingefügt.

Code: Alles auswählen

# Ein Archiv mit einer Datei erzeugen
[I] chris@thinkpad ~> Downloads/tar-1.34/src/tar -cvf backup.tar left_ptr 
left_ptr
[I] chris@thinkpad ~> Downloads/tar-1.34/src/tar -tvf backup.tar 
-rw-r--r-- chris/chris   20736 2024-07-02 13:28 left_ptr

# Die selbe Datei nochmal hinzufügen -> das wird übersprungen -> OK
[I] chris@thinkpad ~> Downloads/tar-1.34/src/tar -uvf backup.tar left_ptr
[I] chris@thinkpad ~> Downloads/tar-1.34/src/tar -tvf backup.tar
-rw-r--r-- chris/chris   20736 2024-07-02 13:28 left_ptr

# Den Zeitstempel der Datei verändert und nochmal hinzugefügt
# -> die Datei wird an das Archiv angehängt -> OK
[I] chris@thinkpad ~> touch left_ptr
[I] chris@thinkpad ~> Downloads/tar-1.34/src/tar -uvf backup.tar left_ptr
left_ptr
[I] chris@thinkpad ~> Downloads/tar-1.34/src/tar -tvf backup.tar
-rw-r--r-- chris/chris   20736 2024-07-02 13:28 left_ptr
-rw-r--r-- chris/chris   20736 2024-07-02 14:38 left_ptr

[heisenberg]

Ich finde das sinnvoll, die Pfade in einem tar-Archiv relativ zu halten. Absolute Pfade in einem Tar-Archiv würde ich als potentielle Fallgrube ansehen.

Deswegen vielleicht lieber so:

Code: Alles auswählen

tar -uvf /backup/archive.tar -C /home/user .