Richtiges Backup und vor allem richtiges Restore

fpg · 04 Januar 2018, 13:44:31

Moin,

Wie hat sich Deine Vorgehensweise bewährt?
Ich stehe aktuell vor den gleichen Fragen und Problemen. Ziel ist es, im Fall der Fälle (sd-Karte geht hops) ein möglichst aktuelles image auf eine neue sd-karte zu bügeln, bzw. bügeln zu lassen. Dabei muss es im fall zwei, also dem bügeln lassen, dem laiendarsteller ohne druidenwissen möglich sein, das image auf eine neue sd-karte zu bringen.
Meine Infrastruktur beinhaltet einige windows-pcs sowie android-devices und einen synology-nas (tv, Webradio usw. lass ich mal aussen vor). Ein raspi 3 dient fhem als Grundlage und ist das neuste Geräte im Netz.
Da ich kein Freund automatischer Updates bin und zudem nicht allzuviel Zeit in Systempflege investieren kann und will, benötige ich ein eher konservatives backup-konzept.
Die Trennung von Betriebssystem und Anwendung über Partitionen macht aus meiner Erfahrung Sinn, ebenso das schreiben von log-files auf externe Medien.. wobei man ggf über eine Minimierung der log-einträge nachdenken müsste (dazu kenn ich aber das System noch zu wenig).

Meine idee:
- backup des Betriebssystems vor jedem Update als disk-image
- backup der Anwendungen vor Updates und Konfigurationsänderungen als zip-archiv (ggf. auch zyklisch Backups)

Beide Backups werden auf dem nas abgelegt und können von dort über einen windows-client zum erzeugen eines Abbildes der letzten Umgebung genutzt werden.

...so der plan....

Ich Frage mich nun, wie das alles möglichst simpel umzusetzen ist.
- Scripte zum Betriebssystem-backup manuell anstossen oder im update-script einbauen
- Scripte zum applikations-backup als cron-job und manuell anschubsbare Lösung, bzw. im update-script einbauen.
- Scripte für die windows-clients zum herstellen von systemkopien des raspi/fhem konglomerats auf eine neue sd-karte

Gruss vom fpg

Otto123 · 04 Januar 2018, 21:02:43

Hi fpg,

- aufschreiben was installiert und konfiguriert wurde.
- regelmäßig FHEM Backup machen und extern sichern.
- setup Script mit eigenen Modulen und speziellen Installationen pflegen.
- bei Bedarf: Neues aktuelles Systemimage installieren, Setup script ausführen, FHEM restore machen.

Gruß Otto

Wernieman · 04 Januar 2018, 22:10:38

Und vorallem, das Backup auch mal testen!

fpg · 05 Januar 2018, 11:16:48

Moin,
um es mal anders zu formulieren: ich suche nach einer backup-Lösung deren Restore ein lauffähiges System generiert. Das muss auch dann funktionieren, wenn kein linux/fhem-druide in der Nähe ist. Das setzt voraus, das man bei einem Ausfall des Datenträgers eine technische Lösung parat hält, die dem System eine notwendige Autonomie verleiht, indem jeder, auch ohne tiefere systemkenntnisse in der Lage ist, das System wieder in Betrieb zu nehmen.
Die Anweisung würde sich dann nur auf den Kauf einer passenden sd-karte, deren Einsatz in den card-adapter und den Start einer "APP" beschränken. Komplette Systemdokumentation mit allen Releases ist zwar nett, aber wenn die zeit knapp ist eher hinderlich.
Die Installation eines aktuellen image bringt zudem neue Unsicherheiten. Was spricht dafür ein stabil laufendes System anzufassen, zumal der erwartete Ausfall nicht ursächlich auf einen Softwarefehler zurückzuführen wäre?

Ich könnte mir vorstellen, dass ich nicht allein mit derartigen Anforderungen bin. Zudem würde eine gute Lösung zur Professionalisierung des Projekts führen.

Gruss vom fpg

Otto123 · 05 Januar 2018, 13:00:50

Hi fpg,

