Linux System Backup

[Wolfgang Hochweller]

Auch wenn die Frage vielleicht eher in ein Linux Forum gehört; hier gibt es ja vorwiegend Linuxinstallationen, daher meine Frage :
Ich verwende FHEM auf einem kleinen Intel NUC, Debian Server, headless.
Ich möchte gerne die Systemplatte regelmaessig komplett sichern, aber ohne Anschließen eines Monitor und auch ohne Ausbauen der Platte.
Ziel ist es, das System ohne großen Zeitverlust im Falle eines Diskausfalls, etc. wieder aufsetzen zu können.
Etwaiger Datenverlust seit der letzten Sicherung ist dabei erstmal unerheblich, die Daten kann ich separat häufiger sichern.

Wie sollte ich da vorgehen ?

[juergen012]

Hallo,
ich sichere jede Nacht meinen Raspi auf mein NAS. Somit kann ich bei einem Crash der MicroSD eine neue flashen und das System läuft wieder.
Das NAS mounten..

Code Auswählen Erweitern

//<IP vom NAS>/Sichern_/Sichern/Backups /mnt/Backups cifs vers=3.0,username=xxxxxxxxx,password=xxxxxxxxxxx,rw,soft,_netdev,x-systemd.automount 0 0


habe 2 scripts. Die werden in der crontab aufgerufen:

Code Auswählen Erweitern

00 2  * * * /home/pi/script/RPI_backup.sh
#
59 23 * * * /home/pi/script/autodelete.sh


um 23.59h werden alte Sicherungen gelöscht. um 02:00h wird gesichert.

Code Auswählen Erweitern

#!/bin/bash

