Plugin: LoxBerry Backup

[TomekWaw]

I receive backup errors every other day

tar: /var/lib/docker/overlay2/181746ed041b0e4fc12675264fdc6f34304b36ceffba733e2b 4c1f1bb208c640/diff/tmp/.X11-unix/X0: socket ignored
tar: /var/lib/docker/overlay2/181746ed041b0e4fc12675264fdc6f34304b36ceffba733e2b 4c1f1bb208c640/diff/tmp/ns.root.\:0/wmii: socket ignored
tar: /var/lib/docker/containers/5591c167b344cec3dd713ecf651503e7ea22b4f542018f07ba 589ce0db7256c3/5591c167b344cec3dd713ecf651503e7ea22b4f542018f07ba 589ce0db7256c3-json.log: file changed as we read it
tar: /var/agentx/master: socket ignored
??? RBK0021E: Backupprogram for type tgz failed with RC 1.
--- RBK0033I: Please wait until cleanup has finished.
--- RBK0043I: Removing incomplete backup in /media/smb/192.168.103.2/home/backup/loxberry/loxberry-tgz-backup-20210124-060004. This may take some time. Please be patient.
--- RBK0049I: Messages saved in current.msg.
--- RBK0026I: Debug logfile saved in current.
--- RBK0010I: loxberry: raspiBackup.sh V0.6.6-beta (a35949f) stopped at Sun 24 Jan 06:32:46 CET 2021 with rc 109.
??? RBK0005E: Backup failed. Check previous error messages for details.

Script done on 2021-01-24 06:32:48+01:00 [COMMAND_EXIT_CODE="109"]
ERROR: Backup failed with error code 109
24.01.2021 06:32:52 TASK FINISHED

Is this log file change a reason to this?
What can I do about it?

[jschoens]

Habe ein kleines Problem mit der Wiederherstellung des Backups (4GB-Karte) auf einer 32GB-Karte.
Der Loxberry ist immer noch der Meinung, dass er eine 4GB-Karte benutzt,
Hinweis beim Selbsttest: / is below limit of 5% discspace,
obwohl er genügend Speicherplatz zur Verfügung hätte.

Konnte wegen dem geringen Speicherplatz auf der 4GB-Karte schon keine Updates mehr installieren, deswegen der Weg über eine Größere.
Ebenso möchte ich wegen den komplexen Einstellungen auf FHEM und Text2SIP das System nicht neu aufsetzen.

Wie kann ich mit dem bestehenden Image (4GB) den Speicherplatz erweitern.

Ich hoffe Ihr könnt mir helfen.

Viele Grüße Jürgen

[framp]

Offensichtlich benutzt Du den dd Backuptyp. Wenn Du den tar oder rsync Backuptyp benutzt wird automatisch von raspiBackup die zweite Partition (root Partition) bei einem Restore auf ihr Maximum expandiert und es ist kein resize_rootfs notwendig ;-)

[Christian Fenzl]

Mit putty anmelden und zu root machen (siehe Wiki)

/opt/loxberry/sbin/resize_rootfs

Dann das tun, was dort steht.

[framp]

file changed as we read it

That's the root cause for RC1 from tar. As far as I can see this file is managed by a docker container. Stop docker before you start the backup and start it again when the backup finished. See FAQ18 for details.

[Peter_Aschenberger]

That's the root cause for RC1 from tar. As far as I can see this file is managed by a docker container. Stop docker before you start the backup and start it again when the backup finished. See FAQ18 for details.

Wenn man sich diese Liste anschaut, dann werden einige Dienste ja von Loxberry auch benutzt (zumindest Samba & Apache) Werden diese dann von LB-Backup standardmäßig deaktiviert?

[Christian Fenzl]

Das Bsckup-Plugin dreht selbst nichts ab, aber du kannst im Plugin Services definieren, die abgedreht werden sollen.
Ich nehme es jedenfalls nicht auf meine Kappe, beim Backup etwas abzudrehen, was für den Betrieb notwendig ist.

[framp]

Sehe ich genauso. Ein jeder muss selbst entscheiden ob Service gestoppt werden sollen oder nicht. Das hat Vor-aber auch Nachteile. Es gab schon Requests dass raspiBackup automatisch alle wichtigen Services stoppt. Das wird nie passieren.

[Peter_Aschenberger]

Alles gut. Ich wollte nur fragen, damit ich sicher bin.
Danke

[fs79]

Hallo,
ich stoppe beim Backup den collectd weil der immer Logfiles während des Backups schreibt und dann das Backup fehlschlägt weil sich Dateien geändert haben.
Das funktioniert soweit auch.

Jetzt habe ich das FHEM Plugin installiert, da es kein Dienst ist und ich den nicht stoppen kann.
Wie kann ich denn im Plugin Loxberry Dienste, die nicht als service im Linux sind, vorher stoppen?

