DASI

[DieterL]

So langsam, da meine FHEM Inatallation schon recht komplex ist, mache ich mir Gedanken über ein Backup.
Mein kleiner Raspberry läuft zwar recht stabil, aber der Tag wird kommen.........
Die Backup Funktion innerhalb FHEM sichert ja "nur" FHEM.
Ich hätte aber gern die komplette SD Karte- quasi als Image weggesichert, da im Laufer der Zeit immer mehr Module nachinstalliert wurden. Wie macht ihr das ?!
Win32imager fällt aus, da dafür der Raspberry heruntergefahren werden müsste. Ich würde es gern als "Online" Backup butzen wollen.
Habe aber eher geringe Linuskenntnisse. Am WE hatte ich einmal DD ausprobiert, krieg es aber nicht hin das das Image auf einem NAS gespeichert wird, was Vorraussetzung wäre, da kein USB Port mehr frei ist.
Gibt es etwas vergleichbares wie Acronis, Drivesnapshot- ich komme eher aus der Mocrosoftwelt.
Dake für euren Input.

[Hollo]

Ich habe es zwar selbst nicht im Einsatz (ich sichere mir nur das FHEM-Verzeichnis), aber vielleicht hilft Dir folgender Link weiter:

http://www.linux-tips-and-tricks.de/de/raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself/

Da sind diverse Varianten abgedeckt und es ist ziemlich anpassbar.

[Wernieman]

Erstmal der generelle Hinweis:
Ein laufenden Rechner komplett von sich selber zu sichern (egal ob Win, Linux oder Mac) ist immer wie eine Operation am "offenen Herzen". Ein Funktionsfähiges Restore ist schwierig zu gewährleisten.

Die Frage, welche Du Dir stellen solltest:
Was brauchst Du zum wiederherstellen des Rechners.

Wenn es Dir folgendes "reicht":
- defekte Hardware tauschen
- Betriebsystem/Fehlende Software neu installieren
- Konfig aus dem Backup Holen
- Daten aus dem bakup holen
- reboot und freuen
Dann ist ein Backup sehr einfach. Ein Job definieren, der dir /etc/ fhem und eventuelle Datenverzeichnisse sichert und Freuen.

Wenn Du aber wirklich ein "bare-metal-recovery" möchtest, also
- defekte Hardware tauschen
- Komplettbackup einspielen
- reboot und hoffen, das man sich freuen kann
Dann ... solltest Du wissen, was Du tust.

Nicht ohne Grund wird im Profibereich für "bare-metal-recovery"-Fähigkeit viel Geld augegeben.

Also meine Empfehlung (wie immer):
Ein Offline Full-Backup der SD-Karte
Eine tägliche Sicherung in verschiedenen Versionen (dirvish, rsnapshot o.Ä.) von /etc/ fhem und sonstigen Datenverzeichnissen

P.S. verwende bitte das nächste Mal einen Aussagekräftigeren Threat-Titel

[DieterL]

Erstmal der generelle Hinweis:
Ein laufenden Rechner komplett von sich selber zu sichern (egal ob Win, Linux oder Mac) ist immer wie eine Operation am "offenen Herzen". Ein Funktionsfähiges Restore ist schwierig zu gewährleisten.

Ähm....sorry Ich schrieb ja, dass ich in der Microsoftwelt zu Hause bin und da ist´s kein Problem. Zigmal schon Liveimage gemacht und AUCH funktionsfähig zurückgespielt, nie ein Problem gehabt, da gibt es so etwas wie VSS wenn dir das was sagt.

Die Frage, welche Du Dir stellen solltest:
Was brauchst Du zum wiederherstellen des Rechners.

Wenn es Dir folgendes "reicht":
- defekte Hardware tauschen
- Betriebsystem/Fehlende Software neu installieren
- Konfig aus dem Backup Holen
- Daten aus dem bakup holen
- reboot und freuen
Dann ist ein Backup sehr einfach. Ein Job definieren, der dir /etc/ fhem und eventuelle Datenverzeichnisse sichert und Freuen.

Es stellen sich mir keine anhand der o. g. Punkte Fragen. Ersatzhardware vorhanden.Betriebssystem neu installieren will ich nicht. Ich möchte Fullbackup, Image- wie geschrieben.

Wenn Du aber wirklich ein "bare-metal-recovery" möchtest, also
- defekte Hardware tauschen
- Komplettbackup einspielen
- reboot und hoffen, das man sich freuen kann
Dann ... solltest Du wissen, was Du tust.
Nicht ohne Grund wird im Profibereich für "bare-metal-recovery"-Fähigkeit viel Geld augegeben.

