raspiBackup mit type rsync und backupPartition nfs bricht mit RC23 ab

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • raspiBackup mit type rsync und backupPartition nfs bricht mit RC23 ab? Schau mal ob du hier fündig wirst!

  • :conf: Die Einstellungen sind wie bei mir.

    Ohne Dir zu nahe treten zu wollen, aber bist Du sicher, das in dem Moment, wo Du das Script ausgeführt hast, das Filesystrm auf dem Pi auch gemountet war?

    Ich frage deshalb, weil:

    Mit gemountetem Filesystem:

    Code
    root@piwx:/NAS# ./framp.sh /mnt/qnap
    /usr/bin/setfacl
    ??? setfacl Fails on /mnt/qnap with RC 1
    setfacl: /mnt/qnap/framp.acls: Operation not supported
    root@piwx:/NAS# 

    Ohne den mount:

    Und das sieht fast so aus, wie Deine Ausgabe. Aber in dem Fall handelt es sich dann um ein lokales Filesystem.

    Gruss

  • Tut mir leid, dass es meinetwegen schlaflose Nächte gibt

    Nee ... passt schon. Ich kann gut schlafen. Ist nur irgendwie fuer mich unbefriedigend nicht zu verstehen warum es bei Dir funktioniert und bei allen anderen nicht ;(

    würde ich sogar ausdrücklich darauf verzichten, es durch ein neues zu ersetzen.

    Du koenntest die Kiste auch an FSC830 verkaufen. Der sucht haenderingend nach einer Moeglichkeit auch die ACLs seiner Raspis zu sichern :lol:

    Koenntest Du noch mal folgede bitte Ausgabe zeigen?

    Code
    getfacl /mnt/qnap/@HOSTNAME@/@HOSTNAME@-rsync-backup-20211114-060901/var/log/journal
    getfattr /mnt/qnap/@HOSTNAME@/@HOSTNAME@-rsync-backup-20211114-060901/var/log/journal
  • Nein, nein, schon ok. Ich bin User, nicht Experte:

    bist Du sicher, das in dem Moment, wo Du das Script ausgeführt hast, das Filesystrm auf dem Pi auch gemountet war?

    Ich weiss nicht, ob damit die Frage nach "mounted" oder nicht auch beantwortet ist. Die Kommandos habe ich auf dem Pi ausgeführt:

    Code
    :~ $ getfacl /mnt/qnap/<host>/<host>-rsync-backup-20211114-060901/var/log/journal
    getfacl: /mnt/qnap/<host>/<host>-rsync-backup-20211114-060901/var/log/journal: Keine Berechtigung
    Code
    :~ $ sudo getfattr /mnt/qnap/<host>/<host>-rsync-backup-20211114-060901/var/log/journal

    ...keine Ausgabe (leer)

  • Vielleicht hilft es was:

  • Oder liegt es doch am Pi OS und nicht am NAS?

    64/32?

    Ich benütze Bullseye 11/64:

  • Bei meinem Bullseye kommt

    D.h. die Attribute sind identisch mit denen von bavoub s Backup. Ich nutze aber nicht die 64bit RaspiOS Version. Das waere ja wirklich der Hammer wenn es in der 64bitter Version funktioniert :neutral:

  • Ich hoffe, ich stifte jetzt keine Verwirrung, aber vielleicht trägt es etwas zur Klärung bei.

    Ich habe mal versucht, mit dem Backup von heute früh einen Restore durchzuführen. Da ich nur diesen einen Pi habe, schliesse ich dazu eine identische USB SSD "T5 Samsung Portable SSD" 1TB an mein "Mint"-Notebook an. Der Pi startet von dieser und sie enthält "/" (EXT4) und "/boot" (VFAT). Ich habe das Verfahren schon mehrfach angewendet und es funktionierte bisher immer einwandfrei:

    raspiBackup.log:

    Code
    20211116-132447 DBG 2023:                  <-- logFinish

    Ein Restore von Buster scheint fehlerfrei durchzulaufen (im Gegensatz zu früher und zu "/boot" fehlt bei "/" die Fortschrittsanzeige, das irritiert mich etwas):

    Ich nehme an, dass der Pi mit dieser Disk booten würde. Wenn es gewünscht wird, prüfe ich das noch.

  • Mit deb http://raspbian.raspberrypi.org/raspbian/ bullseye main contrib non-free rpi in "sources.list" erhalte ich Fehlermeldungen beim update: ...wird übersprungen, da das Depot »http://raspbian.raspberrypi.org/raspbian bullseye InRelease« die Architektur »arm64« nicht unterstützt.

  • Der RC112 kommt wenn die Partitionen nicht erstellt werden koennen. Bloed dass das Debuglog fast leer ist :wallbash: Da wuerden wir sehen das die Ursache ist. Es koennte sein dass sich sfdisk bzw das exportierte Format geaendert hat. Das hab es schon einmal bei einem releasewechsel gehabt. Ich habe bislang noch keinen Test gemacht ob Backup/Restore mit Bullseye funktioniert.

    Hier hat jemand auch das Problem eines fast leeren Logs. bavoub Wir sollte jetzt Dein Restoreproblem von diesem Thread trennen denn es ist <OT>. Da kein Log existiert fuehre bitte folgende Schritte aus:

    Code
    1) execute script raspiBackup.log.verbose
    2) execute sudo bash -x raspiBackup.sh -g -d /dev/sdb /mnt/qnap/rpi4nc/rpi4nc-rsync-backup-20211113-060901/
    3) execute exit
    4) provide raspiBackup.log.verbose

    und schicke mir das gezippte Verbose log per PN. Ich mache dann einen neuen Thread dazu auf wo wir das Problem weiterverfolgen.

  • folgende Schritte

    20211113 funktioniert fehlerfrei. ich habe den Pfad angepasst

    Der Aufruf von :~ $ exec sudo bash -x raspiBackup.sh -g -d /dev/sdb /mnt/qnap/rpi4nc/rpi4nc-rsync-backup-20211116-060901/ stirbt (wird nie abgeschlossen) mit

    raspiBackup.log.verbose wird dennoch angelegt. Sende ich Dir per PN.

Jetzt mitmachen!

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