Raspi mit SSD komplett sichern

Jogi · 31 März 2021, 10:46:51

Hallo zusammen,
ich habe meinen Raspi vor ca. einem Jahr auf SSD-Boot umgestellt.
Bis dahin hatte ich meine SD-Karte monatlich einmal gesichert (Imagesicherung).
Seit der Umstellung sichere ich "nur" noch mein FHEM wöchentlich.
Meine Frage: Gibt es einen einfachen Weg, wie ich den kompletten Raspi sichern kann, so dass ich bei einem Problem das System schnell wieder herstellen kann?
Wahrscheinlich (so hoffe ich) wird das zwar nie nötig sein weil die SSD länger hält als eine SD, aber der Fehler kann ja auch mal bei mir liegen und ich zerschieße mir das System bei irgendeiner Bastelei. Daher würde ich das komplette System schon gerne zyklisch (1-2 mal/Jahr) sichern.

Ich bin mir bewusst, dass ich die SSD natürlich auf eine andere SSD per Imagesicherung sichern könnte, aber das erscheint mir sehr aufwändig (2. SSD vorhalten, FHEM-System steht während der Sicherung. Sicherung einer 120GB SSD dauert lange).
Der wirklich genutzte Speicherplatz auf der SSD ist zur Zeit 26GB groß.
Kann ich das auch anders/einfacher sichern?

Gruß,
Jogi

Wernieman · 31 März 2021, 11:08:41

Wenn Du eine einfache saubere Sicherung willst, ist es nicht anders Möglich. Wobei Du auch "nur" die Partitionen sichern kannst. Wenn Du natürlich auf 120G vergrößert hast ...

Es gibt auch Leute, die im laufenden Betrieb per dd sichern, ABER ...bei geöffneten/sich ändernden Dateien ist dann das Backup inkonsistent und nicht jeder kann so etwas reparieren (falls es reparabel ist)

MadMax-FHEM · 31 März 2021, 11:22:11

Ich halte tatsächlich eine 2te SSD vor

Aber ich sicher per tar.
Somit nur das was wirklich verwendet wird...

Dauert nicht lange.
Allerdings reicht mir die Sicherung von fhem (geht autom. 1x die Woche / oder nach/bei größeren Änderungen)...

Da ich ja die "vorbereitete" SSD habe.
fhem Backup drauf und gut...

Es gibt auch ein raspi-Backup was ebenfalls tar bzw. rsync nutzt und wohl auch im laufenden Betrieb (gut) gehen soll.
https://github.com/ephestione/RaspiBackup
https://github.com/framps/raspiBackup <- das denke ich war's bzw. auch hier: http://www.linux-tips-and-tricks.de/raspiBackup

EDIT: ich übernehme aber nat. KEINE GARANTIE, dass das auch problemlos läuft...

Leider finde ich grad meine Quelle des Denkanstosses nicht mehr...
...war aber auch irgendwas auf git

Dort wird/wurde zwar "bevorzugt" gleich in ein passendes img-File gesichert.
Das aber auf einen externen Server via nfs (oder auch samba?) und das will/wollte ich nicht.
Habe aber auch eine Option per tar gefunden und damit "experimentiere" ich grad rum.

Also tar im "offline Modus" (also SSD einfach in Linux Rechner) nutze ich schon lange.
Weil ich damit auch das "Problem" neue SD (früher) oder SSD zu klein umgehe.
Solange genug Platz auf der neuen SD/SSD für die "Nutzdaten" ist, ist es kein Problem.

Ja man "muss" ein wenig manuell rumtun: Partitionen anlegen und Part-UUIDs in /boot/cmdline.txt und /etc/fstab anpassen aber wenn man das öfter macht oder Notizen hat: nicht schlimm (finde ich)...