Hm....ich weiß was ich will und tue, wie gesagt mein tägliches Geschäft, nur leider nicht unter Linux.
Wer hat gesagt das ich kein Geld dafür ausgeben würde !?

[Wernieman]

Mir sagt VSS was .... aber da hat Microsoft auch ziemlich "gebastelt", das es "live" funktioniert.

Kurzfassung:
Das Betriebsystem wird angehalten, es wird der SnapShot gemacht, Betriebsystem wird wieder gestartet. Der SnapShot wird weggesichert. (VSS ist die SnapShot Funktion, NICHT das Backup)

So etwas gibt es auch unter Linux, nur ist selbstverständlich so eine "Großmimik" in einem kleinen RasPi-Image nicht mit enthalten.

Du kannst natürlich die Angesprochenen Backups verwenden, ABER ... dann musst Du auch hoffen, das ein restore funktioniert. Ich persönlich würde mich nicht darauf verlasen (Kenne Myrphi)

Ich arbeite beruflich mit Linux (und mit Windows) und wir gehen anstatt "bare-metal-recovery" von einer Neuinstallation aus.

[OliS.]

Hallo DieterL!

Was das Thema angeht, kann ich zumindest mit ein paar Erfahrungswerten dienen. Seit ca. vier Wochen führe ich einmal pro Nacht ein Backup meiner SD-Karte im Raspberry im laufenden Betrieb durch. Per at wird ein Backup-Script ausgeführt, welches zunächst FHEM beendet und dann ein Backup der SD per dd auf mein Synology-NAS schiebt. Nachdem das Backup durchgeführt wurde - das dauert für meine 8 GB Karte ungefähr 16 Minuten - startet das Script FHEM wieder.
Ich halte immer sieben Backups vor, sodass ich bei einer eventuell notwendigen Wiederherstellung bis zu einer Woche zurück gehen kann. Ich habe einzelne Backups jetzt schon testweise einige Male für ein Recovery benutzt, und bislang hat das immer hervorragend funktioniert.

Zunächst habe ich nach dieser Anleitung http://www.elektronx.de/raspberry-pi-nas-einbinden-und-beim-start-mounten/ den Backup-Ordner meines NAS in einen Ordner auf dem Raspberry gemountet.

Das eigentliche Script habe ich von dieser Seite http://developer-blog.net/hardware/raspberry-pi-backup/. Es muss nur auf die eigenen Gegebenheiten und Bedürfnisse angepasst werden.

Wie gesagt, das Ganze funktioniert für mich bislang sehr gut. Aber von Langzeiterfahrungen kann man hier sicher nicht sprechen.

Oli

[Wernieman]

Kleiner Tip:

vor dem dd kannst Du sicherheitshalber den Kernel anweise, den "cache" wegzuschreiben. also einfach ein "sync" vor dem dd ausführen.

Nur wie schon gesagt:
dieses dd kann, muß aber nicht zu einem funktionierenden Image führen ;o)

[OliS.]

vor dem dd kannst Du sicherheitshalber den Kernel anweise, den "cache" wegzuschreiben. also einfach ein "sync" vor dem dd ausführen.

Ah ok, das werde ich mir mal ansehen. Danke.

Nur wie schon gesagt:
dieses dd kann, muß aber nicht zu einem funktionierenden Image führen ;o)

Ja, ich weiß. Von Zeit zu Zeit teste ich einzelne Backups. Und die, die auf jeden Fall funktionieren, speichere ich mir noch mal extra weg.

[DieterL]

Ah ok, das werde ich mir mal ansehen. Danke.

Ja, ich weiß. Von Zeit zu Zeit teste ich einzelne Backups. Und die, die auf jeden Fall funktionieren, speichere ich mir noch mal extra weg.

Super...das werde ich einmal bei Gelegenheit testen. Vielen Dank.
Wie sind denn deine Erfahrungen mit dd !?  Hattest du auch schon Images welche nicht funktionierten ?!

[Hollo]

...welches zunächst FHEM beendet und dann ein Backup der SD per dd auf mein Synology-NAS schiebt. Nachdem das Backup durchgeführt wurde - das dauert für meine 8 GB Karte ungefähr 16 Minuten - startet das Script FHEM wieder...

Einfach mal blöd gefragt... warum hältst Du Dein FHEM an?
Das restliche System lässt Du doch auch weiterlaufen und bis auf ein inkonsistentes Logfile kann bei den FHEM-Dateien doch nix passieren.
Wenn die Kiste nur FHEM macht, würde ich persönlich nicht so einen Aufwand treiben; da reicht auch 1 Image pro Woche.

P.S.: Übrigens ist die Variante ebenfalls in dem Vorschlag/Link enthalten, den ich anfangs gepostet hatte.

