raspiBackup Komisches Verhalten beim Restore

Ich habe vorhin mein System mit raspiBackup restored, nachdem ich mich in nextcloud ausgesperrt hatte. Pi5 mit NVME.

• Vom "Notfalldatenträger" gebootet. (Auf diesem ist nur raspiBackup installiert. Kein Mailprogramm)
• Restore lief einwandfrei durch.
• Pi heruntergefahren
• "Notfalldatenträger entfernt und von NVME neu gebootet. Alles Einwandfrei.

Jetzt das merkwürdige. Nach dem Booten der NVME erhielt ich eine Email. (Trixie: Backup nicht erfolgreich!!!)
Der Hostname vom "Notfalldatenträger" ist "backup"
Inhalt

--- RBK0009I: Trixie: raspiBackup.sh V0.7.2 - 2025-12-02 (c3fa944) Di 3. Mär 12:52:16 CET 2026 gestartet
--- RBK0031I: Prüfe ob eine neue Version von raspiBackup.sh verfügbar ist
--- RBK0151I: Backuppfad /backup mit Partitionstyp wird benutzt
??? RBK0027E: Kein externes Gerät an /backup verbunden. Die root Partition würde für das Backup benutzt werden
--- RBK0033I: Bitte warten bis aufgeräumt wurde
--- RBK0320I: Unvollständiges Backup wird gelöscht. Das kann etwas dauern. Bitte Geduld
??? RBK0005E: Backup fehlerhaft beendet. Siehe vorhergehende Fehlermeldungen
--- RBK0010I: Trixie: raspiBackup.sh V0.7.2 - 2025-12-02 (c3fa944) Di 3. Mär 12:52:17 CET 2026 beendet mit Returncode 102

Ich hatte aber kein Backup angestoßen. Automatische Backups laufen Sonntags um 5:00 Uhr

lsblk
NAME          SIZE TYPE MOUNTPOINT            UUID                                 PARTUUID
loop0           2G loop
sda         465,8G disk
├─sda1      221,6G part /backup               7a35cc33-5ab5-4fb2-8102-d27d23d9a676 0098a4f5-01
└─sda2      244,1G part /home                 bb6a6a75-ef1a-4a61-8007-e49bfdd0200a 0098a4f5-02
zram0           1G disk [SWAP]                5fb700d3-85ca-4be6-818a-aef8e99815ad
nvme0n1     476,9G disk
├─nvme0n1p1   512M part /boot/firmware        EB03-EB51                            b6ca1593-01
└─nvme0n1p2 476,4G part /                     fcaecaff-8a9d-40c4-8b8a-afbfea6ebb7d b6ca1593-02

Dann habe ich den "Notfalldatenträger" verbunden und / nach /mnt gemountet. Unter /home/<User> gab es eine Datei raspiBackup.logr , aber die war leer

Ich habe jetzt versucht, das noch einmal nachzustellen.

Gleicher Ablauf wie vorher. Alles gut. Restore erolgreich.

Email "Trixie: Backup erfolgreich beendet"

Quote

--- RBK0009I: Trixie: raspiBackup.sh V0.7.2 - 2025-12-02 (c3fa944) Di 3. Mär 16:25:56 CET 2026 gestartet
--- RBK0031I: Prüfe ob eine neue Version von raspiBackup.sh verfügbar ist
--- RBK0151I: Backuppfad /backup mit Partitionstyp ext4 wird benutzt
--- RBK0081I: Backup vom Typ rsync wird in /backup/Trixie/Trixie@debian13-rsync-backup-20260303-162555 erstellt
--- RBK0044I: Backup der Bootpartition wird in /backup/Trixie/Trixie@debian13-rsync-backup-20260303-162555/Trixie-backup.img erstellt
--- RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte Geduld
--- RBK0078I: Backupzeit: 00:00:25
--- RBK0033I: Bitte warten bis aufgeräumt wurde
--- RBK0299I: Backupverzeichnis /backup/Trixie/Trixie@debian13-rsync-backup-20260303-162555 erstellt
--- RBK0159I: 10 Backups werden für den Backuptyp rsync aufbewahrt. Bitte Geduld
--- RBK0017I: Backup erfolgreich beendet
--- RBK0010I: Trixie: raspiBackup.sh V0.7.2 - 2025-12-02 (c3fa944) Di 3. Mär 16:26:34 CET 2026 beendet mit Returncode 0

