Backup einspielen bei .ova oder USB-Boot Systemen "problematisch"

[Baxxy13]

Da es sich bei meinem Thema m.E. eher nicht um einen Bug handelt würde ich das gerne erstmal besprechen.

Worum gehts?:
Weil ich irgendwas zerlegt hatte musste ich heute auf meinem Pi4B (USB-Boot) das System mit dem letzten Backup restoren.
Lief sauber durch, aber anschließend waren alle meine Nutzerdaten (Logs, Hisorian-DB, Historian-DB-Backups) weg.
Die Sachen lagen in Verzeichnissen (Beispiel: /usr/local/Historian-DB/) welche mit der .nobackup versehen waren. Einfach damit nicht jeden Nacht "riesen" Backups erstellt werden.

Das Dilemma:
Durch die .nobackup waren die Sachen korrekterweise nicht Bestandteil des Backups. Dummerweise werden aber beim restoren die Verzeichnisse (inklusive .nobackup) neu angelegt / überschrieben und somit alle Inhalte gelöscht.

Fragen:

• Wie kann ich das zukünftig "umgehen" das Verzeichnisse innerhalb /usr die mit der .nobackup versehen sind beim Restore gelöscht/überschrieben werden.
• Kann das restore-Script dahingehend angepasst werden das vorhandene Daten nicht überschrieben werden?

Gedanken:
Ich möchte ungern wieder einen USB-Stick anstöpseln um die Problematik zu umgehen.
Das "full-Backup" extern wegzusichern wäre eine Option, momentan habe ich aber kein NAS und die alte Fritte ist da ziemlich lahm. Außerdem weiß ich nicht ob der Historian das mag wenn (möglicherweise) mitten im Schreibvorgang die DB weggesichert wird. (geht vermutlich aber was ist nach dem Restore?)

[Baxxy13]

Der "Ärger" ist noch nicht wirklich verflogen...

Durch das Einspielen des Backups habe ich...

• eine ca. 1GB große Historian-DB mit Daten von 2 Jahren verloren (effektiv 2 Wochen an Daten da ich letztens die DB extern weggesichert hatte)
• alle Historian Datenbank-Backups verloren
• 29 von 30 Systembackups verloren (das letzte hatte ich runtergezogen um damit den Restore zu machen)
• alle devlog-Files für CUxD-Highcharts mit Daten von 2 Jahren verloren
• alle WebUI-Diagrammdaten verloren (keine Ahnung für welchen Zeitraum)
• mehrere MB an LogFiles und sonstigen Daten verloren

Das kann doch so nicht gewollt sein!

Ich würde mir wünschen das das Restore-Script hier behutsamer vorgeht und vorhandene Verzeichnisse (auf dem physischen Medium) nicht einfach mit dem leeren Verzeichnis (aus dem Backup) überschreibt wenn noch Daten im Verzeichnis (auf dem physischen Medium) vorhanden sind.

Vielleicht ließe sich das mit einer zusätzlichen "Kontrolldatei" .nobackupoverride realisieren. Das Restore-Script prüft die Verzeichnisse (auf dem physischen Medium) auf Vorhandensein derselben und überspringt dann den Restore des Verzeichnisses.

[jens-maus]

Das kann doch so nicht gewollt sein!

Doch, genau so ist das aber vom design her. Das Backup via WebUI oder createBackup.sh bzw. cronBackup.sh übergeht eben alle .nobackup Verzeichnisse, da es ansonsten zu einem mehrere GB großem Backup kommen würde das man mitunter nicht mehr herunterladen könnte. Das ist genau die Motivation dieses .nobackup. Folglich müssen die Drittanbieter-Addons wie Historian, etc. eigene Backuproutinen zur Verfügung stellen die es erlauben die Addon-Eigenen Daten persistent herunterladen zu können. Du hattest es ja schon gesagt: Selbst wenn man di .nobackup verzeichnisse mit backupen lassen würde, das würde dazu führen das dann die Historian-DB mitunter in einem nicht-konsistenten Status gebackupt wird und dann am schluss auch defekt ist. Hier muss Historian selbst eine Backup-Funktionalität anbieten damit man die Daten persistent herunterladen kann.

Ich würde mir wünschen das das Restore-Script hier behutsamer vorgeht und vorhandene Verzeichnisse (auf dem physischen Medium) nicht einfach mit dem leeren Verzeichnis (aus dem Backup) überschreibt wenn noch Daten im Verzeichnis (auf dem physischen Medium) vorhanden sind.