find /mnt/Backups/*.img -mtime +4 -exec rm {} \;


Code Auswählen Erweitern

#!/bin/bash
sudo dd if=/dev/mmcblk0  of=/mnt/Backups/FHEM-$(date +%Y%m%d-%H%M%S).img bs=1MB


Beste Grüße
Jürgen Koch

[Wernieman]

Kannst Du bitte den Thead zu " Server - Linux" Verschieben? Dort gehört er eigentlich hin ...

Zum Thema Backup wurde hier schon viel geschrieben. Ich selber bin kein Freund von "Systemplatten-Sicherung im laufenden Betrieb" (Siehe einen Beitrag vorher). Es gibt hier einige, welche ein Dump der Systemplatte im laufenden Betrieb machen und es auch erfolgreich wiederherstellen konnten. ABER ... im laufenden betrieb sind einige Dateien geöffnet und da Unix (Linux) eher cached als schreibt, sind diese dann nicht konsistent. Entsprechend kann es sein, das ein solches Backup nicht funktioniert.

Da laut Murphys Gesetz alles schief geht was schiefgehen kann, wird im notwendigen Restorefall genau das zutreffen ....

Habe deshalb mein Backup (ein Zotac CI320) anders organisiert:
komplett /etc, fhem, /home und MySQL dump wird automatisch täglich gesichert. Im Restorefall wird das System wieder aufgesetzt.

Als "Backupsoftware" verwende ich dirvish, was auf rsync aufbaut. Alternativen mit ähnlichen Aufbau: rsnapshot, rdiff-backup .... (oder Hardcore mit rsync).

Gibt aber auch diverse andere Lösungen (incl. Großlösungen wie bacula etc.)

Hinweis:
Als Software sind hier nur OpenSource Lösungen erwähnt. Du willst doch bestimmt kein geld ausgeben ;o)

Zusammenfassung:
Komplett Backup mit dd (o.Ä.) würde ich Dir nicht empfehlen. Für mehr Empfehlungen müsste man Dein Backupplan wissen.

Edit:
Jemand anderes war schneller, habe zum schreiben zu lange gebraucht. Trotzdem (und angepasst) veröffentlicht.

Edit2:
@Jürgen:
Wenn Du schon ein Script hast, würde ich Dir empfehlen vor dem dd ein sync einzutragen. So wird die Wahrscheinlichkeit der Oben erwähnten "offenen Files" Minimiert.

[Thyraz]

Da ich zur genauen Fragestellung leider nichts beizutragen habe (außer der Idee zu einem von USB-Stick bootbaren Live-System mit Backuptool) eine Anregung, da du mit einem NUC ja auch eher ein überdimensioniertes System hast:

Ich habe gerade auch aus dem Grund von einfachem Backup/Restore auf Virtualisierung gesetzt.

Bei mir läuft auf dem NUC Proxmox als Host und (unter anderem) Fhem als Gast im Ubuntu Container.

Proxmox ist bei totalem Systemausfall einfach installiert und dann können direkt die Backups der Gastsysteme eingespielt und gestartet werden.

In den Backups der Gastsysteme sind auch die PassThrough Settings für USB-Geräte mit gespeichert.
Solange man auf dem selben System restored (auch wenn die Platte komplett tot war und man Proxmox neu aufgespielt hat) läuft das also alles gleich wieder problemlos.

Wenn man dann mal wirklich auf andere Hardware wechselt, muss man beim Passthrough nur auf das Quelldevice im Hostsystem anpassen.
Der Name im Gastsystem bleibt ja gleich und hier muss dann nichts angefasst werden.

Das Backup eines Systems ist denkbar einfach über das Proxmox Webinterface.
Backup wählen, als Backuptyp "Stop" wählen, damit das Gastsystem runtergefahren wird (und kein Backup im laufenden Betrieb versucht wird).

Als Ziel kann man NFS Shares hinzufügen um z.B. direkt aufs NAS zu sichern.
Das Gastsystem wird dann runtergefahren, das Backup erstellt und das Gastsystem dann wieder automatisch gestartet.
Ein Restore läuft genauso ab, ohne das Hostsystem runterfahren/neu booten zu müssen.

Vereinfacht die Sache ungemein wenn man das mal so eingerichtet hat.
Auch der Umstieg auf einen neuen Rechner bereitet einem dann nicht mehr so große Sorgen wenn es denn mal wieder nötig wird.


edit: Auf Automtisierung des Ganzen bin ich jetzt mal nicht eingegangen.
Klang in deinem Post ja so, als ob du FHEM etc. öfters automatisch sicherst und es nur um Backup des Gesamtsystems geht wenn sich mehr geändert hat (neue Pakete installiert, System upgedatet, ...)

[Wernieman]

Kann man ein Proxmox auch Scripten? D.h. Backups automatisch starten?

Manuelles Backup wird bekanntlich gerne "vergessen" ....

[darkness]

um 23.59h werden alte Sicherungen gelöscht. um 02:00h wird gesichert.

Hier ist aber die Gefahr, dass aus irgendeinen Grund dd fehl schlägt und dann trozdem gelöscht wird. Dann ist irgendwann das Backupverzeichnis leer 

Stichwort Exit-Codes. Erst löschen, wenn dd erfolgreich war.

Das aber nur am Rande. War ja nicht die Frage...

[darkness]

Kann man ein Proxmox auch Scripten? D.h. Backups automatisch starten?

Manuelles Backup wird bekanntlich gerne "vergessen" ....

Ja, z.B. vzdump auf dem Host. Bzw. du kannst die Backups in der GUI anlegen und diese werden dann automatisch zur angegeben Zeit gestartet.

[Thyraz]

Scheduled Backup
Backup jobs can be scheduled so that they are executed automatically on specific days and times, for selectable nodes and guest systems. Configuration of scheduled backups is done at the Datacenter level in the GUI, which will generate a cron entry in /etc/cron.d/vzdump.

https://pve.proxmox.com/wiki/Backup_and_Restore

[Wolfgang Hochweller]

Danke fuer die Antworten.
@Thyraz:
Der Einsatz des NUC ( der kleinsten Sorte, mit Celerons, aber immer noch viel schneller als alle meine Raspis ) ist ein Ergebnis verschiedener Erfahrungen :
- die Lebensdauer von sd-Karten ist (oft) beschraenkt, oder ich hatte Pech mit der Auswahl.
- eine ssd am Raspi ueber USB zu betreiben habe ich mal versucht, kein guter Erfolg
- gleiches gilt uebrigens fuer den Betrieb des Raspi ueber einen USB-Stick

Pi 4 habe ich noch nicht probiert,da ist ja wohl USB besser implementiert.

[MadMax-FHEM]

Warum kein guter Erfolg mit SSD!?

Ich betreibe 4 PI (1x fhem und 2x tvheadend an versch. Standorten) mit SSD bzw. einer davon (PI4) mit HDD und kann nichts negatives sagen...

EDIT: bei Backup reicht mir das fhem Backup mit meinen Notizen... Alle paar Jahre wird "geübt" beim Umstieg auf eine neue OS-Version... Da fange ich eh "frisch" an... Sollte ich mal "außerplanmässig" Restoren müssen tut das bisschen OS Aufspielen nicht weh...

Gruß, Joachim

[Wolfgang Hochweller]

Ich denke, es lag/liegt eher an der USB-Anbindung im Pi3.
Zwei USB-Anschluesse sind bei mir eh  schon belegt; es hat weder mit Stick noch SSD zufriedenstellend geklappt, sprich, mal war die SSD 'weg', mal der Stick.
Habe ich dann erstmal aufgegeben.

'Das bisschen OS aufspielen' macht ja sogar noch Spass,   ist aber relativ.
OS ist auch nicht das, was am meisten Zeit braucht, sondern alles andere, was mittlerweile noch dazu installiert werden muss,
ein Python-Skript hier, eine Perl-Erweiterung da, eine Datenbasis, usw..
Richtig laestig wird es, wenn man noch andere Sachen laufen hat, etwa einen Wireguard-Server , Pihole ....

[MadMax-FHEM]

Bei mir sind mit SSD 3 USB belegt: HM-CFG-USB, ZWave-USB und eben mSata-USB+SSD...
Ebenfalls PI3

Gut auf meinem fhem-PI läuft nur fhem (außer bei meiner Freundin, da ist noch ha-bridge und piVPN drauf, geht aber beides schnell)...

Bei mir hab ich einen PI4 für Samba, piHole, piVPN, ...

Allerdings würde ich trorzdem bei einem OS-Umstieg neu aufsetzen...

Für ein schnelles "Notaufsetzen" sichere ich beide Partitionen mittels tar...
Da wird nur gespeichert was auch genutzt ist und kann somit auf jedes Medium mit genug Platz aufgespielt werden...

Gruß, Joachim

[Peteruser]

Hallo,
auch bei mir ist FHEM nur noch virtuell. Der NUC hat genügend Power um als Host für FHEM als Gast zu dienen. Neben der Möglichkeit noch andere Dienste da darauf laufen zu lassen, ist das die aus meiner Sicht optimale Lösung um eine Sicherung zu machen. Runterfahren und Kopieren des Systems geht erstaunlich schnell und passiert per skript nachts Auf was man hier als Grundsystem setzt  ist hier egal, wichtig ist nur das Verschieben auf ein anderes Medium.

Hat mir beim Spielen schon mehrfach den Hintern gerettet, auch direkte Snapshot direkt vor der Tat kein zeitliches Problem. Hier kann man dann auch zeitnah sehen, ob das Backup funktioniert.

Grüße Peter