tar macht Vollbackup nach Pi neustart

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    ich habe folgendes Problem.
    Ich habe ein bash script das nach einer Vollsicherung mit tar nur noch inkrementell sicher. Das funktioniert auch sehr gut, bis ich den Pi neu starte. Dann scheint tar alles zu vergessen und sichert im nächsten inkrementell ALLE Datein. Ich sichere von einer gemounteten Platte auf eine gemounteten Platte.
    Ich habe erfahren das tar mit den Checksummen der Verzeichnisse arbeitet um das inkrementell zu steuern. Ich vermute nun, dass durch das erneute Einhängen der Platten die Checksumme vom Verzeichnis ändert und somit alles als geändert angesehen wird.

    Gibt es eine Möglichkeit die Platten so einzuhängen dass es die Checksumme nicht verändert?
    Oder hatte schonmal jemand anderes so ein Problem und wie hat er es gelöst.

    Viele Grüße

  • Servus Alti,
    ich glaube nicht, dass das was mit irgendwelchen Checksummen zu tun hat.
    Ich habe da eher den Verdacht, dass Du z.B. den mountpoint als Startverzeichnis für Dein Backup gewählt hast. Und dessen Timestamp für die "modification-time" wird sich vermutlich bei jedem Einhängen ändern.
    Evtl. brauchst Du nur ein Verzeichnis tiefer mit Deinem Backup starten ...

    Das wär' jetzt auf die Schnelle mal meine Erklärung für das Verhalten.
    cu,
    -ds-

  • Sorry hatte ich vergessen hier der tar Befehl:

    tar -cpzf ${BACKUPDIR}/${filename} -g ${BACKUPDIR}/${TIMESTAMP} ${SOURCE} ${EXCLUDE}

    BACKUPDIR=media/usbBackUp/backup-TV
    filename=backup-TV-${backupnr}.tgz
    TIMESTAMP="timestamp.dat"
    SOURCE="media/usbhdd1/TV"
    EXCLUDE=""

    Die Idee mit dem Mountpunkt fand ich gut, aber das TV bereits ein Verzeichnis auf der Platte ist denke ich nicht, dass es das ist oder?

    Einmal editiert, zuletzt von Alti (30. Oktober 2016 um 01:07)


  • ... TV bereits ein Verzeichnis auf der Platte ist ...


    nun, dann schau halt mal mit stat nach wie die Zeiten momentan gesetzt sind, mach einen reboot (oder umount/mount) und guck nach, ob sich was geändert hat ;)

    Code
    cd media/usbhdd1
    stat TV

    war, wie gesagt, nur so eine spontane Idee ....

    cu,
    -ds-

  • Wie gesagt die Idee fand ich gut und sehr plausibel :thumbs1:
    aber es scheint etwas anderes zu sein :s .

    Code
    File: ‘TV’
     Size: 0               Blocks: 0          IO Block: 4096   directory
    Device: 811h/2065d      Inode: 445532      Links: 1
    Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2016-06-01 08:45:10.296291600 +0200
    Modify: 2016-02-06 10:08:38.030488200 +0100
    Change: 2016-02-06 10:08:38.030488200 +0100
    Birth: -

    Auf der Seite http://linuxwiki.de/tar steht:

    Zitat

    So, wie geht das nun: tar kennt den Schalter '-g', mit dem ein Log aller Verzeichnisse mit Prüfsummen angelegt wird. Anhand dieser Prüfsummen entscheidet tar dann später, welche Dateien bei einem inkrementellen Backup zu sichern sind. Ausgangspunkt ist das /home Verzeichnis, das gesichert werden soll. Die Archive und die Logs landen in /backup:

    Es scheint beim erneuten Einhängen der Platte (über fstab) nach einem Neustart wird eine neue Prüfsumme gebildet.
    Deshalb ist die Frage wie kann ich das vermeiden, DENN(!) mein Testbackup das ich von meinem /home Verzeichnis mache ist von den Neustarts total unbeeindruckt!!!
    Automatisch zusammengefügt:
    Das was sich nur verändert hat nach dem reboot ist Device:

    erste Abfrage:

    Code
    File: ‘TV’
    Size: 0               Blocks: 0          IO Block: 4096   directory
    Device: 811h/2065d      Inode: 445532      Links: 1
    Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2016-06-01 08:45:10.296291600 +0200
    Modify: 2016-02-06 10:08:38.030488200 +0100
    Change: 2016-02-06 10:08:38.030488200 +0100
    Birth: -

    zweite Abfrage:

    Code
    File: ‘TV’
     Size: 0               Blocks: 0          IO Block: 4096   directory
    Device: 821h/2081d      Inode: 445532      Links: 1
    Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2016-06-01 08:45:10.296291600 +0200
    Modify: 2016-02-06 10:08:38.030488200 +0100
    Change: 2016-02-06 10:08:38.030488200 +0100
    Birth: -

    Einmal editiert, zuletzt von Alti (30. Oktober 2016 um 10:10)

  • Servus,
    hast Du mal geschaut, ob Du die Checksummen beim tar für das Backup evtl. abschalten kannst?
    Ich bilde mir ein mal irgendwo gelesen zu haben, dass es bei rsync möglich ist für Backups die Prüfung auf Datei-Änderungen über Checksummen zu deaktivieren.
    Evtl. mal überlegen auf rsync umzusatteln ... :s

    //EDIT: dass sich das Device ändert stufe ich als Änderungs-Kriterium für irrelevant ein.

    cu,
    -ds-

  • Vielen Dank Dreamshader für das gemeinsame Kopfzerbrechen :lol:

    Es sieht so aus, dass ich Dein EDIT widerlegen muss.

    denn ich habe herausgefunden das die Device ID in hex simultan zu den Device ID aus dem blkid ist.
    Hier meine leihenhafte Annahme:
    8 an der 3. Stelle von rechts entspricht "sd", die 2. Stelle von rechts entspricht dem Devicebuchstaben (a, b, c etc.) und die rechteste Stelle der Partition.
    Demnach muss diese Platte jetzt unter /dev/sdc1 hängen und sie tut es auch.

    Dann dachte ich mir ich mache nun jedesmal ein kleines backup und boote neu um zusehen ob das inkrementell backup mit eine gleichen DeviceID normal fortgeführt wird...
    Brauchte ich aber nicht, denn wenn die Platte unter sdc1 hängt werden die inkrementell backups normal fortgeführt.

    Code
    File: ‘TV’
     Size: 0               Blocks: 0          IO Block: 4096   directory
    Device: 821h/2081d      Inode: 445532      Links: 1
    Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2016-06-01 08:45:10.296291600 +0200
    Modify: 2016-02-06 10:08:38.030488200 +0100
    Change: 2016-02-06 10:08:38.030488200 +0100
    Birth: -

    Das heißt: Wie bekomme ich raspbian dazu jede Platte immer wieder unter der gleichen Device ID einzuhängen, also dass die Fileserviceplatte immer sdc1 ist.

    Noch eine Frage zu rsync: Macht rsync auch incremental und komprimiert rsync auch?

    Einmal editiert, zuletzt von Alti (30. Oktober 2016 um 11:06)

  • Tja ...


    Vielen Dank Dreamshader für das gemeinsame Kopfzerbrechen :lol:


    gerne ... das ist ja Sinn und Zweck des Forums. Ausserdem lerne ich auch immer wieder was dazu oder kann mein Wissen auffrischen.


    ...
    Es sieht so aus, dass ich Dein EDIT widerlegen muss.

    kein Problem ... ich finde es immer gut zu wissen, wenn etwas anders läuft als ich mir das gedacht hatte (s.o. man lernt nie aus).


    ... Das heißt: Wie bekomme ich raspbian dazu jede Platte immer wieder unter der gleichen Device ID einzuhängen, ...

    Da ist das Zauberwort udev ...
    Such mal hier im Forum ... da findest Du einiges zu diesem Thema.


    ... Macht rsync auch incremental und komprimiert rsync auch?

    Inkremental auf alle Fälle ... wie da die Aufruf-Option(en) heiss(t)en weiss ich aber jetzt nicht auswendig.
    Komprimieren ... da bin ich überfragt ... notfalls einfach nach Abschluss des Backups über cron ein Kompressions-script starten ( wär jetzt wieder so der erste Gedanke dazu ).

    cu,
    -ds-

  • Es sollte eigentlich nicht nötig sein mit udev rum zu spielen um ein inkrementelles Backup zu erstellen.

    Man kann auch mal

    Code
    --no-check-device

    versuchen.

    Ich würde nicht direkt rsync verwenden um ein Backup zu erstellen sondern dies über rsnapshot machen. Das Konzept voll-/inkrementelles Backup ist hier durch die Verwendung von Hardlinks etwas ineinander verwachsen. Jedes inkrementelle Backup stellt ein eigenständiges volles Backup dar und verbraucht nur den Speicherplatz eines inkrementellen soweit ein volles Backup mal erstellt wurde. Kompression unterstützt rsnapshot/rsync nur während der Datenübertragung mit ssh. Du kannst aber theoretisch ein komprimiertes Archiv wie zip, tar.gz o. ä. ins Filesystem mounten und dann dein Backup dort rein laufen lassen.

    Einmal editiert, zuletzt von florian0285 (30. Oktober 2016 um 12:27)

  • He he, wie soll's auch anders sein, trotz zig reboots wird die Platte immer wieder als sdc1 eingehängt und ich kann nichts testen.

    Ich denke die [font="monospace"]--no-check-device[/font] Option die ist die flexibelste Lösung, wenn sie funktioniert ;) , werde es testen wenn ich mal wieder an der Platten rumstöpsel. Achja, wenn ich jetzt die Option mit aufnehme, fängt tar dann wieder überall mit eine Vollbackup an, oder kann tar die DeviceID rausrechnen?

    Wenn ich die udev Lösung nehmen würde, würde ich dann [font="monospace"]SYMLINK+="fileservice"[/font] eintragen und dann im /etc/fstab [font="monospace"]/dev/fileservice /media/usbhdd1/ ntfs-3g defaults,umask=000,users 0 0[/font] zum mounten? Nur eine geänderte Device ID wie sda1 (zB) würde bleiben. Oder würde dann auch die Device ID in stat für "fileservice" und nicht für sdc1 angezeigt?

    Wenn ich mir das so ansehe befürchte ich, egal wofür ich mich entscheide, ich muss erstmal wieder mit einem Vollbackup anfangen, oder?

  • Deinem udev+mount Gedankengang kann ich grad nicht wirklich folgen...

    tar sollte eigentlich das vorhandene vollbackup ranziehen. Das Device interessiert es nicht (mehr) und ausgehend von den Pfadangaben sollten nur noch die Daten dahinter verglichen werden.
    Natürlich sollte man das, wie alles andere auch, vorher testen bevor man es produktiv einsetzt ;)

  • Hi,


    Deinem udev+mount Gedankengang kann ich grad nicht wirklich folgen...
    ...

    Du kannst über udev-Regeln sicherstellen, dass ein Datenträger immer am selben mount-point eingehängt wird.
    meigrafd hatte -> hier mal was dazu geschrieben <- ...

    Wie das jetzt in Alti's Fall konkret aussieht, kann ich nicht sagen. Da müsste ich mich jetzt auch erst (wieder) reinlesen.

    Ob ein Vollbackup fällig ist? Hm ... evtl. ist es möglich die externe Platte passend einzuhängen.
    Wenn nicht, dann denke ich schon.
    Wobei ich in diesem Fall ernsthaft darüber nachdenken würde, statt tar eben rsync - oder besser - we von florian0285 -> in diesem Beitrag <- erwähnt, z.B. rsnapshot zu verwenden.

    cu,
    -ds-

  • Ich habe mal ein kleines Backup gestartet und wenn die Syntax:

    Code
    tar --no-check-device -cpzf ${BACKUPDIR}/${filename} -g ${BACKUPDIR}/${TIMESTAMP} ${SOURCE} ${EXCLUDE}


    richtig ist, klammert tatsächlich tar die DeviceID einfach aus. Es wird ganz normal das nächste incremental angelegt.


    Deinem udev+mount Gedankengang kann ich grad nicht wirklich folgen...


    Die Frage für mich war, wenn ein physisches USB Gerät eingehängt wird, heisst es zunächst (als Platte) sd?x. Dann biege ich den Namen in der udev auf fileservice (oder backup wie bei meigrafd) um und mounte es über die fstab an meinem /media/usbhdd1.

    Dass tar für den device check nicht /media/usbhdd1 nimmt, ist klar sonst hätte ich diese Problem nicht. Die Frage ist nun, nimmt tar fileservice als device oder weiterhin sdc1 (in meinem Fall). Leider befürchte ich, dass es weiterhin sdc1 sein wird, da ich bisher in der fstab auch über die UUID und nicht über die sd?x gemounted habe.

    Wenn das jetzt ausgeräumt ist, werde ich in den nächsten Tagen mal mein Backup "Projekt" vorstellen mit einem kaskadierenden (modifizierbarem) Backup script für eine Vollsicherung meiner 1.5TB Platte.
    :danke_ATDE: für Eure Unterstützung

    Einmal editiert, zuletzt von Alti (30. Oktober 2016 um 17:22)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!