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.
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/ (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.
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
Zitat von: Wernieman am 28 April 2015, 10:37:22
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.
Zitat von: Wernieman am 28 April 2015, 10:37:22
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.
Zitat von: Wernieman am 28 April 2015, 10:37:22
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 !?
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.
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/ (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
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)
Zitat von: Wernieman am 29 April 2015, 10:03:39
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.
Zitat von: Wernieman am 29 April 2015, 10:03:39
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.
Zitat von: OliS. am 29 April 2015, 10:47:38
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 ?!
Zitat von: OliS. am 29 April 2015, 10:00:41
...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.
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
ZitatHattest du auch schon Images welche nicht funktionierten ?!
Bis jetzt noch nicht. Aber wie gesagt, so lange mache ich das auch noch nicht.
ZitatEinfach 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.
ZitatWenn 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.
ZitatEin 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
Zitat von: OliS. am 29 April 2015, 15:24:32
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
Zitat von: Wernieman am 28 April 2015, 13:55:04...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 ;D
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.
Zitatsiehe 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
Wenn Du das fhem Verzeichnis sicherst, dann sichere Dir auch /etc. Dort stehe (im allgemeinen) die Komplette Konfiguration der Systemes.
Da einige Beiträge wegen dd und fhem Anhalten bei dblog gesprochen wurde: bei dblog sollte man nicht nur fhem, sondern auch den sql-Server anhalten.
Die Liste der installierten Pakete ist ebenfalls sinnvoll für eine Sicherung.
So etwa in der Art:
dpkg --get-selections | awk '!/deinstall|purge|hold/ {print $1}' > packages.list
Das erleichtert das neue Aufsetzen eines Systems ungemein.
Gruß,
Gero
Danke an alle für die Tipps (auch wenn das ja eigentlich gar nicht mein Thread ist...).
Oli
Zitat von: OliS. am 29 April 2015, 10:00:41
Wie gesagt, das Ganze funktioniert für mich bislang sehr gut. Aber von Langzeiterfahrungen kann man hier sicher nicht sprechen.
Hallo OliS!
Ich hab es einmal probiert....sieht gut aus- das Image wird auf dem NAS angelegt. Ich bin begeistert !!!
Vielen Dank !!!!
Zitat von: gero am 30 April 2015, 09:08:00
Die Liste der installierten Pakete ist ebenfalls sinnvoll für eine Sicherung.
Danke für die gute Idee! Das habe ich gleich in mein Backup-Script integriert.
Jetzt habe ich eine Tagesaktuelle Liste der installierten Pakete in meinem täglichen FHEM-Backup. 8)
dd mit laufender Datenbank ist doch "fast" kein Problem ...
dump der Datenbank; sync; dd ....
dann kann man die DB notfalls direkt wieder herstellen
*lol* ich meinte auch nicht für Dich oder mich. Wenn aber jemand (ohne Beleidigung: DAU) auf die Idee kommt, für ein restore "nur" per dd das Image zurückzuspielen, wird die DB krachen. Also .. leere DB aufbauen und dann den Dump zurückspielen .. oder eben in der Backupzeit die DB abschalten ... ;o)
ähm....nix da.....man kann aber auch immer wirklich alles verkomplizieren und probleme sehen wo eigentlich gar keine sind..
hab gestern nachmittag mittels dd im laufendem betrieb ein image erzeugt. (von einer 32gb karte), aber ohne etwas herunterzufahren.und da ich nur noch eine 16gb karte hatte, mittels usb imagetool das image darauf zurückgespielt. a. war ich überrascht das dieses tool das image und die partitionen überhaupt erkannt hatte. und b. es hatte gemeckert, dass das image grösser ist als der freie kartenplatz, in den optionen des programms alles angepasst, wurde die 16er bis zum rand vollgeschrieben.
diese karte in einen anderen raspberry reingesteckt und was ich nie erwartet hätte, er bootete, startete fhem und alles ist da. also, linux könnte mein freund werden.
bin per Zufall auf den Thread gestoßen und trage mich hier nur mal kurz ein weil das Thema ist , was ich SEHR bald
angehen muss :-[
Danke für die guten Ideen
@DieterL:
Weil es ein mal funktioniert, muß es aber nicht immer funktionieren!
Und gerade wenn Du es brauchst wirst Du feststellen, das ..... Du kennst doch Murphie
Zitat von: Wernieman am 06 Mai 2015, 11:02:40
@DieterL:
Weil es ein mal funktioniert, muß es aber nicht immer funktionieren!
Und gerade wenn Du es brauchst wirst Du feststellen, das ..... Du kennst doch Murphie
Du weißt doch wie das in der Praxis gehandhabt wird !? Wie ein vernünftiges Backupkonzept aussieht ?"
Mittlereile hab ich es mehrmals durchgespielt......bisher sind alle Images lauffähig und fehlerfrei, da kann Murphy ruhig zuschlagen, ich habe mehrere Images mehrmals auf versch. Datenträgern abgelegt. Damit könnte ruhig alles abkacheln. Innerhalb von zwei Minuten wäre alles wieder funktional.
Somit kann man DD ruhig weiterempfehlen, ohne ein schlechtes Gewissen haben zu müssen.
Ich bin Backup-Administrator, da sollte ich wissen .. *griiiis*
Zusätzlich sollten Backups automatisch laufen (z.B. 1 mal in der Woche / 1 mal in der Woche), da manuelle Backups irgendwann nicht mehr ausgeführt werden ...