raspiBackup Release 0.7

Die Sicherung wurde und wird auch mit 0.7.0 auf der Backuppartition erstellt.

Anbei noch mal das Verzeichnislisting des Backupverzeichnisses und wo man sieht wo das tmp Verzeichnis während des Backups angelegt wurde:

pi@raspberrypi-bookworm64-desktop-cm4:/backup/raspberrypi-bookworm64-desktop-cm4 $ tree -L 2
.
├── raspberrypi-bookworm64-desktop-cm4-rsync-backup-20240312-224214
│   ├── backup
│   ├── bin -> usr/bin
│   ├── boot
│   ├── dev
│   ├── etc
│   ├── home
│   ├── initrd.img -> boot/initrd.img-6.1.0-rpi7-rpi-v8
│   ├── initrd.img.old -> boot/initrd.img-6.1.0-rpi7-rpi-2712
│   ├── lib -> usr/lib
│   ├── lost+found
│   ├── media
│   ├── mnt
│   ├── mntcmdline.txt.bak
│   ├── opt
│   ├── proc
│   ├── raspberrypi-bookworm64-desktop-cm4-backup.img
│   ├── raspberrypi-bookworm64-desktop-cm4-backup.mbr
│   ├── raspberrypi-bookworm64-desktop-cm4-backup.sfdisk
│   ├── raspiBackup.log
│   ├── raspiBackup.msg
│   ├── root
│   ├── run
│   ├── sbin -> usr/sbin
│   ├── srv
│   ├── sys
│   ├── tmp
│   ├── usr
│   ├── var
│   ├── vmlinuz -> boot/vmlinuz-6.1.0-rpi7-rpi-v8
│   └── vmlinuz.old -> boot/vmlinuz-6.1.0-rpi7-rpi-2712
└── tmp
    └── raspberrypi-bookworm64-desktop-cm4@debian12-rsync-backup-20250204-121721

66 directories, 30 files

Am Ende des Backuplaufes wird das tmp in raspberrypi-bookworm64-desktop-cm4@debian12-rsync-backup-20250204-121721 umbenannt.

Habe schon mal eine kurze Zusammenfassung erstellt was es Neues geben wird. YT Videos sind noch TBD.

Durch einen Beitrag hier im Forum ist mir zufällig eingefallen dass die neue Option -00 den Restore des kleinen Helperscripts raspiBackupAndClone.sh extrem beschleunigt da ein vollständiger Restore nicht mehr notwendig ist.

Ich habe das mal eben durchexerziert:

1) Initial ein partitionsorientierten Backup mit der Beata Release 0.7 auf einer lokal angeschlossenen USB HDD erstellt

2) Den Backup von der HDD restored auf eine Cold Backup SD Karte. Das ist ein Fullrestore.

3) Die Bootpartition auf der Cold Backup SD Karte gelöscht

4) raspiBackupAndClone aufgerufen

Zeiten:

1) Backup: 2 Sekunden (OK: Es hat sich inzwischen kaum was auf dem System geändert ... Im Normalfall wird es etwas länger dauern)

2) Restore auf Coldbackup SD Karte: 44 Sekunden (Restore der gelöschten Bootpartitionsdaten)

Die Option -00 war nicht deshalb eingeführt worden. An den Usecase hatte ich damals echt nicht gedacht. Aber für diejenigen die aus Verfügbarkeitsgründen einen Coldbackup haben möchten ist das mit dem neuen raspiBackup Release jetzt wesentlich schneller erledigt als bislang wo immer der gesamte Backup restored wurde und das natürlich dauerte.

raspiBackup Release 0.7 ist jetzt published

Bitte prüfe noch mal mit raspiBackup --version ob Du tatsächlich sie letzte Version hast. Es gab dummerweise ein paar Fehler an verschiedenen Stellen beim publish so dass kein Update erfolgte Ist jetzt aber alles gefixed.