Display More

Sehe ich das richtig, dass nach dem Restore automatisch ein neues Backup erstellt wird?

Quote

Code

drwxr-xr-x 20 root root 4096 22. Feb 05:01 Trixie@debian13-rsync-backup-20260222-050043
drwxr-xr-x 21 root root 4096  1. Mär 05:01 Trixie@debian13-rsync-backup-20260301-050043 #Sonntag morgen
drwxr-xr-x 21 root root 4096  3. Mär 16:26 Trixie@debian13-rsync-backup-20260303-162555 # direkt nach dem restore und Start des Systems automatisch erstellt

Ich habe das Backup nicht angestoßen. Ich habe das System nach dem Restore gestartet. Dann kam direkt nch ca 1 min. die Email und ein weiteres Backup war vorhanden.

 uptime
 16:46:39 up 20 min,  3 users,  load average: 0,26, 0,27, 0,26

16:26:39 gebootet, Letztes Backup von 16:26

Quote from framp

Ich kann mir nur vorstellen dass aus irgendwelchen Gründen der Timer dachte er muss ein Backup starten. Weil die Clock noch nicht stimmte?

Ist möglich, aber das war direkt nach dem Booten um 16:25

Beim ersten (nicht erfolgreichen Backup) war warscheinlich die Backup Partition noch nicht gemountet. Hat sich dann möglicherweise mit dem Timer überschnitten.

Normalerweise dürfte die Timer-Unit nicht zwischendurch ein Backup starten, es sei denn die Zeit ist noch nicht synchronisiert und die Zeit wurde aus dem Restore (Backup vom Sonntag) übernommen.

Quote from framp

Vielleicht verursacht das das Problem?

Das macht Sinn. Dann hat das System beim Booten noch das Datum von Sonntag um 5:01 und systemd startet ein Backup bevor die Zeit synchronisiert ist.

Das Backup wurde begonnen um 16:25:55 und beendet um 16:26:34

20260303-162555 DBG 2328:  --- Logfiles used: /tmp/raspiBackup.log and /tmp/raspiBackup.msg
20260303-162555 DBG 2339:  --- raspiBackup.sh 0.7.2, 2025-12-02/19:34:02 - c3fa944
-
-
-
-
20260303-162634 DBG 5648:  <-- cleanup
20260303-162634 DBG 5475:  --> unLockMe
20260303-162634 DBG 5477:  <-- unLockMe

Ich werde es gleich noch einmal mit einem anderen Backup testen. Ich werde eins manuell anstoßen und dann restoren.

So, Backup ist erstellt

Ich schreibe hier gleich weiter.

sudo raspiBackup
--- RBK0009I: Trixie: raspiBackup.sh V0.7.2 - 2025-12-02 (c3fa944) Di 3. Mär 17:26:34 CET 2026 gestartet
--- RBK0151I: Backuppfad /backup mit Partitionstyp ext4 wird benutzt
--- RBK0081I: Backup vom Typ rsync wird in /backup/Trixie/Trixie@debian13-rsync-backup-20260303-172634 erstellt
--- RBK0044I: Backup der Bootpartition wird in /backup/Trixie/Trixie@debian13-rsync-backup-20260303-172634/Trixie-backup.img erstellt
--- RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte Geduld
--- RBK0078I: Backupzeit: 00:00:16
--- RBK0033I: Bitte warten bis aufgeräumt wurde
--- RBK0299I: Backupverzeichnis /backup/Trixie/Trixie@debian13-rsync-backup-20260303-172634 erstellt
--- RBK0159I: 10 Backups werden für den Backuptyp rsync aufbewahrt. Bitte Geduld
--- RBK0017I: Backup erfolgreich beendet
--- RBK0010I: Trixie: raspiBackup.sh V0.7.2 - 2025-12-02 (c3fa944) Di 3. Mär 17:27:02 CET 2026 beendet mit Returncode 0
--- RBK0026I: Debug Logdatei wurde in /backup/Trixie/Trixie@debian13-rsync-backup-20260303-172634/raspiBackup.log gesichert

"Notfalldatenträger"