Ich experimentiere da grad rum.
Allerdings baue ich grad mein eigenes tar für laufenden Betrieb.
D.h. bestimmte Dateien/Ordner werden ausgenommen, somit ist die Gefahr, dass es "Inkonsistenzen" gibt (hoffentlich) gering...
Aber daran "übe" ich noch

Bzgl. dd o.ä. im laufenden Betrieb kann ich mich nur anschließen.
Den Fall eines nicht mehr lauf-/boot-fähigen Images hatte ich schon...

Gruß, Joachim

Jogi · 06 April 2021, 12:53:20

Vielen Dank für die Infos.
ich denke, ich werde mir dann auch eine zweite SSD zulegen.
Gruß,
Jogi

Steinardo · 06 April 2021, 18:08:32

Ich nutze raspiBackup seit einigen Jahren ohne Probleme und sichere meine Installation im laufenden Betrieb. Jede Woche ein Backup ( mit Telegram Benachrichtigung) und alle 6 Monate spiele ich das Backup zurück. Das hat zwei Vorteile. Ersten prüft man ob das Backup funktioniert und nicht korrupt ist. Zweitens übt man den Umgang mit dem Programm, nichts ist schlimmer wenn man wirklich mal zurück spielen muss und man nicht weiß wie es geht.
Vielleicht einfach mal ausprobieren https://www.linux-tips-and-tricks.de/de/

Gruß
Steinardo

framp · 08 April 2021, 10:56:24

Zitat von: Wernieman am 31 März 2021, 11:08:41
Es gibt auch Leute, die im laufenden Betrieb per dd sichern, ABER ...bei geöffneten/sich ändernden Dateien ist dann das Backup inkonsistent und nicht jeder kann so etwas reparieren (falls es reparabel ist)

Ein dd Backup ist die schlechteste Backupmethode und nicht zu empfehlen. Lieber tar oder rsync benutzen. Man kann das Risiko dass im laufenden Betrieb inkonsistente Backups entstehen dadurch minimieren dass man alle wichtigen Services vorher beendet. Deshalb kann man bei raspiBackup definieren welche Services vor dem Backup zu stoppen sind und welche wieder zu starten sind.

Wernieman · 08 April 2021, 11:14:56

Also sooo groß ist der Unterschied zwischen tar und dd nicht (abgesehen vom "im laufenden betrieb sichern"). tar hat den Vorteil, gesperrte Dateien nicht mal anzufassen.

Dafür hat tar den Nachteil, das man mit den schaltern aufpassen muß, das auch alle Berechigungen übernommen werden.

Also grundsätzlich: Ein Backup auch mal mit restore testen!

MadMax-FHEM · 08 April 2021, 11:29:46

Zitat von: Wernieman am 08 April 2021, 11:14:56
Also sooo groß ist der Unterschied zwischen tar und dd nicht (abgesehen vom "im laufenden betrieb sichern"). tar hat den Vorteil, gesperrte Dateien nicht mal anzufassen.

Naja 2 Vorteile/Unterschiede sehe ich schon (noch):

bei tar wird nur an Platz gebraucht, der auch auf dem System aktuell verwendet wird (mit gzip sogar weniger) und man kann es auch ganz einfach auf "irgendein" Medium zurückspielen, sofern der PI davon booten kann und das "Medium" halt ausreichend Platz hat.
Bei dd-Images immer etwas schwer auch mal auf "was Kleineres" zurückzuspielen...

und bei dd werden evtl. bereits vorhandene Fehler mitkopiert und (wohl) auch wieder "zurückgeschrieben".
Bei tar passiert das erst, wenn das Filesystem schon Fehler hat, also die Dateien nicht mehr gelesen werden können...
Also irgendwie werden dort Fehler erst "später" mitübernommen bzw. entstehen Fehler "beim Backup", die man "mitkriegt", wogegen dd einfach alles nimmt wie es kommt und auch so wieder zurückspielt...

