gemacht.
Diese Zip-Files liegen dann im Ordner userdate/Backups.
Wenn ich aber über gleiche Option ein Backup wieder einspielen möchte, tauchen die letzten Backups in der Auswahlliste nicht mehr auf.
Es werden nur 20 Backups angezeigt.
- Wie kann ich ggf. die max. Anzahl an Backups heraufsetzen?
- Wie kann ich in dem o.g. Ordner alte Backups löschen, um die Neueren wieder in der Auswahlliste zu haben?
Löschen kann ich nichts, weil die Rechte es nicht hergeben.
Danke.
VG.
Hausautomation zu 95% mit Siemens Logo! (5x 0BA8).
Gartenbewässerung, Rollosteuerung, Lichtsteuerung, etc.
Abfrage von Temperaturen, Helligkeit, Füllstand Zisterne Leistung Photovoltaik.
löschen.
Dahin komme ich aber nicht (no such file or directory).
Kann man nicht auch die Rechte für die Dateien/den Ordner Backups generell ändern, so dass ich diese auch im Windows Explorer oder via Win SCP löschen kann?
Führt das zu Problemen?
Falls das unkritisch ist, wie könnte man das machen?
Danke.
Hausautomation zu 95% mit Siemens Logo! (5x 0BA8).
Gartenbewässerung, Rollosteuerung, Lichtsteuerung, etc.
Abfrage von Temperaturen, Helligkeit, Füllstand Zisterne Leistung Photovoltaik.
löschen.
Dahin komme ich aber nicht (no such file or directory).
Der Ordner heißt /var/lib/openhab/backups/. openHAB-userdata ist ja nur ein Synonym, welches in Samba so definiert ist.
Galadriel13 hat geschrieben: ↑21. Mai 2021 22:47
Kann man nicht auch die Rechte für die Dateien/den Ordner Backups generell ändern, so dass ich diese auch im Windows Explorer oder via Win SCP löschen kann?
Nein, das ist keine Gute Idee.
Abgesehen davon, dass openHAB mindestens für neue Dateien die Rechte immer wieder so setzen wird, wie sie nun mal gesetzt sind, ist es auch Teil des Sicherheitskonzepts, welches Du damit unterlaufen würdest.
Es ist auch eine gute Idee, sich zumindest rudimentäre Kenntnisse in Linux drauf zu schaffen. Dazu gehören essenzielle Befehle zum Auffinden von Dateien (das wäre find) oder auch sudo um erweiterte Rechte zu erlangen.
Den Speicherort der openHAB Dateien verrät openHAB übrigens selbst, indem Du in der GNU/Linux-Konsole den Befehl
Besten Dank, das hat funktioniert.
Ich werde deinen Rat befolgen.
Schönes Wochenende.
Hausautomation zu 95% mit Siemens Logo! (5x 0BA8).
Gartenbewässerung, Rollosteuerung, Lichtsteuerung, etc.
Abfrage von Temperaturen, Helligkeit, Füllstand Zisterne Leistung Photovoltaik.
Bis jetzt habe ich meine Sicherung immer wie im ersten Post beschrieben über dd gemacht. Letzte Woche kam ich allerdings in schwitzen, da eine der beiden sd-Karten defekt war. Ich habe meine Backup Strategie überlegt und habe mich mit raspibackup beschäftigt.
Mount zur Synology einrichtet und läuft. Erstes Backup mit rsync ging in die Hose -> Problem mit ACL
Zweites Backup wieder mit dd -> Datei erstellt, wurde aber noch nicht getestet.
..nur Cron am laufen. Zusätzlich natürlich auch Openhab, was hier ja nicht aufgeführt ist (aber fhem, iobroker).
Und vom Gedankengang... Wenn ich wie in Post beschrieben ein dd Backup erstelle, werden ja auch keine Dienste im Vorfeld gestoppt. Wäre bei dd ja auch ziemlich Blöd aufgrund der Dauer...
Wie lösen die raspibackup-Nutzer das Problem (wenn es eins gibt )
Also, dd kopiert auf Geräteebene, das heißt, wenn, dann wird das gesamte Filesystem gesichert. Kann man machen. Man sollte aber schon verstehen, was da passiert. Da man das gesamte Filesystem kopiert, kopiert man z.B. auch den kompletten leeren Bereich mit. Man kopiert auch die Information mit, welche Dateien gerade geöffnet sind. Und dieser eine Punkt zeigt schon, warum dd mit äußerster Vorsicht zu genießen ist. Wenn man das aus dem System selbst heraus macht, sind zwingend einige Dateien geöffnet (schließlich läuft das System) und werden auch so mit abgespeichert. Der Sicherungsvorgang dauert durch die Größe des Dateisystems extrem lange, selbst bei optimierten Parametern.
Wenn man also eine solche Sicherung an den Start bringt, ist es fast zwingend, dass es zu Fehlern kommt. Wenn man das weiß, kann man natürlich entsprechende Maßnahmen ergreifen (z.B. die pid-Dateien von Hand löschen oder auch ein fsck laufen lassen).
Man kann auch alles, was möglich ist schließen und darauf vertrauen, dass schon nichts Schlimmes passieren wird. Allerdings sollte man die Sicherungskopie schon mal testen. Und da man dazu das laufende System eh anhalten muss, erschließt sich mir nicht, warum man die Sicherung überhaupt aus dem laufenden System heraus macht.
Unterm Strich: dd taugt eher für Dateisysteme, die man im laufenden Betrieb aushängen kann (umount).
openHAB kann man recht einfach sichern, indem man das mitgelieferte Tool nutzt: openhab-cli backup ist dazu da (und kann sogar Backups mit openhab-cli restore zurückspielen).
Um das gesamte System zu sichern, gibt es ebenfalls andere Möglichkeiten.
rsync ist eine nette Sache, allerdings macht das erst dann Spaß, wenn man auch einen entsprechenden Server laufen hat, der die Sicherungen automatisch entgegen nimmt oder (noch besser) die Sicherung remote vornimmt. rsnapshot wäre hier das passende Stichwort. Auf dem Server läuft das Script, welches automatisch ein diff aller zu sichernden Verzeichnisse auf dem Remote host macht. Auf dem Remote Host muss dazu lediglich rsync installiert und als Dienst eingerichtet sein. rsnapshot legt einstellbar diverse Kopien an, die über das Filesystem alle als (virtuell) vollständiges Backup angesprochen werden können. Real werden aber nur dann Dateien gespeichert (und verbrauchen Platz) wenn sie geändert wurden. Man kann jederzeit eine Version von vor 10 Minuten, 3 Stunden 6 Tagen, 5 Wochen oder 3 Monaten wiederherstellen (vorausgesetzt, man hat das Backup entsprechend konfiguriert, natürlich), da geht so, dass eben verschiedene Stufen definiert werden (frequently, hourly, daily, weekly, monthly) und für jede der Stufen eine Anzahl x vergegeben wird, wieviele Kopien dieser Stufe aufbewahrt werden sollen. Es stehen dann z.B. die letzten 4 frequently, die letzten 24 hourly, die letzten 7 daily, die letzten 5 weekly und die letzten 7 monthly zur Verfügung. Solange sich Dateien nicht ändern, belegen sie aber nur einmal den Platz im Filesystem (und natürlich entsprechend in der Verwaltung des Dateisystems 47 mal, da es sich um 47 Hardlinks auf eine Datei handelt).
Um das System in erträglicher Zeit wieder zum Laufen zu bringen, reicht es, die Dateien in $OPENHAB_USERDATA und $OPENHAB_CONF zu sichern (man kann mittels openhab-cli info auch anzeigen lassen, welche Pfade openHAB in der eigenen Installation nutzt).
Mit dieser überschaubaren Menge an Daten setzt man das System mittels aktuellem Image neu auf, spielt die Daten zurück und das System läuft wieder.
Von dieser Sicherung ausgenommen ist natürlich Software von Drittherstellern, z.B. mosquitto oder influx/grafana. Auch die persistierten Daten sind dann weg bzw. (soweit unter userdata abgelegt) inaktuell. Aber das Probelm mit den fehlenden Daten hat man auch mit jeder anderen Sicherungsmethode, denn wer hat bitteschön ständig ein aktuelles Vollbackup laufen (wäre schlecht für die Performance und die Datenträger)?
Da Du eine Synology hast, schau mal, ob Du dort einen rsync Server eingerichtet bekommst (ich meine, die bietet das von Haus aus). Oder um noch weiter vorne zu beginnen: Wie potent ist Dein Modell? Kann es eventuell sogar mit Docker umgehen?
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
Backbe01 hat geschrieben: ↑25. Mai 2021 09:10
Wie lösen die raspibackup-Nutzer das Problem (wenn es eins gibt )
Als ich noch einen RPi für openHAB genutzt habe wurde von mir ein tar Backup genutzt und kein einziger Dienst gestoppt.
Sowohl ein paar Test-Restore als auch zwei scharfe Restore Vorgänge haben immer zum Erfolg geführt.
Heute nutze ich noch RPi's um Sensoren auszulesen und als VPN Server, diese werden weiterhin mit raspiBackup gesichert, auch weiterhin mit tar Backups und auch weiterhin ohne irgendwelche Dienste zu stoppen: alles völlig unproblematisch, auch bei einem notwendigen Restore (musste den beim VPN Server schon einmal nutzen).
openHAB3 mit Zwave, Alexa, ESPEasy, MQTT, Logitech Harmony, Philips HUE und ZigBee Hardware auf Proxmox VE.
@udo1toni Ich stimme Dir voll und ganz zu: Ein dd Backup ist aus verschiedenen Gruenden die ungeeignetste Backup Methode und rsync die geeignetste Methode - sofern man ein Linuxdateisystem ext3 oder 4 nutzen kann und somit den Vorteil der Hardlinks nutzen kann. Vornehmlich Windowsnutzer nutzen leider die dd Backupmethode da dd Backups mit Windowstools einfach restored werden koennen .
Nur die OpenHAB Configdaten und Datenbank zu sichern geht sicherlich am schnellsten. Wenn man dann aber im Disasterrecoveryfall erst ein neues OS, dann OpenHAB neu installieren muss und final die OpenHAB Configs wie Daten wieder einspielt dauert das aber eine Weile. Wenn man aber das ganze System gesichert hat geht der Restore wesentlich schneller.
Ich nutze kein openHAB - habe aber verschiedene Raspis im Einsatz und sichere sie regelmaessig mit raspiBackup im laufenden Betrieb. Vorher stoppe ich Services die Datenbanken nutzen um 100% sicher zu sein keinen inkonsistenten Stand zu sichern. Damit fahre ich sehr gut und habe seit Existenz von raspiBackup (2013) damit um die 15 Mal erfolgreich einen Restore der Systeme im Disasterrecoveryfall vorgenommen und konnte so jeweils nach ca 15 Minuten wieder meine Server hochfahren.
PS: raspiBackup bietet seit der Version 0.6.5 auch eine intelligente Rotationsstrategie an die der von Dir erwaehnten Großvater-Vater-Sohn Backupstrategie entspricht
"Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." Linus Benedict Torvalds, 28.9.2003
framp hat geschrieben: ↑25. Mai 2021 19:41
@udo1toni Ich stimme Dir voll und ganz zu: Ein dd Backup ist aus verschiedenen Gruenden die ungeeignetste Backup Methode und rsync die geeignetste Methode - sofern man ein Linuxdateisystem ext3 oder 4 nutzen kann und somit den Vorteil der Hardlinks nutzen kann. Vornehmlich Windowsnutzer nutzen leider die dd Backupmethode da dd Backups mit Windowstools einfach restored werden koennen .
Wobei man Hardlinks auch in ntfs nutzen kann - mir wäre allerdings kein Tool wie rsnapshot für Windows bekannt, schon gar nicht so, dass es von GNU/Linux Dateisystemen liest und in Richtung Windows ntfs repliziert. Man könnte allerdings das Linux Subsystem nutzen
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
)
. 