[Christian Fenzl]

FHEM ist ein Dienst.
Einfach unten fhem reinschreiben.

[fs79]

root@loxb01:~# service fhem status
Unit fhem.service could not be found.
root@loxb01:~#

Sicher?
Finde es nicht als Service.

[framp]

Gemaess FAQ18 sollte es mit

systemctl stop fhem

funktionieren.

[fs79]

Das habe ich gar nicht probiert.
Probier ich mal aus.
Dank dir.

[Christian Fenzl]

Es gehört im Plugin nur "fhem" rein, wie ich das auch schon geschrieben habe.
Das systemctl... macht das Plugin selbst.

Ich frage mich manchmal, warum ich überhaupt noch antworte, wenn eh niemand tut, was man empfiehlt, bzw. dauernd Rückfragen kommen, ob das wirklich so gehört, statt es EINFACH ZU PROBIEREN. wie empfohlen.

[Christian Fenzl]

BTW Den service-Command gibt's bei Debian seit 5 Jahren nicht mehr, der wird nicht verwendet zum Services verwalten.

[fs79]

Christian Fenzl
Heute ist so ein schöner Sonntag. Wir hatten einen sonnigen Tag und hoffe dein Sonntag war auch schön. Ich wollte dich nicht ärgern.

Ich möchte es nur verstehen weil auch systemctl nicht mit fhem funktioniert.
Ich habe das FHEM Plugin im Loxberry installiert. Weder habe ich eine unit dafür gefunden, noch sonst irgendetwas.
Hätte ich vielleicht auch alles dazu schreiben sollen. ;-)

root@loxb01:~# systemctl status fhem
Unit fhem.service could not be found.
root@loxb01:~# systemctl start fhem
Failed to start fhem.service: Unit fhem.service not found.
root@loxb01:~# systemctl stop fhem
Failed to stop fhem.service: Unit fhem.service not loaded.
root@loxb01:~#

Hab den FHEM jetzt hier entdeckt, nachdem ich mir die Webinterface Datei dazu angeschaut habe.

root@loxb01:~# ls /opt/loxberry/system/daemons/plugins/fhem
/opt/loxberry/system/daemons/plugins/fhem

Und wenn ich mir das Backupskript anschaue, dann macht versucht der es mit systemctl

if ($service) {
$par_stopservices .= "systemctl stop $service && ";
$par_startservices .= "systemctl start $service && ";
}

Kann ich, trotz dieser Findings, da jetzt einfach "fhem" eintragen?
Ich hoffe das es für dich jetzt etwas runder ist und erklärt warum ich nachfrage.


P.S.Dank dir für den "service" Hinweis. Wollte gerade schauen, wo mein Wissen da stehen geblieben ist.

[Christian Fenzl]

Ja, es war ein schöner Sonntag, nur bissl stressig 😉

Du musst eine alte Version von FHEM haben, weil in Michaels Repo der aktuellen Version wird FHEM per apt installiert, und einen LoxBerry Daemon-Script gibt es gar nicht mehr. Das bei dir kann aber auch "Legacy" sein, ich kann mich erinnern, dass es bei der Umstellung des Plugins irgendwas gab, was Michael dazu geschrieben hatte.

Du bekommst somit FHEM über das Plugin nicht down.

Da möchte ich denn Ball doch eher an framp zurück geben, und nachfragen, ob es nötig ist, beim TAR-Backup geänderte Dateien tatsächlich als Fehler statt nur als Warnung zu interpretieren.
Im Prinzip kann ich viele Dienste nicht einfach für mehrere Stunden abdrehen (FHEM ist eine Smarthome-Software, aber gleiches würde auch für Datenbanken aller Art gelten, oder Docker-Container, die weiß Gott was betreiben).
Selbst wenn ich als Benutzer Vorkehrungen treffe (z. B. eine Datenbank vorab per Datenbank-Script sichere, also schon konsistent bin), komme ich ohne Beenden dieser Dienste nicht zu einem (wenn auch nicht 100% konsistenten) Backup.

Wenn du framp die Art des Fehlers "Dateien haben sich geändert" von TAR eindeutig identifizieren kannst, würde ich das als Warnung und nicht als Fehler sehen. Drei inkonsistente Files sind besser als gar kein Backup.

lg, Christian

[fs79]

Dank Dir.
FHEM ist bei mir mittlerweile nicht mehr ganz so wichtig und kann auch mal ein Wartungsfenster vertragen. Ich schaue mir das auf jeden Fall mal an und aktualisiere da, um auf den aktuellen Stand zu kommen.
Die Idee mit den geänderten Files framp wäre natürlich perfekt, sind ja nur Logdateien.
Habe ich beim collectd und bei fhem.

[framp]

