Ubuntu OS Sicherungen

[Crys]

Hallo miteinander,

ich habe diverse Linux Systeme am Laufen, vor allem mehrere Ubuntu LTS Server. Aktuell sichere ich nur bei den Hauptsystemen das OS per rsnapshot. Das funktioniert nur mäßig, da im laufenden Betrieb wohl nicht alle Dateien gesichert werden und somit eine Wiederherstellung mittels "löschen & kopieren der Sicherung" nicht ohne Weiteres möglich ist. Hierfür suche ich eine bessere Alternative.

Mein Ziel ist es:

• Automatische OS Sicherungen durchzuführen (welche auf eine Partition übertragbar sein sollen; falls HDDs Ausfall o.Ä.)
• Einfaches Rückspielen der Sicherung, ohne extra System (ohne booten in ein Live-System, um dort die Wiederherstellung durchzuführen).
  Wenn man z.B. versucht ein Programm zu installieren, stundenlang Einstellungen ändert und am Schluss nur den Stand vom Vormittag zurückspielen möchte.

Gibt es hierfür ein "einfaches" Programm oder Methode, was weitestgehend auf den meisten Systemen (Ubuntu 16-22, Debian, Raspbian) läuft?

Vielen Dank!

 

[Dante2000]

Veeam. Kostenlos verwendbar für Privatpersonen und lässt sich super einfach bedienen. Zum Download ist jedoch eine kostenlose Registrierung erforderlich. Funktioniert zudem für Windows und Linux.

https://www.veeam.com/linux-backup-free.html

 

[Cokocool]

Alternativ direkt auf das Cattle-Prinzip umstellen.

• Die Server komplett mit Ansible automatisiert konfigurieren. Der Server macht die Grätsche -> einfach neu bauen
• Wichtige Daten, die persistent sein sollen, regelmäßig auf ein NAS oder Cloudspeicher sichern

 

[Alexander2]

Schau dir mal BTRFS/ZFS an, da kannst du im laufenden Betrieb Snapshots machen, inwiefern es da noch tolle Programme für gibt kann ich dir leider auch nicht sagen.

 

[Muffknutscher]

Ich werfe mal Bareos in den Raum... Kostet nix und macht die deine Backups der einzelnen Dateien. Wenn gewünscht auch noch verschlüsselt.

 

[Knoops]

Wenn du mehrere Server betreibst schau dir evtl mal https://www.proxmox.com/de/proxmox-ve an. Die Integrierte Backupfunktion deckt genau das ab was du möchtest. In verbindung mit Proxmox Backup-Server noch mächtiger.

 

[bin/bash]

Mein Favorit
https://borgbackup.readthedocs.io/en/stable/

 

[andy_m4]

Das funktioniert nur mäßig, da im laufenden Betrieb wohl nicht alle Dateien gesichert werden

Ich weiß nicht genau, was Du damit meinst. Denn eigentlich gibt es bei Linux (im Gegensatz zu Windows) kein File-Locking. Auf die Dateien kann man also immer zugreifen und sie können icht z.B. durch einen anderen Prozess gesperrt werden.

Das generelle Problem was man bei solchen Sicherungen von laufenden Systemen aber hat, ist einfach der Umstand das Du eigentlich nie sichergestellt hast das die Datei die gerade kopiert wird wirklich gerade fertig geschrieben ist. Möglicherweise wird sie in dem Augenblick gerade geschrieben so das Deine Kopie unvollständig ist.

Die sauberste Lösung für das Problem ist, halt einfach die entsprechenden Services/Prozesse zu beenden (damit halt sichergestellt ist das alle Daten wirklich geschrieben sind), dann die Daten zu kopieren und dann startest Du den Service wieder. Das ist zeitaufwendig. Erst mal das Start/Stop kostet Zeit aber vor allem das kopieren. Zumindest letzteres kann man dadurch minimieren, das man ein Dateisystem (wie ZFS, btrfs usw.) nutzt was Snapshots beherrscht. Dann kann man nämlich nach dem beenden des Services einfach einen Snapshot machen und den Service sofort wieder hochfahren und kann dann in aller Ruhe den Snapshot kopieren.

