.nobackup Datei erstellt sich automatisch

[pekae]

Hallo zusammen

Ich habe ein Problem mit dem automatischen Backup, das täglich um 0:00:07 erstellt wird.

Die Größe des Backup ist immer nur einige KB . Wenn ich nachschaue warum, liegt es daran, dass die Datei .nobackup vorhanden ist. Diese Datei wird NICHT von mir erstellt, sondern anscheinend automatisch vom System. Ich habe ein Programm erstellt, welches um 0:00:00 die Datei löscht. Trotzdem ist die Datei um 0:00:07 beim Backup wieder da und dadurch wird kein vollständiges Backup erstellt.
Wie kann ich verhindern, dass die .nobackup Datei automatisch wieder erstellt wird ?

[jens-maus]

Dann verrat uns mal welche settings du für das backup so eingestellt hast, d.h. Was da unter erweitere Einstellungen für das automatische Backup eingestellt ist und wohin du genau das Backup generieren lässt.

[pekae]

Das Problem hat auch nichts mit dem automatischen Backup zu tun - tritt dort halt nur in Erscheinung.
Es ist das generelle Problem, dass die .nobackup erzeugt wird. Anscheinend zwischen 0:00:00 und 0:00:07 Uhr

[jens-maus]

Dann geb mal folgende Befehle ein und zeig was die ausgeben:

cat /etc/config/CronBackupPath
realpath /mnt/usbstick
df -h

Und dann wäre auch noch die Frage wie genau du den usb stick unter /mnt/usbstick mounten lässt und warum überhaupt unter /mnt/usbstick? Denn ein angeschlossener usb stick sollte ja automatisch gemounted und auch unter dem richtigen verzeichnis das man schon gar nicht unter Erweiterte Einstellungen irgendetwas einstellen muss.

[pekae]

wie gesagt : bitte nicht am automatischen Backup festbeißen

das Problem fällt dort nur auf.
Das eigentliche Problem tritt auch beim normalen Backup auf. Hier lösche ich die .nobackup Datei immer vor dem Backup.

es hat nichts mit dem automatischen Backup zu tun .
Es kann daher meiner Meinung nach nicht am /mnt/usbstick liegen , da beim normalen Backup hier nicht zugegriffen wird.

das System liegt auf einer ssd und wird von ssd gebootet.

Wann wird die .nobackup erzeugt ? Was ist die Voraussetzung hierfür?

[jens-maus]

wie gesagt : bitte nicht am automatischen Backup festbeißen

Ich "beiß" mich hier an gar nichts fest. Ich weiss nur (weil ich es entwickle) wo diese .nobackup datei automatisch angelegt wird und das ist nunmal in den Routinen des automatischen Backup.

das Problem fällt dort nur auf. Das eigentliche Problem tritt auch beim normalen Backup auf. Hier lösche ich die .nobackup Datei immer vor dem Backup.

es hat nichts mit dem automatischen Backup zu tun . Es kann daher meiner Meinung nach nicht am /mnt/usbstick liegen , da beim normalen Backup hier nicht zugegriffen wird.

Nun, nicht direkt. Man sieht aber sehr gut an deinen Screenshots (bitte in zukunft diese Art der Handy-Screenshots nicht mehr posten, da bekommt man ja augenkrebs von...) das du hier prinzipiell etwas falsch machst.

das System liegt auf einer ssd und wird von ssd gebootet.

Das wird das problem bzw. deine falsche herangehensweise / annahme sein. Schau mal deine Ausgaben des df -h kommandos genauer an und du wirst sehen das /usr/local sowie /mnt/usbstick bei dir auf exaxt dem gleichen device node liegt, nämlich /dev/sda3. Ergo ist /mnt/usbstick und /usr/local bei dir im Grunde genau das gleiche. Und das erklärt eben warum diese .nobackup Datei in deinem /usr/local am schluss landet, eben weil die im der cronBackup.sh in dem konfigurierten backup verzeichnis angelegt wird – eben damit das backup nicht ein backup des backups des backups anlegt, usw..