Da möchte ich denn Ball doch eher an framp zurück geben, und nachfragen, ob es nötig ist, beim TAR-Backup geänderte Dateien tatsächlich als Fehler statt nur als Warnung zu interpretieren.

Die Diskussion gab es schon mal direkt zur Anfangszeit von raspiBackup. Das Problem ist dass tar nur einen RC 1 zurueckliefert der verschiedene Ursachen haben kann. Ich koennte jetzt tar immer mit Option -v starten und dann das Log durchsuchen nach Dateien die die Ursache sind fuer einen RC1. Ich kann aber programmatisch nicht entscheiden welche Dateien unproblematisch sind und welche problematisch. Das kann nur der Benutzer. Damals wollten Benutzer aber den RC 1 ignorieren und es gibt Code in raspiBackup der das immer noch erlaubt. Dasselbe Problem gibt es bei rsync und RC 23. Ich habe dann irgendwann den offiziellen Support dafuer rausgenommen da es in meinen Augen unverantwortlich ist. Denn es kann sein dass zum Zeitpunkt t man im Log sieht es sind nur Logdateien. Das System aendert sich aber und zum Zeitpunkt t+1 kommt eine wichtige Datei dazu die sich auch aendert. Man bekommt aber keine Indikation mehr dass der Backup nun inkonsistent sein koennte da alle RC1 ignoriert werden.

Wenn trotz des Risikos jemand den RC1 bei tar ignorieren will kann ich beschreiben wie das geht. Ich rate aber dringend davon ab.

Die korrekte Art und Weise auf solche Fehler zu reagieren ist die Excludeoption von raspiBackup fuer tar zu benutzen. Dann bekommt man immer mit wenn ploetzlich durch Systemaenderungen sich neue Dateien beim Backup aendern. Ich glaube aber kaum dass Christian Fenzl sich den Schuh anzieht das im Plugin zu konfigurieren

[Christian Fenzl]

framp

tar gibt eigentlich lt. man-Page RC 1 nur zurück, wenn sich während des Backups ein File geändert hat (sonst immer RC 2), und auch nur deshalb, weil du offenbar explizit das Compare bei tar mit --compare/--diff/-d anforderst.
Das heißt, es läuft in den Fehler, den du mit dem Aufruf selbst verursachst.

Für mich ist das unlogisch - selbstverständlich kann sich bei einem Backup, das drei Stunden läuft, ein File ändern. Dieses (wichtige?) File auszuschließen wäre ja noch unlogischer. Und das Backup deswegen komplett wegzuwerfen, statt einen zwei Stunden alten Stand (statt des eine Stunde alten Standes) dieser Datei zu sichern, erscheint mir auch unlogisch.

Das Verhalten von raspiBackup bei tar mit geänderten Files widerspricht jedenfalls jeder Logik und gängiger Praxis. Da könnten wir keinen Server mehr betreiben, wenn renommierte Serversoftware wie TSM, Backup Exec, Arcserve,... bei einer Dateiänderung während des Backups das komplette Backup wegwirft.
Bei DD können sich während des Backups ebenfalls Dateien ändern, trotzdem bleibt das Backup erhalten.

Wenn man das Compare abschalten kann (oder das nur als Warnung ins Log kommt) , würde ich das auch sofort als Default in LB Backup übernehmen. Wir LoxBerryaner betreiben Smarthomes, da können wir nicht für ein paar Stunden "das Haus abdrehen". Da wir die Logs in einer Ramdisk haben, kommt tar nie bei den Logfiles vorbei - sonst würde mit tar überhaupt kein Backup durchlaufen?

Dieser Abbruch von tar wäre wirklich zu hinterfragen, was man damit gewinnt (User weiß über geänderte Files während des Backups, ggf. Fehler des Zieldatenträgers) und damit verliert (das Backup selbst, die Möglichkeit überhaupt Backups zu machen).


lg, Christian
PS: Ich bin nicht betroffen, ich verwende DDZ 😉

[fs79]

Vielen Dank nochmals für den Hinweis. Wahnsinn an was du dich alles, sogar bei einzelnen Plugins erinnerst.
Hab jetzt das FHEM Plugin aktualisiert und meine Daten in FHEM, durch den neuen Ort, angepasst.
Läuft wieder und ich habe jetzt einen Dienst den ich per "systemctl" starten und stoppen kann.

Warum dieses FHEM Update nicht von loxberry angeboten wurde, bleibt wohl ein Geheimnis.
Ich war auf ein V0.4.x und habe den Upgrade auf die 0.6.x verschlafen.

[fs79]

Eine "exclude" per Loxberry Backup Webinterface wäre natürlich auch nicht schlecht.
Bei meinem FHEM nehme ich dann das das Logfolder raus, alles andere sichere ich trotzdem.
Auch das Backup Folder von FHEM, dann fehlen mir im Notfall zwar die letzten Logs, die Konfiguration ist aber gesichert.