Wenn die Services in einer VM laufen hat kann man im Prinzip auch den Start/Stop-Zyklus verkürzen. Mit dem Live-Migration-Funktionalität kannst Du halt den laufenden Status des Systems inkl. der Dateien wegsichern. Die Dateien sind in der VM zwar nicht sauber geschlossen aber da Du den gesamten Zustand einfrierst und später an der Stelle fortsetzen kannst ist das nicht dramatisch. Allerdings muss man aufpassen. Das "Restore" funktioniert nicht in jedem Fall fehlerfrei weil einige Services empfindlich darauf reagieren, wenn bestimmte Dinge nicht mehr so sind wie vor dem einfrieren. Weil z.B. die Uhrzeit völlig anders ist oder Netzwerkverbindungen nicht mehr gültig sind usw.

Man muss halt im Einzelfall gucken welche Anforderungen man genau hat. Wie und in welchem Umfang sind Down-Zeiten vertretbar. Wie empfindlich reagieren die Services überhaupt auf bestimmte Dinge. usw.

Einfaches Rückspielen der Sicherung, ohne extra System

Na sofern Du die Platten nicht ausbaust und woanders bespielst, wirst Du immer irgendeine Art System haben müssen.

Wenn man z.B. versucht ein Programm zu installieren, stundenlang Einstellungen ändert und am Schluss nur den Stand vom Vormittag zurückspielen möchte.

Es spricht ja nix dagegen das Rescue-System so weit vorzubereiten, das halt das Backup-Image aus dem Netz gezogen und einfach auf die lokalen Platten gespült wird.

 

[netzgestaltung]

Bei mir läuft auch Borg-Backup, hat mir mein Linux-Server-Admin empfohlen.

 

[Alexander2]

Ich Nutze auch Borg bei meinem Desktop und Laptop, aber nicht für das ganze System, sondern für Daten die ich behalten möchte.
Falls mal was doller schiefgehen sollte lässt sich das System ja easy wieder installieren.
Zudem nutze ich nicht Borg direkt sondern mit Hilfe der Oberfläche Vorta. Borg ist auf jeden Fall ziemlich Flott, ich habe auch schon mehrmals teile wiederhergestellt und das lief zuverlässig, obwohl es die bereits hundertste oder mehr inkrementell aufeinander bauende Sicherung war.

Mich hat Borg noch nicht enttäuscht :-)

 

[andy_m4]

Falls mal was doller schiefgehen sollte lässt sich das System ja easy wieder installieren.

Ja. Und selbst das kann man sogar weitestgehend automatisieren (so das man z.B: benötigte Packages nicht "zu Fuß" installieren muss). Tools wie Ansible und Co helfen dabei. Dann besteht gar keine Notwendigkeit ein Vollbackup zu machen was dann auch dazu führt, das man weniger wegsichern und speichern muss was Performance bringt und Speicherplatz spart.
Außerdem kommt ein solches Backup besser mit veränderter Hardware zurecht. Was insbesondere dann hilfreich ist, wenn der Server ein Totalschaden hat und man auf Ersatzhardware ausweichen muss.

 

[Crys]

Vielen Dank euch allen!

Veeam [...]

Bareos [...]

Proxmox [...]

Die Tools sehen interessant aus. Ich bin aber kein Fan von Dritt-Tools, die (mit Ausnahme von Bareos) proprietär sind. Aber schaue ich mal wieder an.

Cattle-Prinzip [...]

Problem ist, dass alle Server Unikate sind. Zum Teil seit der erst Installation 8 Jahren laufen und das gut. Eine Neuinstallation ist oft schon überfällig, aber zeitlich nicht machbar. Ich behalte das aber auf jeden Fall im Hinterkopf.

[...] Denn eigentlich gibt es bei Linux [...] kein File-Locking. [...]

Das war auch meine Vermutung. Eine per rsync bzw. rsnapshot erstelle Sicherung, die ich in Betrieb erstellt habe, und dann das selbe System (aus einem Live-System heraus) wieder überschreibe, hat leider noch nie funktioniert. Wieso weiß ich nicht (Rechte usw. werden übernommen bzw. sind korrekt).