Aber ich sichere lieber im "offline Modus".
Ist zwar etwas umständlich(er) aber dafür sicher(er).
Bzw. automatisch eben "nur" Konfigurationsdateien etc.

Komplette Images mache ich nur manuell und nur (wie geschrieben) wenn ich mal einen "wilden Test" fahre (wo ungewiss ist wie er ausgeht / bzw. wo auch mal was "schief gehen" könnte)...
...und schnell wieder zurück will/muss wenn der Test nicht "gut lief"...

Weil wenn ich (was gut ist und man tun sollte) quasi alle Dienste stoppe, ein Backup nehme und die Dienste wieder starte ist der Unterschied zu: ich fahre den PI runter, nehme die Karte/SSD und clone bzw. "tare" und stecke die Karte/SSD wieder und fahre hoch nicht sooo groß.
Ja klar: manueller Aufwand, dafür aber (sehr, sehr) sicher.
Und auch klar: geht nicht automatisch...

Weil was hilft ein autom. Backup, wenn es beim Restore nicht tut: nichts

Gruß, Joachim

framp · 08 April 2021, 12:45:02

Zitat von: MadMax-FHEM am 08 April 2021, 11:29:46
und bei dd werden evtl. bereits vorhandene Fehler mitkopiert und (wohl) auch wieder "zurückgeschrieben".

Exakt. Und man bekommt diesen Fehler nicht mit denn dd ist - wie man so schoen sagt - strunzendumm bzgl Filesystemen.

Bzgl Restoretest - ja das ist ebenso wichtig. In raspiBackup wird man deshalb auch standardmaessig alle 6 Monate daran erinnert.

Wernieman · 08 April 2021, 14:26:53

Hatte mal eine defekte SD und damit rumghespielt .. sowohl dd als AUCH tar haben es nicht mitbekomme .. selbst als ich wußte, das sie defekt ist .... also bitte verlasse Dich nicht auf tar ;o)

framp · 08 April 2021, 14:42:38

Zitat von: Wernieman am 08 April 2021, 14:26:53
.. sowohl dd als AUCH tar haben es nicht mitbekommen ..

Das verwundetr mich aber sehr. Jetzt wuerden mich die genauen Umstaende interessieren wie Du getestet hast und wie die Platte defekt war. tar ist sehr picky und schreibt sehr schnell Fehlermeldungen wenn was auf der Platte nicht stimmt.

Wernieman · 08 April 2021, 14:46:29

Im grunde genommen war, nach meiner Einschätzung, der "Managment-Controler" der SD (nicht SSD!) hinne, Die SD benam sich im PI normal, abgesehen davon, das der PI nicht mehr zu ende bootete. Test in einem Linux-rechner brachte per fsck keine Probleme zu tage. Erst als ich komplett neu Partitionieren wollte und anstatt 4g die SD nur noch 512 anbot, war das Problem endgültig klar.

Gibt hier irgendwo im Forum auch ein thread von mir diesbezüglich ...

Und ja, tar kann pingelig sein, muß aber eben nicht.

MadMax-FHEM · 08 April 2021, 14:48:50

Zitat von: framp am 08 April 2021, 14:42:38
Das verwundetr mich aber sehr. Jetzt wuerden mich die genauen Umstaende interessieren wie Du getestet hast und wie die Platte defekt war. tar ist sehr picky und schreibt sehr schnell Fehlermeldungen wenn was auf der Platte nicht stimmt.

Da schließe ich mich an...

Weil: Defekt nicht gleich eine Auswirkung (auf das Filesystem [und damit die Daten]) haben muss (und tar ja nun mal "Daten" kopiert und solange die [für das Filesystem] "gut" aussehen, sollte das auch kein Problem sein (selbst mit defekten "Sektoren")...

Ansonsten liegt das (in dem Fall) eher nicht an tar, sondern eher am Filesystem...

Aber ich lerne gerne dazu...
...gerade bei so wichtigen Themen!!

Gruß, Joachim