Da Backup-Restore wird aber nicht von irgendeinem einfachen Skript gesteuert. Das Restore eines Backups läuft beim rebooten ab. D.h. findet er eine backupdatei an ort&Stelle dann löscht er im grunde die gesamte /usr/local partition, und spiel die Daten entschend zurück.

Vielleicht ließe sich das mit einer zusätzlichen "Kontrolldatei" .nobackupoverride realisieren. Das Restore-Script prüft die Verzeichnisse (auf dem physischen Medium) auf Vorhandensein derselben und überspringt dann den Restore des Verzeichnisses.

Das wird früher oder später nur zu inkonsistenzen führen. Ein Backup restore ist eben ein backup restore und MUSS zwangsläufig exakt den Stand 1:1 aus dem Backup wiederherstellen und nicht irgendein "merge" machen.

Einzige Option die ich sehe ist, zusätzlich zu einem normalen Backup den command-line skript createBackup.sh vielleicht dahingehend zu erweitern, das er trotzdem die .nobackup verzeichnisse mit backupt. D.h. ein FULL Backup quasi mit allen Konsequenzen (d.h. inkonsistentes Datenbankbackup von Historian, usw. Backup von /usr/local/tmp mit Firmareupdate dateien und backups von backups, etc.) durchführt und dann ggf. dieses monster-GB-große FullBackup irgendwo ablegt. Im Grunde kommt das dann aber "nur" einem kompletten Image der /usr/local (userfs) Partition gleich.

[Baxxy13]

Hi Jens...

D.h. findet er eine backupdatei an ort&Stelle dann löscht er im grunde die gesamte /usr/local partition, und spiel die Daten entschend zurück.

Das war die Info die mir fehlte. Damit ist ist mein "Ergebnis" natürlich klar. Ist natürlich richtig so, nur habe ich das so nicht "erwartet".

D.h. ein FULL Backup quasi mit allen Konsequenzen (d.h. inkonsistentes Datenbankbackup von Historian, usw. Backup von /usr/local/tmp mit Firmareupdate dateien und backups von backups, etc.) durchführt und dann ggf. dieses monster-GB-große FullBackup irgendwo ablegt.

Das habe ich tatsächlich schon so implementiert. Um eine Inkonsitenz der DB zu vermeiden wird der Historian per Monit gestoppt und dann 30s später alles gebackupped. Das Problem... Das FULL-Backup liegt auch unter /usr/local/sdcard und ist mit .nobackup versehen. Das war kontraproduktiv wie sich nun herausstellte. ;-)

Einzige Option

Naja, ich teste gerade die Fritte als Backupgerät aus. Ist jetzt nicht das aktuellste Modell, aber mal sehen.
Die zweite Sache die ich teste wird dir nicht so gefallen...
Habe die /userfs - Partition der SSD verkleinert und eine zusätzliche primäre f2FS-Partition erzeugt.
Die mounte ich über die /usr/local/etc/rc.local mit mount /dev/sda4 /media/usb6
Das funktioniert erstmal.
Nun möchte ich /usr/local/etc/config/CustomStoragePath mit dem Eintrag /media/usb6 nutzen aber das läuft nicht.

Wie es scheint erfolgt der Mount über die rc.local zu spät.
Die WebUI sagt zwar "externer USB-Speicher vorhanden"... Klicke ich dann auf "Daten sichern" meint der Browser kurz "Die RaspberryMatic ist noch nicht bereit". Die WebUI kommt dann wieder hoch, ein Backup wird aber nicht angelegt.

Ich werde das mal in #914 detaillierter beschreiben.

Grüße
Baxxy

[Baxxy13]

Ich habe mich jetzt vorerst für eine weitere Partition auf der SSD (sda4 mit f2FS) entschieden.

• sda4 wird mittels /usr/local/etc/rc.postinit und dem Eintrag mount /dev/sda4 /media/usb1 quasi als USB-Speichermedium gemounted.
• Dazu noch die /usr/local/etc/config/CustomStoragePath mit dem Eintrag /media/usb1 angelegt.
• Die Speicherpfade im CCU-Historian und CUxD auf /media/usb1/xxx/ geändert.
• Das läuft soweit.
• Etwas tricksen musste ich um die Speicherbelegung von /usb1 in der Monit-Übersicht zu sehen (ggf. auch für USB1 Speicherplatz-Alarme). Hierzu habe ich in der /usr/local/etc/rc.local den Eintrag: touch /var/status/hasUSB angelegt.

Durch das Auslagern aller meiner Nutzerdaten auf sda4 bleibe ich in Zukunft hoffentlich vom Kahlschlag eines Backup-Restores verschont. ;-)