Das geht also so nicht wie du dir das vorstellst bzw. wie du dir das da konfiguriert / zusammengebastelt hast. Das Backupdir (bei dir /mnt/usbstick darf eben nicht auf dem selben device gemounted sein wie /usr/local.

Ergo, das Problem liegt bei dir bzw. der Art wie du dein Setup da selbstständig zusammengebastelt hast.

[pekae]

Ok, das ist ne große Hilfe und vor allem DIE Erklärung!
Mir ist die .nobackup in /mnt/usbstick aufgefallen- aber ich bin nicht so tief in der Materie um das sofort zu verstehen.

Wüsste jetzt auch nicht, wie ich mein Mount ändern müsste - war froh, dass es irgendwie klappt

Ich wollte auch nicht verärgern, wenn ich da schreibe „festbeißen „
Klar, wenn nicht du, wer sonst sollte wissen wo was passiert.

sorry , mein Fehler!

Danke für die Hilfe, Mühe und verbratene Zeit

[Baxxy13]

Bei SSD-Boot Systemen ist das etwas "tricky".
Hier wird standardmäßig das Verzeichnis /usr/local/sdcard/ als "USB-Stick" genutzt.
Darin landen z.B. die Diagrammdaten und im Unterverzeichnis /usr/local/sdcard/backup/ eben die Backups.
Damit die Backupdateien nicht selbst wieder ins Backup gelangen wird eben die .nobackup in /usr/local/sdcard/backup/ erzeugt, außerdem wird die .nobackup auch in /usr/local/sdcard/ erzeugt.

Die Alternativer Speicherpfad - Option biegt einfach nur /usr/local/sdcard/ auf deinen eingetragenen Pfad um. Das mit der .nobackup bleibt gleich.

Was "am besten" für dich wäre ist schwer zu beantworten.

• Nutzt du die interne Diagrammfunktion nicht, keinen CCU-Historian oder sonstige Zusatzsoftware die normalerweise Daten auf den USB-Stick schreiben würde, dann würde ich Alternativer Speicherpfad nicht nutzen sondern nur den Backup-Speicherpfad auf den MountPoint setzen.

• Ansonsten Backup-Speicherpfad nicht nutzen, dafür eben Alternativer Speicherpfad auf den MountPoint setzen. Hier werden dann alle anfallenden Daten und auch die Backups im MountPoint abgelegt. Das bedingt aber ein dauerhaft verfügbares Netzlaufwerk und der Mount muss frühzeitig beim RM-Systemstart etabliert werden. (/usr/local/etc/rc.prelocal)

• Alternativ: zurück zum SD-Karten-Boot und statt eines USB-Sticks eben eine SSD anstecken.

[pekae]

HalloUnd danke für die freundliche AntwortIch muss mal schauen was ich tun kannHistorian etc nutze ich - daher erforderlich Dankeschön 🙏 Mit freundlichen GrußPeter KästnerAm 21.05.2024 um 08:42 schrieb Baxxy13 ***@***.***>: Bei SSD-Boot Systemen ist das etwas "tricky". Hier wird standardmäßig das Verzeichnis /usr/local/sdcard/ als "USB-Stick" genutzt. Darin landen z.B. die Diagrammdaten und im Unterverzeichnis /usr/local/sdcard/backup/ eben die Backups. Damit die Backupdateien nicht selbst wieder ins Backup gelangen wird eben die .nobackup in /usr/local/sdcard/backup/ erzeugt, außerdem wird die .nobackup auch in /usr/local/sdcard/ erzeugt. Die Alternativer Speicherpfad - Option biegt einfach nur /usr/local/sdcard/ auf deinen eingetragenen Pfad um. Das mit der .nobackup bleibt gleich. Was "am besten" für dich wäre ist schwer zu beantworten. Nutzt du die interne Diagrammfunktion nicht, keinen CCU-Historian oder sonstige Zusatzsoftware die normalerweise Daten auf den USB-Stick schreiben würde, dann würde ich Alternativer Speicherpfad nicht nutzen sondern nur den Backup-Speicherpfad auf den MountPoint setzen. Ansonsten Backup-Speicherpfad nicht nutzen, dafür eben Alternativer Speicherpfad auf den MountPoint setzen. Hier werden dann alle anfallenden Daten und auch die Backups im MountPoint abgelegt. Das bedingt aber ein dauerhaft verfügbares Netzlaufwerk. Alternativ: zurück zum SD-Karten-Boot und statt eines USB-Sticks eben eine SSD anstecken. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[pekae]

Wie man unschwer merkt, hab ich nicht die grooooße Ahnung
Hab vor 50 Jahren mal bisschen was mit Unix/mounten/etc zu tun gehabt.

Könnte ich nicht auf der ssd eine neue Partition erstellen und diese als sda4 mounten ?
Wie gesagt - lang ist’s her
Oder doch zurück zu sd-Kartenboot und ssd für die Daten (wie oben vorgeschlagen)
Daten schreiben auf sd schrottet diese halt alle paar Monate.
Danke für die Hilfe

[Baxxy13]

Könnte ich nicht auf der ssd eine neue Partition erstellen und diese als sda4 mounten ?

Man könnte. Das ist aber äußerst unpraktikabel speziell wenn das System mal flöten geht und du restoren musst.
Außerdem wäre das außerhalb der Norm und dir könnte im Problemfall quasi keiner helfen.

Ich hatte ja damals das USB-Boot-Feature vorangetrieben. Es funktioniert und das auch gut, macht aber m.E. nur Sinn wenn man mittels Alternativer Speicherpfad alle Nutzerdaten komplett auslagert.

Daten schreiben auf sd schrottet diese halt alle paar Monate.

Das kann ich nicht nachvollziehen. Regulär wir die SD-Karte schreibtechnisch kaum belastet. Einzig die lokale Datenbank (homematic.regadom) wird im laufenden Betrieb ggf. häufiger geschrieben. Dazu kommen bei jedem (Neu)Start ein paar kleine "Kontrolldateien".
Die Historian-DB und auch die Diagrammdaten der internen Diagrammfunktion setzen ein angeschlossenes USB-Speichermedium voraus.

Ich hatte 3 Jahre lang einen Pi4B (gebootet mit SD-Karte) am laufen. Für die Daten war eine USB-SATA-SSD (formatiert mit f2fs) am USB2-Port angeschlossen. Wenn ich nicht zu einem Mini-PC mit Proxmox gewechselt wäre würde das heute noch so laufen.

Das ist m.E. das "optimale" Setup. Die "Daten-SSD" hält ewig und RaspberryMatic auf der SD kann im Problemfall schnell neu aufgesetzt werden. (neue SD flashen, Backup einspielen... fertig)

[pekae]

Super
Danke, dann mach ich das so

Vielen lieben Dank nochmals