Raspi Komplettbackup möglich?

[Jackie]

Hallo,

den FHEM Befehl "backup" kenne ich bereits sehr nützlich um ein Backup der FHEM Daten zu erhalten. Aber: inzwischen habe ich so viel am Raspi selbst, bzw. dem installierten Linux geändert, was will ich im Falle eines Falles ungerne verlieren.

Gibt es eine elgenate Lösung, die gesamte SD Karte komplett zu sichern, so dass man sie im Falle eines Falles einfach wieder herstellen kann?

[wagenkna]

Hallo,

hier eine gute Beschreibung: http://www.meintechblog.de/2015/05/fhem-howto-automatisches-backup-auf-externem-nas/

Ich hoffe es hilft Dir weiter

herbstliche Grüße

[Jackie]

Hallo wagenkna,

danke, aber der Artikel beschreibt ja nur wie man Backups von FHEM durchführt, ich möchte aber das komplette zugrundelegende System inklusive Linux und aller Änderungen daran sichern.

Also quasi das was Tools wie Acronis oder Drive Snapshot unter Windows tun, nur eben auf Linux ebene!

[ergerd]

Hallo Jackie,

ich mache es mit RaspiBackup:  http://www.linux-tips-and-tricks.de/raspiBackup

Grüße
Rainer

[SmartHome]

Hallo Jackie,

ich mach das immer offline http://www.manfred-steger.de/de/blog/raspberry-pi-image-sd-karte-klonen
Muss mir aber raspiBackup unbedingt mal anschauen. 

Gruss
SH

[schnitzelbrain]

Da kann ich dir die Dietpi distro empfehlen. Die hat ein backup auch auf externe Datenträger, eingebaut.

http://dietpi.com


Selbst getestet auf xu4 board, backup und restore einwandfrei.

Grüße

Schnitzelbrain

[Christoph Morrison]

Gibt es eine elgenate Lösung, die gesamte SD Karte komplett zu sichern, so dass man sie im Falle eines Falles einfach wieder herstellen kann?

Konträr zur vorherrschenden Meinung vertrete ich einen "lazy backup"-Ansatz. D.h. ich mache gar keine, sondern ich halte jede Änderung die ich an meinen Pis mache als Konfiguration fest (in meinem Fall mit Puppet): Installiere ich z.B. ein neues Paket, dann erweiterte ich meine Puppet-Rezepte um die Änderung und fertig. Ich sichere lediglich mehrmals täglich den State-File meiner FHEM-Installation auf einem Netzwerkspeicher.

Geht mir mal ein PI, eine SD-Karte oder sonst was kaputt, setze ich einfach einen neuen PI mit Puppet auf und gut ist. FHEM-Config kommt aus einem Repository, Statefile vom Backup und das System an sich + FHEM wird von Puppet serviert.

[Hauswart]