Borg [...]

Ist und war auch mein Haupt-Favorit. Nur scheitere ich hier beim Wiederherstellen der OS Sicherung. Im laufenden System für (Nutzer-) Daten kein Problem. Per Live-OS das alte OS überschreiben habe ich aber nicht geschafft.
Das schaue ich mir aber als Nächstes genauer an, versuche das noch einmal und gebe Feedback (des genauen Fehlers).

Ganz im Konkreten:
Ich muss ein Ubuntu 16 LTS ESM System mal upgraden und bin mir alles andere als sicher, dass dies auf Anhieb glattgeht. Deshalb brauch ich zum Tagesanbruch eine Sicherung, auf die ich immer schnell wieder zurückwechseln kann. Das am besten nur per ssh (da der Server in einem Keller, in einem Schrank, ohne Monitor steht).
Es geht auch nur um eine OS (Partitions-) Sicherung. Alle Benutzer-Daten sind (per rsnapshot) schon sicher und eh auf anderen Partitionen.

 

[andy_m4]

Das war auch meine Vermutung. Eine per rsync bzw. rsnapshot erstelle Sicherung, die ich in Betrieb erstellt habe, und dann das selbe System (aus einem Live-System heraus) wieder überschreibe, hat leider noch nie funktioniert. Wieso weiß ich nicht (Rechte usw. werden übernommen bzw. sind korrekt).

Bei einem laufenden System fallen halt auch viele Dateien an, die einen augenblicklichen Zustand halten der später (also beim Restore) evtl. gar nicht mehr gültig ist. So gibt es zum Beispiel Dateien die ProcessIDs halten. Die werden aber ständig neu vergeben. Nach einem Reboot sind die eben anders.

Noch ein Wort zum Thema Locking. Da es unter Linux keinen echten Lock-Mechanismus gibt, ist ein typischer Weg Locking-Dateien zu erzeugen und beim beenden des lock-bedürftigen Vorganges die wieder löschen. Das sind mehr oder weniger nur leere Dateien und der Prozess guckt nach, ob es sie gibt und wenn ja, dann besteht ein Locking. Wenn nicht ist die gelockte Ressource (meist andere Dateien) frei.

Dann gibts ja noch Spezialdateisysteme wie /dev oder /proc, deren Inhalt man nicht mitkopieren und natürlich auch nicht restaurieren sollte.

Jetzt hast Du natürlich das Problem das wenn Du ein laufendes System kopierst wirst Du da höchstwahrscheinlich auch Lock-Dateien dabei haben. Machst Du ein Restore und bootest in das restorierte System finden die entsprechenden Programme die Locking-Dateien vor und denken die Ressource ist schon belegt und warten halt ewig drauf, das das wieder freigegeben wird (was natürlich nie geschieht).


Das Problem hast Du übrigens auch, wenn ein Programm abstürzt. Dann kommt es auch nicht mehr dazu, die Lockdatei wegzuräumen. Üblicherweise werden solche Dateien daher auch bevorzugt in Verzeichnissen abgelegt, wo man weiß das die regelmäßig geleert werden (wie z.B. /tmp/).

Kurzum: Es kann eine Reihe an Ursachen dafür geben, warum Dein Restore nicht funktioniert.
Generell geht das aber. Also zumindest wenn man das System "kalt" kopiert (also ohne das es läuft).
Der einzig wirklich kritische Teil sind Boot-notwendige Dateien. Je nachdem, welchen Bootmechanismus Du nimmst kann es sein, das der Loader wissen muss, wo z.B. eine Kernel-Image-Datei "physisch" auf der Platte liegt (weil der Dateisysteme nicht kennt kann er die Datei nicht einfach so laden). Wenn Du die einfach so kopierst stimmt die Konfiguration des Bootloaders nicht mehr und das System startet nicht mal. Das lässt sich lösen, indem man nach dem Restore die Bootkonfiguration neu schreibt.
Ob das relevant für Dich ist und wie man das macht, hängt aber sehr von dem System ab was Du fährst.