was Du willst bedeutet im Klartext:
- System so aufsetzen das SD Card nicht voll genutzt wird!
- System herunterfahren
- SD Karte raus offline Image machen
- SD Karte wieder rein
- System starten
Den Rest kannst Du so machen wie Du vorgeschlagen hast. Eventuell baust Du einen kleinen SD Karten Roboter, was allerdings der Slot dazu sagt

Um es vorneweg zu beantworten: Nein es gibt kein 100% funktionierendes "dummes" Online Image Backup, in keinem System.

Der erwartete Ausfall ist übrigens meistens der Admin (entschuldige Werner

)

Gruß Otto

fpg · 05 Januar 2018, 13:48:42

moin,

fast... bis auf den Roboter

und die 100%-Aussage. Gerade im Fall eines Datenträgerversagens gibt es seit ewigen Zeiten Lösungen. Aber die greifen bei den fussel-rechnern nicht... ausser man könnte eine art fail-over Spiegel einrichten. Soetwas triebe den Aufwand aber etwas weit (wobei ein zweiter raspi im Netz ja übernehmen könnte wenn es gelänge alle Periferie wie CUxe zu teilen... hmmm da ginge was mittels pub/sub a la mqtt).

zunäxxt aber simpleres

:
- gibt es ggf. eine brauchbare Lösung, ein online-image der SD-Karte auf dem raspi zu ziehen und an einen sicheren Ort zu schreiben ?
- kann man Betriebsystem incl. boot-Partition separat von den Anwendungen (FHEM) "partitionieren" ohne das man beim ersten update den Laden an die Wand fährt ?

- Wie gross muss eine SD-Karte mindestens sein, um eine fhem-Umgebung incl. OS fassen zu können ?

gruss vom fpg

Otto123 · 05 Januar 2018, 14:40:27

Zitat von: fpg am 05 Januar 2018, 13:48:42
- Wie gross muss eine SD-Karte mindestens sein, um eine fhem-Umgebung incl. OS fassen zu können ?

4 GB der Rest hängt von Dir ab

Nochmal: Online Image ist Quark - aber mir ist das Wurscht. Die Diskussion gibt es nicht jede Woche aber aller halben Jahre.

Du kannst mit dd irgendwohin ins Netzwerk schreiben. Also Stichworte:
dd
fstab
mount

Gibt es glaube ich auch schon einiges an Beiträgen hier im Forum.

Gruß Otto

Wernieman · 05 Januar 2018, 14:53:06

Zitatgerade im Fall eines Datenträgerversagens gibt es seit ewigen Zeiten Lösungen.

Aber eben nicht für absolute Daus .. und genau dafür willst DU eine Lösung.

Für Daus: Mache eine Offline-Kopie der SDCard und lege sie Dir ab. Bei jeder Änderung .....

(Wobei mir dazu auch noch einige Sachen einfallen. Eine Offline Kopie einer SDCard mit einer 2. Partition für FHEM. Beim Start von FHEM automatisch aus einem Backup fhem + config holen (z.B. Deiner Synology). Und alle 30 Minuten/Shutdown aktuellen Stand ins Backup ... + Versioniertem Backup (wird meistens vergessen))

@Otto123
Mit dem Hinweis auf "Admins" ärgerst Du mich nicht (mehr). Den häufigsten Ausfallvon Servern in meinem (Admin)-Leben hatte ich Durch Entwickler *griiins*

fpg · 05 Januar 2018, 16:27:45

Moin,

Ich hatte mir diesen Thread ausgewählt, weil mir der Ansatz vom Themenstarter gefiel.

Otto 123, warum ist ein online-abzug Quark? Funktioniert doch auf anderen Plattformen sehr gut. Sinn macht sowas vor systemänderungen. Wenn da was schief geht, spart einem das image jede menge zeit und arbeit.... ggf. auch geld.

4gb ist recht happig für eine linux-Installation.... kann man die nicht schlanker machen ??

Meine Anforderung an das backup und Restore ist zweiteilig zu betrachten:

- das backup muss so gut sein, wie der letzte konfigurierte betriebszustand und soll so weit wie möglich automatisiert ablaufen. Scripte können da hilfreich sein. Was nicht automatisierbar ist, muss im Ernstfall (update, konfigurationsänderung) manuell durch kundige User erfolgen.

- Restore ist dabei der einfachere Prozess. Der ist, soweit ich es überblicken kann, auch durch nicht-it'ler durchführbar. Eine "APP" zu bedienen und eine sd-karte zu handhaben ist heute quasi Kulturgut.

Es wäre doch eine gute Idee, ein brauchbares Konzept für solche Fälle zu entwickeln. Nicht jeder macht seine smarthome-lösung zum lebensmittelpunkt

Gruss vom fpg

Otto123 · 06 Januar 2018, 00:16:08

Zitat von: fpg am 05 Januar 2018, 16:27:45

Otto 123, warum ist ein online-abzug Quark? Funktioniert doch auf anderen Plattformen sehr gut. Sinn macht sowas vor systemänderungen. Wenn da was schief geht, spart einem das image jede menge zeit und arbeit.... ggf. auch geld.

4gb ist recht happig für eine linux-Installation.... kann man die nicht schlanker machen ??

Wenn alle Komponenten im System Online Image unterstützen geht das sicher. Aber ich meine schon raspbian ist dafür nicht gebaut. Aber Du kannst gerne sowas bauen, ich sage da nix dazu...
Gibt es noch kleinere Karten als 4GB ?

Aber ja, raspbian lite hat glaube ich weniger (1,8 GB) und FHEM braucht quasi das was Du brauchst. Ich hatte 4 GB nur gesagt weil es aus meiner Sicht mit weniger keinen Sinn ergibt.

Viel Spaß beim Online Backup und vor allem dem Restore für DAUs

Otto

kadettilac89 · 06 Januar 2018, 09:45:04

Zitat von: fpg am 05 Januar 2018, 13:48:42
zunäxxt aber simpleres :
- gibt es ggf. eine brauchbare Lösung, ein online-image der SD-Karte auf dem raspi zu ziehen und an einen sicheren Ort zu schreiben ?
- kann man Betriebsystem incl. boot-Partition separat von den Anwendungen (FHEM) "partitionieren" ohne das man beim ersten update den Laden an die Wand fährt ?

- Wie gross muss eine SD-Karte mindestens sein, um eine fhem-Umgebung incl. OS fassen zu können ?

Mit ein wenig Aufwand ist das schon machbar.

Online Backup der SD-Card?
--> https://www.linux-tips-and-tricks.de/de/raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself/

Habe ich selbst im Einsatz. Feine Sache.

Optional, damit du offene Filehandler verhinderst oder reduzierst, welche Probleme machen könnten.
--> Fhem und DB beim Backup stoppen.

Im Falle eines Fehlers --> Backup auf SD Schreiben (Windows Win32Imager) und fertig

fpg · 06 Januar 2018, 13:14:20

moin,

ja super ! scheint genau das zu sein, was ich gesucht habe

was besonders gefällt, ist die option, nicht die volle sd-kartengrösse zu sichern. man erspart sich blöde klimmzüge.

danke für den link... ich hatte etwas ähnliches schon gefunden, aber das war lange nicht so gut beschrieben, wie es in diesem link gemacht ist !

gruss vom fpg

kadettilac89 · 06 Januar 2018, 14:20:35

die Option nicht verwendeten Speicher nicht zu sichern ist etwas blöd beschrieben.

Angenommen du hast eine 8GB Karte und (Raspbian üblich) alles als Partition --> Image ist auch 8 GB

Wenn du aber die 8GB verkleinerst, und die Karten "hinten" noch 2 GB nicht zugeordneten Speicher hast --> Image nur 6 GB.

Ich würde die Partition immer etwas verkleinern. Das hat den Vorteil wenn deine Ersatzkarte ein paar MB weniger hat kannst das DD-Image dennoch zurückspielen. Das ist oft das Problem da bei gleicher Kartengröße trotzdem ein paar MB Unterschied sein können.