Wie wäre es mit einem einfachen dd-Backup (https://wiki.ubuntuusers.de/dd/ oder  https://www.raspberrypi.org/documentation/linux/filesystem/backup.md)?

[Tom111]

Die einzig und alleinig wahre Sicherung gibt es NUR mit einer Komplettsicherung der SD-Karte, z.B mit
https://sourceforge.net/projects/win32diskimager/ alles andere ist Murks!!
Ich sichere meine Karte einmal im Monat (oder nach größeren Änderungen)!

[nils_]

Die einzig und alleinig wahre Sicherung gibt es NUR mit einer Komplettsicherung der SD-Karte, z.B mit
https://sourceforge.net/projects/win32diskimager/ alles andere ist Murks!!

weil??

[Tom111]

weil??

Es gibt kein "weil"... im laufendem System verändern sich Daten, Zugriffe sind teilweise nicht möglich!

[nils_]

Es gibt kein "weil"... im laufendem System verändern sich Daten, Zugriffe sind teilweise nicht möglich!

stimmt. alles möglich.

aber du schreibst

Die einzig und alleinig wahre Sicherung gibt es NUR mit einer Komplettsicherung der SD-Karte, z.B mit
https://sourceforge.net/projects/win32diskimager/ alles andere ist Murks!!
Ich sichere meine Karte einmal im Monat (oder nach größeren Änderungen)!

also nochmal anders formuliert:
wieso ist alles andere murks?
gibt es gründe, die gegen andere ansätze sprechen? (unter anderem schon hier erwähnte....)

[MadMax-FHEM]

Es gibt kein "weil"... im laufendem System verändern sich Daten, Zugriffe sind teilweise nicht möglich!

Eben, daher: System runter fahren, Datensicherung (Image-Komplett-Kopie) und System wieder hochfahren...
...während dieser Zeit läuft das System nicht!
(wie lang oder kurz das auch immer dauert / ganz abgesehen von der "Fummelei")

Da finde ich diesen Ansatz https://forum.fhem.de/index.php/topic,79467.msg715300.html#msg715300 den ich auch so mache minimal invasiv bei (sehr) hoher Effektivität.

Die für mich (fhem) wichtigen Daten sind gesichert (genausogut wie mit Komplett-Image-Backup) und das System kann laufen...
...und einen evtl. bereits vorhandenen Fehler im Image der SD-Karte habe ich so auch weniger wahrscheinlich im Backup...

Abweichend ist natürlich, dass die (nach)installierten Pakete gegebenenfalls neuer sind und daher abweichen, klar.
War bislang aber noch nie ein Problem...
...bzw. mache ich ja irgendwann eh einen Update und ein Umzug auf eine neue (Betriebssystem) Plattform ist so auch einfach, weil es einfach der "normale" Restore-Vorgang ist...


Letztendlich finde ich es eigenartig genau das und nur das von dir propagierte "Voll-Bakup" als DAS Backup zu bezeichnen...

Und daher gibt es wohl ein berechtigtes: weil...

Gruß, Joachim

[Beta-User]

Da finde ich diesen Ansatz https://forum.fhem.de/index.php/topic,79467.msg715300.html#msg715300 den ich auch so mache minimal invasiv bei (sehr) hoher Effektivität.

Kann mich dem nur anschließen!

Wer andere Hardware als einen Pi nutzt, wird es eh' in die Richtung machen, und wer einen Pi nutzt, braucht ein volles Backup einschließlich OS vermutlich nur, weil er Soft- und Hardware nicht mehr sauber trennen kann (z.B. weil irgendwelche GPIO-Konfigurationen ihn dazu zwingen, eine alte OS-Version zu nutzen - oder wenn es nicht das OS selbst ist, dann die Furcht davor, dass ein OS-Update mal wieder alles durcheinanderbringt).

Und warum irgendein Windo.*-Tool besser sein soll als das gute alte dd aus Beitrag #8, will ich eigentlich schon gar nicht mehr wissen .

Gruß, Beta-User

[MadMax-FHEM]

Und warum irgendein Windo.*-Tool besser sein soll als das gute alte dd aus Beitrag #8, will ich eigentlich schon gar nicht mehr wissen .

So weit wollte ich gar nicht ausholen

Gruß, Joachim

[Beta-User]

So weit wollte ich gar nicht ausholen

Bot sich an, da ich sowieso schon mal dabei war...

Aber bevor hier jemand behauptet, dass sei ja alles schön und gut, aber man müsse die Partitionen hinterher sowieso bearbeiten, wenn die Datenträger nicht 100% identisch groß sind, man mit dd Partitionen ja nicht verkleinern kann und daher soweiso ein grafisches Tool braucht:

https://linux.die.net/man/8/resize2fs

Dort mal die Option -M ansehen...

Und der Vollständigkeit wegen für die, die glauben, dass das aber nicht für eine SD-Karte aus einem Pi geht, weil die ja mehrere Partitionen hat:

https://linux.die.net/man/8/losetup

Aber man kann das alles natürlich auch mit grafischen Werkzeugen unter diesem seltsamten OS aus Redmond machen (oder wenigstens versuchen) .

Aber irgendwie wird es mir immer ganz schummrig, wenn ich daran denke, Linux-Filesysteme wie ext4 unter Windows zu verwenden .

Aber jeder, wie er kann und mag .

[Ranseyer]

wenn die Datenträger nicht 100% identisch groß sind, man mit dd Partitionen ja nicht verkleinern kann

Das Problem mit der evtl minimal kleineren SD Karte lässt sich auch simpel umgehen.

Entweder einfach 100MB (oder weniger) auf der Quelle freilassen. Wenn dann das kopieren beim Ende vom Schreibvorgang abbricht spielt es keine Rolle. Oder einfach die doppelte Größe für das Ziel verwenden. Auch das sollte im Fehlerfall zu verschmerzen sein.

Tja und was ist nun die richtige Methode für Backups?

Ganz sicher die, die man selbst schon mal ausprobiert hat (ohne Restoretest geht es nicht). Dabei spielt es keine Rolle ob der Restore absichtlich oder aufgrund eines Problems erfolgte. Der eine mag lieber neu installieren, der andere mag lieber mehr Sicherheit in der eventuellen Stresssituation.

Dass ein Vollbackup eines aktiven=inkonsisten Systems Quatsch ist, wurde ja schon gesagt.

Wer also nicht weiß was er tun soll könnte mit dd oder dem Win32DiskImager die Grundsicherung machen. Dann die fhem.conf bei größeren Änderungen gesondert sichern und überlegen, ob auf den Status der Geräte verzichtet werden kann.

Gesendet von meinem VTR-L09 mit Tapatalk

[Christoph Morrison]

Die einzig und alleinig wahre Sicherung gibt es NUR mit einer Komplettsicherung der SD-Karte, z.B mit
https://sourceforge.net/projects/win32diskimager/ alles andere ist Murks!!
Ich sichere meine Karte einmal im Monat (oder nach größeren Änderungen)!

Und dann machst du auch jedes mal schön ein Restore und checkst ob das Backup funktioniert hat? Wenn ja, wie genau machst du das?

[Wernieman]

Auf eine SD-Karte schreiben und in einem RasPi prüfen ...

Nur mal zur Info:
So etwas nennt man in "Backupkreisen" Full-Metal-Backup. Ist auch unter Windows nicht ganz Trivial. Jemanden einfach eine Nackte Hardware (Pure-Metal) in die Hand drücken und sagen: Mach mal ein restore ... funktioniert auch in professioneller Umgebung nicht immer .... sprich aus negativer Erfahrung ;o)
(Ist ein gängiger Test, wenn von externen Prüfern, Gutachtern das Backup/Restore geprüft werden soll und er noch nichts gefunden hat)

