raspibackup.sh Dateipfad ausschließen

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

    seit heute sichert sich auch mein RaspberryPi von alleine, dank raspibackup.sh!

    Danach habe ich meine root Partition von der SD Karte auf die externe SSD verlegt.

    Auf der SSD ist auch der Backup Ordner.

    Aktuell läuft das raspibackup.sh Script und die .tar Backup Datei wird immer größer und größer und größer. Aktuell sind es 37GB, und es wächst immer weiter.
    Vorher auf der SD Karte waren es nur 2,1GB.

    Ich vermute, daß raspibackup.sh auch den Backup Ordner in das neue aktuelle Backup sichert.

    Laut der Website https://www.linux-tips-and-tricks.de/de/raspberry/2…kups-of-itself/ gibt's den Parameter -u. Es steht aber auch in der Beschreibung: "Folgende Verzeichnisse werden niemals gesichert: Der Backupfad (Parameter -p)"

    Tja, hmm was denn nun?
    -u oder -p und wie genau ist die Syntax?

    Wie muss ich den Aufruf des Scriptes verändern, so dass der Backuppfad nicht mitgesichert wird?
    Der Eintrag in der /etc/crontab ist folgendermaßen:

    Code
    0 2     * * *   root    /usr/local/bin/raspiBackup.sh -t tar -k 4 -e meine@email.de /ssd/backup

    Könnte mir jemand die obige Zeile korrigieren? (Ich bin blutiger Anfänger in Linux)

    Vielen Dank und lieben Gruß,
    Chris

  • Du solltest den Backupordner nicht excluden muessen. Wie schon in der Beschreibung steht wird der excluded. Du hast allerdings die Rootpartition extern und diese wird mitgesichert. Ausserdem sicherst Du auch Deinen Backup darauf. Es sieht mir so aus als ist das die Ursache. Du kannst ja mal raspiBackup manuell aufrufen und die Parameter

    Code
    -l 1 -m 1 -L current

    mitgeben. In der Datei raspiBackup.log steht viel drin - aber irgendwo findest Du auch exakt den tar Befehl, der von raspiBackup ausgeführt wird. Du musst in dem Log nur nach dem String RBK0085I suchen. Bei mir sieht es bei einem -P Mode backup z.B. so aus:

    Code
    20161106-113334: MSG --- RBK0085I: Backup of type tar progressing. Please be patient
    20161106-113334: DBG -- tar                     -cpi                                                                                            -f "/backup/raspberrynoobs/raspberrynoobs-tar-backup-20161106-113314/mmcblk0p1.tar"                     --one-file-system                       --warning=no-xdev                       --numeric-owner                         --exclude="/backup"                     --exclude=/proc/*                       --exclude=/lost+found/*                         --exclude=/sys/*                        --exclude=/dev/*                        --exclude=/tmp/*


    Zeige mal wie der Befehl bei Dir aussieht und die Ausgabe des Befehls

    Code
    sudo mount
  • Moin,

    ich habe das auch so verstanden, dass der Backup Pfad nicht explizit excluded werden muss.

    "sudo Mount" ergibt folgendes:

  • Die Zeile mit dem tar Befehl fehlt noch ;) Oder Du schickst mir Dein Log direkt zu so dass ich mal reinsehen kann. Das hätte auch den Vorteil dass ich auch andere Informationen darin finde die mir helfen die Ursache zu lokalisieren.

  • Ich habe ein bisschen gebraucht um die .log Datei heraus zu kriegen (bin ja Anfänger ;)

    Reicht die .log Datei, die das Backup heute morgen erzeugt hat?
    Ich wollte es dem Raspberry und der SSD möglichst ersparen, das nochmal wuppen zu müssen.
    Wie man sehen kann, hat es rund 52 Minuten gedauert, bis die insgesamt 43 Gigabyte durchgelaufen sind.


    Automatisch zusammengefügt:
    Hier der Inhalt des Backup Ordners:

    Code
    pi@raspberrypi:/ssd/backup/raspberrypi/raspberrypi-tar-backup-20161106-020001 $ ls -hal
    total 43G
    drwxr-xr-x 2 root root 4.0K Nov  6 02:52 .
    drwxr-xr-x 8 root root 4.0K Nov  6 02:52 ..
    -rw-r--r-- 1 root root  63M Nov  6 02:00 raspberrypi-backup.img
    -rw-r--r-- 1 root root  26K Nov  6 02:52 raspberrypi-backup.log
    -rw-r--r-- 1 root root  512 Nov  6 02:00 raspberrypi-backup.mbr
    -rw-r--r-- 1 root root  273 Nov  6 02:00 raspberrypi-backup.sfdisk
    -rw-r--r-- 1 root root  43G Nov  6 02:52 raspberrypi-tar-backup-20161106-020001.tar

    Einmal editiert, zuletzt von themanfrommoon (6. November 2016 um 12:16)

  • Der Logausschnitt reicht. Es ist deutlich zu sehen dass das Backupverzeichnis excluded wird:

    Code
    --exclude="/ssd/backup"


    und es ist deutlich zu sehen dass das tar selbst auch gesichert werden soll:

    Code
    tar: /backup/raspberrypi/raspberrypi-tar-backup-20161106-020001/raspberrypi-tar-backup-20161106-020001.tar: file is the archive; not dumped


    Allerdings wird das tar unter
    /backup/raspberrypi/raspberrypi-tar-backup-20161106-020001/raspberrypi-tar-backup-20161106-020001.tar

    angemeckert und nicht unter
    /ssd/backup/raspberrypi/raspberrypi-tar-backup-20161106-020001/raspberrypi-tar-backup-20161106-020001.tar

    wo es ja hingeschrieben wird :s Hast Du ein Verzeichnis /backup bei Dir? Zeige mal die Ausgabe von

    Code
    ls -la /

    .

    BTW: Es ist etwas ungewöhnlich wenn man ein Backup zieht und das Backup wieder auf dem Gerät ablegt, was man gesichert hat. Wenn das Gerät verreckt ist das Backup auch weg :(

  • ls -la / fördert folgendes zu Tage:

    Zitat

    BTW: Es ist etwas ungewöhnlich wenn man ein Backup zieht und das Backup wieder auf dem Gerät ablegt, was man gesichert hat. Wenn das Gerät verreckt ist das Backup auch weg undefined

    Ja, das ist korrekt!
    Ich bin mit meiner Backup Orgie ja auch noch nicht fertig.

    Ich hatte zunächst das Konstrukt:
    SD im Raspi als root und boot
    SSD am Raspi als Backup

    Dann ist mir nach einer guten Woche die SD ausgefallen.
    Daraufhin habe ich nun seit gestern folgendes Konstrukt:
    SD im Raspi als boot
    SSD am Raspi als root und Backup

    Das Backup ergibt so natürlich keinen Sinn wenn die SSD ausfällt.

    Dafür kommt dann, wenn das soweit läuft später noch ein weiteres Backup hinzu, was dann folgendes Konstrukt ergibt:
    SD im Raspi als boot
    SSD am Raspi als root und tägliches Backup. Das tägliche Backup soll vor allem vor falschen Einstellungen und versehentlichem Löschen usw. helfen. So kann man leichter zu einem funktionierendem System zurück.
    Synology NAS als wöchentliches Backup

    Das NAS soll (noch?) nicht 24/7 laufen, sondern nur bei Bedarf.

    Lieben Gruß,
    Chris


    Automatisch zusammengefügt:
    Hmmm, aha, wie ist das denn passiert?!

    Scheinbar ist die SSD einmal unter /ssd/backup und einmal unter /backup gemountet

    Und vor allem wo kommt das her und wie werde ich das wieder los?

    Lieben Gruß,
    Chris


    Automatisch zusammengefügt:
    Ich habe das Python Script "raspiSD2USB.py" benutzt, um die boot Partition von der SD auf die SSD zu verschieben.

    Kann das sein, das dabei irgendwo und irgendwie dieser mount zustande gekommen ist?

    Lieben Gruß,
    Chris

    Einmal editiert, zuletzt von themanfrommoon (6. November 2016 um 13:36)

  • Also, in meiner aktuellen /boot/cmdline.txt steht folgendes:

    Code
    dwc_otg.lpm_enable=0 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

    Sieht aus wie root ist meine externe ssd.

    In der vom Python Script "raspiSD2USB.py" gesicherten /boot/cmdline.txt.sd steht:

    Code
    dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait


    Da war root noch die interne SD

    Ich denke das passt soweit?!

    Ich vermute, das die ssd zweimal gemountet ist.
    Einmal unter /ssd/backup und einmal unter /backup.
    Kann das sein?
    Und wenn ja, wie krieg ich das dauerhaft wieder weg?

    Ich weiss nicht, ob was hilft, aber meine aktuelle /etc/fstab sieht so aus:

    Code
    proc            /proc           proc    defaults          0       0
    /dev/mmcblk0p1  /boot           vfat    defaults          0       2
    /dev/sda1  /               ext4    defaults,noatime  0       1
    /dev/sda1       /ssd            ext4    defaults,noatime  0       1
    tmpfs /tmp tmpfs nodev,nosuid,mode=1777,size=30M 0 0
    # a swapfile is not a swap partition, no line here
    #   use  dphys-swapfile swap[on|off]  for that

    Lieben Gruß,
    Chris


  • Ich denke das passt soweit?!

    Ja, alles OK.

    Zitat

    Ich vermute, das die ssd zweimal gemountet ist.
    Einmal unter /ssd/backup und einmal unter /backup.
    Kann das sein?


    Ja das sieht man aus der /etc/fstab. Auch schon bei der mount Ausgabe oben. Nur habe ich das irgendwie nicht gesehen :( Du hast /dev/sda1 zweimal an verschiedene Stellen gemountet. Einmal unter / und einmal unter /ssd. Damit siehst Du das Backupverzeichnis von / aus (von da wird von raspiBackup gesichert) zweimal unter anderem Namen: Einmal /backup und einmal /ssd/backup und deshalb greift der exclude fuer /ssd/backup - aber nicht fuer /backup. Du konntest jetzt natürlich noch /backup excluden. Aber die bessere Lösung ist diesen doppelten Mount zu beseitigen.

    Zitat

    Und wenn ja, wie krieg ich das dauerhaft wieder weg?


    Ein

    Code
    sudo umount /ssd

    und dann löschen der folgenden Zeile in der /etc/fstab:

    Code
    /dev/sda1       /ssd            ext4    defaults,noatime  0       1


    Dann /backup als Backuppfad bei raspiBackup nehmen und nicht /ssd/backup. Dann sollte alles klappen. Auch der exclude. Du kannst dann auch beim manuellen Aufruf noch mal die Option -v mitgeben. Dann siehst Du welche Dateien er alles ins tar steckt und Du solltest jetzt dann nichts mehr aus /backup sehen.

  • Hallo Framp,

    [font="Courier New"]sudo umount /ssd -> habe ich gemacht[/font]
    [font="Courier New"]"/dev/sda1 /ssd ext4 defaults,noatime 0 1" habe ich aus der /etc/fstab gelöscht[/font]
    [font="Courier New"]In der "/usr/local/etc/raspiBackup.conf" habe ich den Pfad von "/ssd/backup" nach "backup" geändert[/font]
    [font="Courier New"]In der "/etc/crontab" habe ich den Pfad ebenfalls [font="Courier New"]von "/ssd/backup" nach "backup" geändert[/font][/font]

    [font="Courier New"]Somit müsste das jetzt sauber sein.[/font]
    [font="Courier New"]Ein Reboot habe ich nicht durchgeführt. (oder wäre das nötig?)[/font]

    Dann habe ich das Backup manuell gestartet mit: "sudo /usr/local/bin/raspiBackup.sh -v"
    Als Antwort kam jetzt:

    Code
    --- RBK0009I: raspberrypi: raspiBackup.sh V0.6.1.3b um Sun  6 Nov 17:15:34 CET 2016 gestartet
    --- RBK0128I: Logdatei ist /backup/raspberrypi/raspberrypi-tar-backup-20161106-171533/raspberrypi-backup.log
    --- RBK0116I: Konfigurationsdatei /usr/local/etc/raspiBackup.conf wird benutzt
    ??? RBK0027E: Kein externes Gerät an /backup verbunden. Die SD Karte würde für das Backup benutzt werden.
    --- RBK0026I: Logdatei wird in /home/pi/raspberrypi-raspiBackup.log gesichert
    --- RBK0043I: Unvollständiges Backup /backup/raspberrypi/raspberrypi-tar-backup-20161106-171533 wird gelöscht (Kann etwas dauern. Bitte etwas Geduld)
    ??? RBK0102E: Backup fehlerhaft beendet


    =( =( =( =( =( =( =( =( =( =( =( =( =(

    Wo steckt der Wurm denn nun wieder?! :s

    Lieben Gruß,
    Chris

  • raspiBackup hat eine Notbremse die verhindert dass man aus Versehen sein Backup auf der SD Karte erstellt. Das macht keinen Sinn und kann bei kleinen SD Karten dazu führen dass die SD Karte vollgeschrieben wird bis zum Stehkragen :-/

    Die Notbremse testet ob am Backuppfad, bei Dir also /backup, etwas gemounted ist. Es gibt aber eine Option -c mit der man diesen Check ausschalten kann ;)

  • Okay, jetzt bin ich wieder im Rennen! Das Backup läuft und auch wieder nur mit der Größe der erwarteten 2,1GB :danke_ATDE:

    Allerdings kommt noch folgende Fehlermeldung:

    Code
    /chris-ds213/
    ??? RBK0024E: Backupprogramm tar hat einen Fehler bekommen.
    Warning: Unit file of apache2.service changed on disk, 'systemctl daemon-reload' recommended.
    !!! RBK0049W: Einige Dateien haben sich während des Backups geändert oder sind verschwunden. RC: 1 - Änderung wird ignoriert
    --- RBK0007I: Services werden gestartet: 'service mysql start; service apache2 start; service vzlogger start; service cron start'
    --- RBK0010I: raspberrypi: raspiBackup.sh V0.6.1.3b um Sun  6 Nov 17:46:44 CET 2016 beendet
    --- RBK0017I: Backup erfolgreich beendet

    Das dürfte doch aber nicht passieren, weil ich den Apache doch gestoppt habe:

    Code
    --- RBK0008I: Services werden gestoppt: 'service cron stop; service vzlogger stop; service apache2 stop; service mysql stop'

    Lieben Gruß,
    Chris

  • War eine schwere Geburt :D Eine Partition zweimal mounten ist auch wirklich ziemlich unüblich - und damit hast Du den exclude bei raspiBackup ausgetrixt :)

    Ich habe den Fehlerstring "Unit file of apache2.service changed on disk" mal Suchmaschinen vorgeworfen. Es kommt wohl haeufiger vor - ist aber wohl ein unschoender Bug.

  • Ja, das war wirklich eine schwere Geburt.
    Aber so lernt man auch ne Menge.
    Mir ist nicht wirklich klar, warum die SSD zweimal gemountet war. Absichtlich war das jedenfalls nicht.

    Okay, dann liegt der Fehler mit dem Apache Service nicht am RaspiBackup und nicht an den Einstellungen. Das ist okay für mich. Das Problem scheint auch nicht bei jedem Durchlauf vom RaspiBackup aufzutreten.

    Also nochmals vielen Dank!

    Lieben Gruß,
    Chris

  • Ich weiss warum Du Deine SSD zweimal gemountet hattest: Als Du noch nur mit der SD gefahren bist musstest Du die SSD mounten und hast es unter /ssd getan. root ( / ) war auf /dev/mmcblk0p2 gemountet. raspiSD2USB hat dann die Zeile in der /etc/fstab mit dem mmcblk0p2 auf sda1 geändert. Und damit hattest Du die SSD zweimal gemountet :-/

  • Zitat

    Es gibt aber eine Option -c mit der man diesen Check ausschalten kann


    Die ist aber noch nirgendwo dokumentiert, oder? Hab ich jedenfalls bei den Optionen noch nicht gefunden. Aber cool, das du auch daran schon gedacht hast :thumbs1:

    Zitat

    Ich weiss warum Du Deine SSD zweimal gemountet hattest: Als Du noch nur mit der SD gefahren bist musstest Du die SSD mounten und hast es unter /ssd getan. root ( / ) war auf /dev/mmcblk0p2 gemountet. raspiSD2USB hat dann die Zeile in der /etc/fstab mit dem mmcblk0p2 auf sda1 geändert. Und damit hattest Du die SSD zweimal gemountet


    Das hatte ich mir schon gedacht. Dann hab ich das jetzt auch verstanden :D

    Also, Problem gelöst! :bravo2:
    :danke_ATDE:
    Lieben Gruß,
    Chris

Jetzt mitmachen!

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