Mein wichtigster FHEM Dienst sind einige Loggings von Loxone, zur Speicherentlastung vom Miniserver, Hausgeräteüberwachung (Bosch & Miele) und die Interaktion mit meiner Harmony Remote. Das Backup läuft Sonntag nachts wo niemand diese Dinge wirklich braucht, wenn FHEM aber weiter laufen könnte wäre das aber schon supi. ;-)

[Christian Fenzl]

Naja, wir bauen den LoxBerry-Core. Wir reden auch abseits des Loxforums 😉

Es kommt jetzt ein größerer Release des MQTT Gateways, dann hat Michael was Nettes in der Queue, wo ich auch bisschen was einbauen darf, und dann gibt's wieder eine Runde durch alle meine Plugins, wo auch LBBackup wieder mal ein "großes Service" bekommt. framp hat nämlich auch ein cooles neues Feature, die Retention, die mal ins Plugin kommen soll.

[framp]

Christian Fenzl Ein laufendes System zu sichern ist immer mit einem gewissen Risiko verbunden - egal ob dd, tar oder rsync genommen wird. Es gibt Admins denen rollen sich die Fussnaegel hoch wenn sie das lesen. Normalerweise nimmt man dafuer die Backuptools die die jeweiligen Applikationen zur Verfuegung stellen (e.g. mySQL). Die sorgen dann dafuer dass auch alle wichtigen Inmemoryinformationen gesichert werden und kein inkonsistentes Backup entsteht. Der VMWare ESX Server z.B. kann laufende Systeme zuverlaessig sichern denn da kann man angeben dass auch der Memory gesichert und wieder restored wird. Selbst da kann es Situationen geben wo der Restore Probleme macht wenn sich externe Stati (z.B. Netzinformationen) geaendert haben.

Darum bricht raspiBackup ab wann immer es Updates waehrend des Backups gibt um damit zu signalisieren dass es dort ein moegliches Problem geben kann. dd hat die Faehhigkeit Aenderungen zu entdecken nicht und sollte eigentlich nicht mehr von raspiBackup angeboten werden aber dann werde ich sicherlich gesteinigt Siehe auch hier wo ich die dd Problematik detailierter beschrieben habe. Der saubere Weg ist die sich aendernden Dateien in einer Excludeliste zu fuehren.

Eine Alternative waere btrfs und Snapshots zu benutzen. Aber auch da hat man das Problem dass u.U. wichtige Inmemoryinformationen nicht gesichert werden. Solange das aber nicht offiziell von der Raspberry Foundation unterstuetzt wird baue ich den Support dafuer nicht in raspiBackup ein.

Es gibt verschiedene Nutzer die stoppen keine Services weil ihr System aktiv bleiben soll. Das Backup ist bei denen auch OK - aber mir persoenlich waere das Risiko zu gross. Das muss jeder fuer sich selbst entscheiden. Oder man benutzt die Applikationsbackuptools bevor man mit raspiBackup das System sichert. Das erfordert aber eigene Programmierung eines Wrapperscripts.

[Loxtom577]

"dd hat die Faehhigkeit Aenderungen zu entdecken nicht und sollte eigentlich nicht mehr von raspiBackup angeboten werden aber dann werde ich sicherlich gesteinigt "

Gut möglich, ich nutze auch DD.

[Christian Fenzl]

Es ist nunmal nicht üblich, dass das Backup stirbt, wenn ein File geändert wurde. Ein DB-Admin macht beispielsweise eine konsistente Sicherung der Datenbank mit dem Datenbank-Tool, hat deren Konsistenz also schon sichergestellt. Dein Backup würde trotzdem sterben, wenn er nicht jedes einzelne File, das er eh schon vorher auf anderem Wege konsistent gesichert hat, noch extra ausnehmen würde.
Das macht die Konfiguration eines Backups mit RaspiBackup zu einer Challenge - ich glaube nicht, dass das viele verstehen.
Die genannten Dateien sind nicht zwangsläufig Inkonsistent - sie sind lediglich zum Beginn des Backups anders als beim Ende.
Mit der Warnung durch tar im Log sind imho sämtliche Sorgfaltspflichten durch tar und dich erfüllt. Wer sicher sein will, muss Logs ansehen.
Wenn du spezifische Return Codes für Warnungen hast, kann ich das im Plugin auch als Warnung weitergeben. GAR KEIN Backup wegen einer Warnung von tar finde ich halt persönlich etwas heftig.

[Christian Fenzl]

BTW Wenn raspiBackup bei rsync abbricht und das Backup löscht, wenn rsync ein File nicht öffnen konnte, finde ich das imho auch nicht richtig. Das wäre trotzdem eigentlich nur eine Warnung.