[gero]

fhem stoppen kann schon sinnvoll sein, wenn man mit DbLog arbeitet.
Ein Vollbackup der SD-Karte halte ich aber trotzdem für unnötig (und problematisch).
Ich sichere zur Zeit nur das fhem-Verzeichnis, das /etc Verzeichnis und die Liste der installierten Pakete.

Mit diesen Informationen ist eine Systemwiederherstellung innerhalb kurzer Zeit möglich.

Gruß,
Gero

[OliS.]

Hattest du auch schon Images welche nicht funktionierten ?!

Bis jetzt noch nicht. Aber wie gesagt, so lange mache ich das auch noch nicht.

Einfach mal blöd gefragt... warum hältst Du Dein FHEM an?
Das restliche System lässt Du doch auch weiterlaufen und bis auf ein inkonsistentes Logfile kann bei den FHEM-Dateien doch nix passieren.

Da ich DbLog nicht verwende und allgemein auch relativ wenig logge, werde ich die Tage mal probieren, das Ganze ohne Stoppen des FHEM-Dienstes durchzuführen. Wäre mir sogar noch lieber, wenn das so funktioniert.

Wenn die Kiste nur FHEM macht, würde ich persönlich nicht so einen Aufwand treiben; da reicht auch 1 Image pro Woche.

Da ich mich momentan, was FHEM angeht, noch in der Findungsphase befinde, gibt es auch fast jeden Tag nicht unerhebliche Änderungen, die ich gerne gesichert haben möchte. Sicherlich werde ich irgendwann an den Punkt kommen, an dem ein Backup pro Woche reicht.

Ein Vollbackup der SD-Karte halte ich aber trotzdem für unnötig (und problematisch).

Inwiefern "problematisch"?
Ich hoffe, dass ich bald auch nicht mehr den Aufwand eines Vollbackups betreiben muss, wenn ich weiß, welche Ordner und Dateien ich sichern muss, um mein System im Bedarfsfall eins-zu-eins wieder schnell herzustellen. Da muss ich mich noch einlesen. Jedenfalls hat ein Recovery mit lediglich dem FHEM-Backup vor einiger Zeit so gar nicht funktioniert.

Oli

[gero]

Inwiefern "problematisch"?

siehe z.B. hier:
http://forum.fhem.de/index.php/topic,24150.0.html

Außerdem bist du mehr oder weniger darauf angewiesen, dass die neue Hardware (im Falle eines Defektes) 100% kompatibel zu deinem erstellten Image ist.
Wenn man nur die Konfiguration sicherst, kann die Hardware durchaus abweichen. Natürlich sind durchaus ein paar manuelle Anpassungen im /etc/ Verzeichnis notwendig.
Ich habe so z.B. mein Raspberry System ohne Probleme auf den odroid C1 umziehen können.

Gruß,
Gero

[framp]

...Du kannst natürlich die Angesprochenen Backups verwenden, ABER ... dann musst Du auch hoffen, das ein restore funktioniert. Ich persönlich würde mich nicht darauf verlasen (Kenne Myrphi)...

Bislang benutze ich das Script raspiBackup schon knapp 2 Jahre und habe bislang noch nie ein Problem beim Restore gehabt. Von anderen Nutzern gab es bislang auch keine Meldungen über solche Probleme. Allerdings sollte man den Restore immer mal wieder von Zeit zu Zeit testen um Murphy zuvor zu kommen  

Falls wirklich Murpy's Law eintritt hat man aber immer noch die Backupdateien per dd, tar oder rsync erzeugt und kann sich dann manuell alle wichtigen Daten wieder rausziehen auf ein neu aufgesetztes Image. Das ist natürlich wesentlich aufwändiger als ein einfacher restore mit dem Script - aber man steht in diesem Falle nicht vor dem Nichts wie ohne ein Backup. Ausserdem kann man ja eine größere Menge von alten Backups vorhalten und die älteren Backups versuchen zu restoren. Sofern kein systematischer Fehler vorliegt sollte dieses Verfahren zum Erfolg führen.

[OliS.]

siehe z.B. hier:
http://forum.fhem.de/index.php/topic,24150.0.html

Danke für den Link.

Angeregt durch die Diskussion hier, habe ich mein Backup-Konzept mal testweise umgestellt. Einmal wöchentlich fahre ich zeitgesteuert ein Vollbackup mit dd. Zusätzlich habe ich ein zweites Backup-Script erstellt, welches einmal täglich das fhem-Verzeichnis auf dem NAS sichert. Vielleicht komme ich morgen ja mal dazu, einen Restore mit einem frischen FHEM und dem Backup des fhem-Ordners zu machen.

Oli