Ich weiss, dass mein NAS uralt ist, aber es läuft klaglos und in diesem Fall würde ich sogar ausdrücklich darauf verzichten, es durch ein neues zu ersetzen.
raspiBackup mit type rsync und backupPartition nfs bricht mit RC23 ab
-
framp -
11. November 2021 um 22:53 -
Erledigt
Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
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!
-
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:
Coderoot@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:
Code
Alles anzeigenroot@piwx:/NAS# ./framp.sh /mnt/qnap /usr/bin/setfacl *** /mnt/qnap supports ACLs getfacl: Removing leading '/' from absolute path names # file: mnt/qnap/framp.acls # owner: root # group: root user::rw- user:root:rwx group::r-- mask::rwx other::r-- root@piwx:/NAS#
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
Koenntest Du noch mal folgede bitte Ausgabe zeigen?
-
Du koenntest die Kiste auch an FSC830 verkaufen.
Nein! Ich habe schon 7(!) Stück hier stehen. Umsonst nehme ich sie, aber Geld nehme ich dafür nicht in die Hand.
Gruss
-
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
Alles anzeigen:~ $ sudo getfacl /mnt/qnap/<host>/<host>-rsync-backup-20211114-060901/var/log/journal getfacl: Entferne führende '/' von absoluten Pfadnamen # file: mnt/qnap/<host>/<host>-rsync-backup-20211114-060901/var/log/journal # owner: root # group: systemd-journal # flags: -s- user::rwx group::r-x group:adm:r-x mask::r-x other::r-x default:user::rwx default:group::r-x default:group:adm:r-x default:mask::r-x default:other::r-x
...keine Ausgabe (leer)
-
Umsonst nehme ich sie, aber Geld nehme ich dafür nicht in die Hand.
Schade. Ich hatte schon Freude ich hätte eine Goldgrube im Keller
-
Vielleicht hilft es was:
Code
Alles anzeigenroot@<host>:/mnt/qnap# bash /root/supportsACLs.sh /mnt/qnap /usr/bin/setfacl *** /mnt/qnap supports ACLs getfacl: Removing leading '/' from absolute path names # file: mnt/qnap/supportsACLs.acls # owner: root # group: root user::rw- user:root:rwx user:501:rwx user:nobody:--- group::rwx group:root:rwx group:users:rwx mask::rwx other::---
-
Oder liegt es doch am Pi OS und nicht am NAS?
64/32?
Ich benütze Bullseye 11/64:
Code
Alles anzeigen:/mnt/qnap# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" root@<host>:/mnt/qnap# uname -a Linux <host> 5.10.63-v8+ #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021 aarch64 GNU/Linux
-
Muss mal schauen, irgendwo muss ich noch eine Micro SD haben, die werde ich dann mal mit Bullseye aufsetzen.
Das läßt einem keine Ruhe .
Gruss
-
Bei meinem Bullseye kommt
Code
Alles anzeigenpi@raspberrypi-bullseye:~ $ getfacl /var/log/journal/d5e61a32a79e441584f8999f6ba98a42/ getfacl: Removing leading '/' from absolute path names # file: var/log/journal/d5e61a32a79e441584f8999f6ba98a42/ # owner: root # group: systemd-journal # flags: -s- user::rwx group::r-x group:adm:r-x mask::r-x other::r-x default:user::rwx default:group::r-x default:group:adm:r-x default:mask::r-x default:other::r-x pi@raspberrypi-bullseye:~ $ uname -a Linux raspberrypi-bullseye 5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l GNU/Linux
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
-
Blöde Frage: wo finde ich denn die 64bit Version? Auf raspberrypi.com sind das laut Webseite alles 32bit OS.
Gruss
-
wo finde ich denn die 64bit Version?
Index of /raspios_arm64/images/raspios_arm64-2021-11-08 (raspberrypi.org)
-
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:
Code
Alles anzeigen:~$ sudo raspiBackup.sh -g -d /dev/sdb /mnt/qnap/<host>/<host>-rsync-backup-20211116-060901/ --- RBK0009I: CND7513G7R: raspiBackup.sh V0.6.6.1 (91326c6) Di 16 Nov 2021 13:24:40 CET gestartet. !!! RBK0065W: Gerät /dev/sdb wird repartitioniert und die gesamten Daten werden gelöscht. --- RBK0066I: Gerät /dev/sdb wird überschrieben mit der gesicherten Boot- und Rootpartition. --- RBK0069I: Bootpartition /dev/sdb1 wird formatiert und erhält die zurückgespielte Bootpartition. --- RBK0070I: Rootpartition /dev/sdb2 wird formatiert und erhält die zurückgespielte Rootpartition. --- RBK0038I: Bist Du sicher? j/N j --- RBK0050I: Backup wird von /mnt/qnap/rpi4nc/rpi4nc-rsync-backup-20211116-060901 zurückgespielt. --- RBK0033I: Bitte warten bis aufgeräumt wurde. ??? RBK0077E: Restore wurde fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen. --- RBK0010I: <host>: raspiBackup.sh V0.6.6.1 (91326c6) Di 16 Nov 2021 13:24:47 CET beendet mit Returncode 112. --- RBK0026I: Debug Logdatei wurde in /home/<user>/raspiBackup.log gesichert.
raspiBackup.log:
Ein Restore von Buster scheint fehlerfrei durchzulaufen (im Gegensatz zu früher und zu "/boot" fehlt bei "/" die Fortschrittsanzeige, das irritiert mich etwas):
Code
Alles anzeigen:~$ sudo raspiBackup.sh -g -d /dev/sdb /mnt/qnap/rpi4nc/rpi4nc-rsync-backup-20211113-060901/ --- RBK0009I: CND7513G7R: raspiBackup.sh V0.6.6.1 (91326c6) Di 16 Nov 2021 13:40:24 CET gestartet. !!! RBK0065W: Gerät /dev/sdb wird repartitioniert und die gesamten Daten werden gelöscht. --- RBK0066I: Gerät /dev/sdb wird überschrieben mit der gesicherten Boot- und Rootpartition. --- RBK0069I: Bootpartition /dev/sdb1 wird formatiert und erhält die zurückgespielte Bootpartition. --- RBK0070I: Rootpartition /dev/sdb2 wird formatiert und erhält die zurückgespielte Rootpartition. --- RBK0038I: Bist Du sicher? j/N j --- RBK0050I: Backup wird von /mnt/qnap/rpi4nc/rpi4nc-rsync-backup-20211113-060901 zurückgespielt. --- RBK0053I: Erste Partition (Bootpartition) wird auf /dev/sdb1 zurückgespielt. 256MiB 0:00:07 [33.3MiB/s] [================================>] 100% --- RBK0055I: Zweite Partition (Rootpartition) wird auf /dev/sdb2 zurückgespielt. --- RBK0033I: Bitte warten bis aufgeräumt wurde. --- RBK0076I: Restore erfolgreich beendet. --- RBK0010I: rpi4nc: raspiBackup.sh V0.6.6.1 (91326c6) Di 16 Nov 2021 14:52:51 CET beendet mit Returncode 0. --- RBK0026I: Debug Logdatei wurde in /home/chief/raspiBackup.log gesichert.
Ich nehme an, dass der Pi mit dieser Disk booten würde. Wenn es gewünscht wird, prüfe ich das noch.
-
"Erst nach einem erfolgreichen Restore ist ein Backup ein Backup!"
scnr
-
wo finde ich denn die 64bit Version?
Ich habe keine Neuinstallation sondern einen Upgrade durchgeführt, indem ich die Paketquellen angepasst habe. Ich weiss, dass es nicht empfohlen wird.
Ich habe aber nur Debian Quellen in der sources.list
-
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 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:
Code1) 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.
-
bavoub Hast Du den Restore auch unter Bullseye gemacht?
-
folgende Schritte
20211113 funktioniert fehlerfrei. ich habe den Pfad angepasst
Code
Alles anzeigen<user>@<host>:~ $ exec script raspiBackup.log.verbose Script started, output log file is 'raspiBackup.log.verbose'. pi4chief@rpi4nc:~ $ execute sudo bash -x raspiBackup.sh -g -d /dev/sdb /mnt/qnap/<host>/<host>-rsync-backup-20211116-060901/ bash: execute: Kommando nicht gefunden. pi4chief@rpi4nc:~ $ exec sudo bash -x raspiBackup.sh -g -d /dev/sdb /mnt/qnap/<host>/<host>-rsync-backup-20211116-060901/ + '[' -z /usr/bin/bash ']' + MYSELF=raspiBackup.sh + MYNAME=raspiBackup + VERSION=0.6.6.1 + VERSION_SCRIPT_CONFIG=0.1.4 + VERSION_VARNAME=VERSION + VERSION_CONFIG_VARNAME='VERSION_.*CONF.*' ++ kill -l ++ grep -c SIG
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
Code
Alles anzeigen||1629> logIntoOutput(): read -r line |1853> writeToConsole(): consoleMsg='--- RBK0026I: Debug Logdatei wurde in /home/<user>/raspiBackup.log gesichert.' |1855> writeToConsole(): [[ I == \E ]] |1858> writeToConsole(): echo -e '--- RBK0026I: Debug Logdatei wurde in /home/<user>/raspiBackup.log gesichert.' --- RBK0026I: Debug Logdatei wurde in /home/pi4chief/raspiBackup.log gesichert. |1862> writeToConsole(): echo -e '--- RBK0026I: Debug Logdatei wurde in /home/<user>/raspiBackup.log gesichert.' |1865> writeToConsole(): (( ! !0 )) |1872> writeToConsole(): unset noNL |1721> logFinish(): [[ /home/pi4chief/raspiBackup.log != /home/<user>/raspiBackup.log ]] |1725> logFinish(): rm -rf /home/<user>/raspiBackup.msg |1727> logFinish(): [[ /home/<user>/raspiBackup.log == \/\h\o\m\e\/\<user>\/\r\a\s\p\i\B\a\c\k\u\p\.\l\o\g ]] |1728> logFinish(): chown <user>:<user> /home/<user>/raspiBackup.log |1729> logFinish(): [[ -s /tmp/raspiBackup.logf ]] |3772> cleanupStartup(): exit 108
raspiBackup.log.verbose wird dennoch angelegt. Sende ich Dir per PN.
-
Hast Du den Restore auch unter Bullseye gemacht?
Nein. Linux Mint:
Da ich nur diesen einen Pi habe, schliesse ich dazu eine identische USB SSD "T5 Samsung Portable SSD" 1TB an mein "Mint"-Notebook an.
-
Jetzt mitmachen!
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!