franjo@backup:~ $ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0     2G  0 loop
sda           8:0    0 465.8G  0 disk
├─sda1        8:1    0 221.6G  0 part
└─sda2        8:2    0 244.1G  0 part
sdb           8:16   0 111.8G  0 disk
├─sdb1        8:17   0   512M  0 part /boot/firmware
└─sdb2        8:18   0 111.3G  0 part /
zram0       254:0    0     2G  0 disk [SWAP]
nvme0n1     259:0    0 476.9G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part
└─nvme0n1p2 259:2    0 476.4G  0 part
franjo@backup:~ $ sudo mount /dev/sda1 /backup

Restore

franjo@backup:~ $ sudo raspiBackup -d /dev/nvme0n1 /backup/Trixie/Trixie@debian13-rsync-backup-20260303-172634
--- RBK0009I: backup: raspiBackup.sh V0.7.2 - 2026-01-08 (1dbd010) Tue  3 Mar 17:35:15 CET 2026 gestartet
--- RBK0031I: Prüfe ob eine neue Version von raspiBackup.sh verfügbar ist
!!! RBK0065W: Gerät /dev/nvme0n1 wird repartitioniert und die gesamten Daten werden gelöscht
--- RBK0066I: Gerät /dev/nvme0n1 wird überschrieben mit der gesicherten Boot- und Rootpartition
--- RBK0067I: Momentane Partitionen auf /dev/nvme0n1:
NAME          SIZE FSTYPE LABEL
nvme0n1     476.9G
├─nvme0n1p1   512M vfat   bootfs
└─nvme0n1p2 476.4G ext4
--- RBK0069I: Bootpartition /dev/nvme0n1p1 wird formatiert und erhält die zurückgespielte Bootpartition
--- RBK0070I: Rootpartition /dev/nvme0n1p2 wird formatiert und erhält die zurückgespielte Rootpartition
--- RBK0038I: Bist Du sicher? j/N
j
--- RBK0050I: Backup wird von /backup/Trixie/Trixie@debian13-rsync-backup-20260303-172634 zurückgespielt
!!! RBK0052W: Partitionen werden auf /dev/nvme0n1 erstellt
--- RBK0038I: Bist Du sicher? j/N
j
--- RBK0053I: Erste Partition (Bootpartition) wird auf /dev/nvme0n1p1 zurückgespielt
--- RBK0342I: Dateisystemcheck wird auf /dev/nvme0n1p1 durchgeführt
--- RBK0055I: Zweite Partition (Rootpartition) wird auf /dev/nvme0n1p2 zurückgespielt
--- RBK0342I: Dateisystemcheck wird auf /dev/nvme0n1p2 durchgeführt
--- RBK0319I: Neue UUIDs werden generiert
--- RBK0295I: /boot/firmware/cmdline.txt und /etc/fstab werden synchronisiert
--- RBK0340I: Restorezeit: 00:03:23
--- RBK0033I: Bitte warten bis aufgeräumt wurde
--- RBK0076I: Restore erfolgreich beendet
--- RBK0010I: Trixie: raspiBackup.sh V0.7.2 - 2026-01-08 (1dbd010) Tue  3 Mar 17:38:42 CET 2026 beendet mit Returncode 0
--- RBK0026I: Debug Logdatei wurde in /home/franjo/raspiBackup.logr gesichert

System neu gebootet

drwxr-xr-x 21 root root 4096  1. Mär 05:01 Trixie@debian13-rsync-backup-20260301-050043
drwxr-xr-x 21 root root 4096  3. Mär 16:26 Trixie@debian13-rsync-backup-20260303-162555
drwxr-xr-x 21 root root 4096  3. Mär 17:27 Trixie@debian13-rsync-backup-20260303-172634

Es wurde kein weiteres Backup automatisch erstellt.
Folglich kann es nur an dem automatischen Backup vom Sonntag liegen.

Ich habe #16 upgedatet

Quote from framp

ast Du verstanden warum Du den Effekt bekommen hast?

Meiner Meinung muss das mit dem .timer zusammenhängen. Den gibt es ja noch nicht seit 2017. Denn das passiert ja nur beim Restore eines automatischen Backups das von der timer-unit angestoßen wurde.

Das soll mir letztendlich auch keine schlaflosen Nächte bereiten, solange nur ein Backup erstellt und nicht gelöscht wird.