Ok. Dann warst Du nicht schnell genug bzw ich schneller

Es gab jemanden der es unschön fand dass die alten Backups manuell gelöscht werden müssen und nicht bei raspiBackup 0.7.0 im Recycle berücksichtigt werden.

Daraufhin habe ich ihn darauf hingewiesen dass einfach die alten Backups nur das OS Release im Backuppfad enthalten müssen und dann sofort im Recycleprozess berücksichtigt werden.

Das hat mich dazu gebracht ein Script für mich zu schreiben welches das Renaming für rsync Backups bei mir vornimmt. Hat auch alles erfolgreich geklappt.

Ich weise aber darauf hin dass das Script für mich erfolgreich funktioniert hat aber ohne Support angeboten wird. Auch funktioniert es nicht bei dd oder tar Backups sowie bei Hostnamen die "-" enthalten.

Wer es nutzen will sollte unbedingt im dryrun (Aufruf ohne jede Option) checken ob die Dateinamen korrekt geändert werden und erst dann die Option -r nutzen um tatsächlich die Verzeichnisnamen anzupassen.

Man kann sicherlich das Script erweitern dass sowohl dd als auch tar Backups unterstützt werden. Wer Lust hat kann gerne einen PR erstellen.

Quote from framp

Auch funktioniert es nicht bei dd oder tar Backups sowie bei Hostnamen die "-" enthalten.

Da meine ganzen Testsystembackups Bindestriche enthalten habe ich das Script eben noch geändert dso ass auch Bindestriche im Hostnamen enthalten sein können.

Jetzt gibt es weitere Meldungen bzw Issues zu dem Fullbackup Thema beim neuen Release. Offensichtlich gibt es raspiBackup Nutzer die einen nicht nicht unerheblichen Datenumfang sichern der dann bei einem Fullbackup signifikant mehr als bei einem inkrementellen Backup wie z.B. einen halben Tag oder mehr

Das kann mit dem von mir geschriebenen Script verhindert werden. Ich habe eben mal auf reddit, Facebook, Twitter und im englischen Forum auf das Script hingewiesen.

Ich habe einen existierende Issue in dem ich denke dass eine Broadcastfunktion in raspiBackup sinnvoll wäre. Leider liegt der Issue im Backlog denn das wäre die beste Lösung wenn jeder Nutzer von raspiBackup < 0.7 auf dieses Script hingewiesen wird.

Eben habe ich die v0.7.0.2 published mit 4 kleinen Fixes. Nichts Schwerwiegendes

Beim Testen habe ich eine interessante Sache bemerkt und deshalb auch noch etwas fixen müssen:

Wenn man das Bookworm auf einer SD Karte installiert wird das systemd journal nicht persistiert (var/log/journal existiert nicht). Installiert man das Bookworm aber auf einer HDD/SSD wird das systemd journal persistiert. Offensichtlich wird da bei der Konfiguration des RaspbianOS unterschiedlich verfahren.

Das bereitet leider Probleme beim rsync Backup wenn die Backuppartition per nfs eingebunden ist da dort keine ACLs supported sind und die journals das sind . Dadurch habe ich rausgefunden dass der exclude von /var/log/journal bislang nicht funktioniert hat. Das ist aber jetzt mit 0.7.0.2 gefixed.

Vorhin wollte ich einen 0.6.9.1 Backup restoren und der bootete nicht weil das Backup nicht vollständig war . Genau darum habe ich in 0.7 eingeführt dass das Backup nicht direkt in das Backupverzeichznis geschrieben wird sondern erst in ein temp Verzeichnis und erst nach einem erfolgreichen Backup in das Backupverzeichnis gemoved wird.

Die Wahrscheinlichkeit dass das passiert ist gering - aber leider wie man sieht nicht gleich Null Deshalb empfehle ich doch auf 0.7 zu upgraden auch wenn die anderen Neuerungen nicht benötigt werden und dem never touch a running system Prinzip gefolgt wird.