Dabei ist es beim Pi wirklich einfach: runterfahren, dd von SDCarte und anschließend Checksumme prüfen. Ein Dump hat den 2. Vorteil, das er nachträglich mit Bordmiteln bearbeitet werden kann (mount, rezise etc.).

Nur ... braucht man wirklich so einen Aufwand? Ich bin auch ein Freund der "legaci Lösung" (Sogar Beruflich): Daten (auch Config-Daten wie /etc) gehören ins Backup, Software wird im Crash-Falle Neuinstalliert. Komplettbackup nur bei Systemen, wo Ausfall 2h schon zu teuer ist (Wobei man dort noch gaaaaaans andere Probleme hat)

[Hauswart]

Wird ein interessantes Thema hier

Zumindest bei einem SD-Karten Ausfall kann ich aber mittels dd-Backup sehr schnell und mit sehr wenig Aufwand das System wieder zum Laufen bringen. SD-Karte einlegen, eine Zeile im Shell und paar Minuten warten.



Offtopic: Ich suche weiterhin nach einer geeigneten Backup-Methode für meine VMs auf meinem ESXI 6.5. ESXI wird Privat betrieben. Ich fürchte allerdings einen Windows-Server installieren zu müssen, um z.B. Veeam verwenden zu können: https://www.veeam.com/de/virtual-machine-backup-solution-free.html

[CoolTux]

Virtuelle Maschinen werden ganz normal gebackupt als wäre es Blech. Oder Du machst ein Snapshot oder halt ein Backup der Virtuellen Disk mit Beschreibungsdatei der Maschine.