Forum: PC Hard- und Software Linux Snapshot Image (Backup) vom laufenden System


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Messwert (Gast)


Lesenswert?

Hallo zusammen,

kennt zufällig jemand eine Software um unter Linux ein Image der 
Festplatte im laufenden Betrieb zu erstellen?
Das Image soll nach dem Backup im Fehlerfall der Festplatte auf eine 
neue geschrieben werden können um in diesen Stand zu booten.

Natürlich soll es ein "echter" Snapshot sein, ab Backup Beginn darf sich 
nichts, was im Backup landet, ändern.

Das System kann auch während der Prozedur "eingefroren" sein aber es 
muss vom laufenden Betrieb aus startbar sein, da ich das ganze gerne 
einmal im Monat oder bei Bedarf starten möchte.

Ist da etwas bekannt? Ich denke Clonezilla oder dd bringt mich hier 
nicht wirklich weiter.

Ein Dateibackup läuft täglich per Restic, es geht mir um ein Image das 
auf eine neue Platte geschrieben werden kann und bootfähig ist.

Unter Windows hat das vor einigen Jahren mit Acronis True Image gut 
funktioniert, für Linux habe ich sowas leider noch nicht gefunden.

von Εrnst B. (ernst)


Lesenswert?

Falls Dateisystem ZFS oder btrfs:

snapshot anlegen, btrfs send

geht später sogar inkrementell, d.h. du kannst mit btrfs send nur die 
geänderten Blöcke zwischen zwei Snapshots rausschreiben.


Falls LVM:

snapshot anlegen, dd

Braucht genug freien Platz in der VG.
Geht nicht wenn du per LVM Sachen wie SSD-Cache-für-HDD etc machst.


direkt bootfähig sind diese images nicht, da nur ein Dateisystem bzw. 
nur ein LV gesichert wird.

aber bootsektor/EFI & "/boot/" kannst du wohl schnell wegsichern, ohne 
dass sich da zwischendurch was ändert.

: Bearbeitet durch User
von Gerd E. (robberknight)


Lesenswert?

Ich habe meine Server mit LVM konfiguriert. Also alles, außer BIOSBOOT 
oder EFI System Partition, ist in einem LVM volume. Auf der LVM volume 
group lasse ich dann so vielleicht 2-5 GB (je nach Bedarf) Platz frei 
damit während das Backup geschrieben wird genug Änderungen gemacht 
werden können.

Wenn ein Backup erstellt werden soll mache ich von allen logical volumes 
ein snapshot, mounte die unter /mnt/snap und mache davon ein Backup.

Natürlich könnte man das Backup auch statt auf Dateiebene mit dd, 
partimage, clonezilla oder ähnlichem erstellen.

Funktioniert seit Jahren problemlos. Auch die wenigen male wo ich das 
Backup brauchte hat Rückspielen problemlos funktioniert.

von Messwert (Gast)


Lesenswert?

Super, vielen Dank! Jetzt ärgere ich mich nur das ich das System auf 
ext4 installiert habe... :)

von Messwert (Gast)


Lesenswert?

Mal ganz naiv gefragt:
ist es mit einem LVM auch möglich ein "pseudo raid" zu erstellen?
Hintergrund:
Mir ist vor kurzem die SSD von meinem Server ausgefallen (120GB) 
ziemlich sicher wurde zu viel geschrieben, Logdateien die ständig per 
Logrotate wieder komrimiert wurden und MariaDB Datenbanken.

Meine Idee wäre jetzt alles wie bisher auf der SSD laufen zu lassen und 
einmal am Tag auf eine angeschlossene Festplatte zu spiegeln, wie in 
einem Raid nur zeitverzögert da eine normale Festplatte zu langsam für 
ein performantes System ist.

von Alexander (alecxs)


Lesenswert?


von Εrnst B. (ernst)


Lesenswert?

Messwert schrieb:
> Meine Idee wäre jetzt alles wie bisher auf der SSD laufen zu lassen und
> einmal am Tag auf eine angeschlossene Festplatte zu spiegeln, wie in
> einem Raid nur zeitverzögert da eine normale Festplatte zu langsam für
> ein performantes System ist.

lvmcache im "writeback" Modus würde fast das Gewünschte tun. 
Schreibzugriffe landen zuerst in der SSD, und werden dann, wenn 
ungenutzte HDD Bandbreite übrig ist, im Hintergrund auf diese 
zurückgeschrieben.

Aber: Geh nicht davon aus, dass bei SSD-Ausfall die Datenbank-Dateien in 
einem gültigen Zustand sind. Die fsyncs, mit denen der DB-Server das 
sicherstellen wollte, landen nur auf der SSD (sonst wär der 
Write-Performance-Gewinn auch weg).

Writethrough könnte aber auch schon ordentlich was bringen, wenn die 
Datenbank hauptsächlich liest und wenig schreibt.

von pp (Gast)


Lesenswert?

REAR - RElax And Recover...

von Eric (Gast)


Lesenswert?

Bei EXT4 wird das nichts mit Backup im laufenden Betrieb. Dazu brauchst 
du LVM/btrfs/ZFS.
Wenn Du aber eine kurze downtime verschmerzen kannst, dann empfehle ich 
Dir, von einem Live-System zu booten, dann chroot in das alte System und 
ganz simple mit tar (bsdtar) ein komplettes Backup des Systems zu 
erstellen (dabei dann natürlich nicht benötigte Verzeichnisse auslassen 
- e.g. /tmp oder cache)
Beim wiederherstellen das gleiche. Live-System, chroot. Darauf achten, 
dass beim entpacken acls und Attribute beibehalten werden.

von pp (Gast)


Lesenswert?

REAR:

https://github.com/rear/rear.github.com/blob/master/documentation/release-notes-2-5.md

"Support included for most common file systems, such as ext2, ext3, and 
ext4. Other filesystems like reiserfs, jfs, xfs, and btrfs are also 
implemented, but are less tested. "

Wir haben (meistens) ZFS genutzt...

von Le X. (lex_91)


Lesenswert?

Ich sichere meine Systeme (Desktop, Tablet, diverse VMs (sowohl 
Virtualbox als auch Proxmox am NAS), Raspberry) indem ich mittels 
rsnapshot (basiert auf rsync) inkrementelle Backups im laufenden Betrieb 
mache. Somit habe ich für alle Systeme ein einheitliches Vorgehen.

Die Backups werden von einer dedizierten Backup-VM "gepullt" die nur bei 
Bedarf läuft. Dadurch haben die Systeme keinen Zugriff auf die Backups. 
Die Backup-Platte ist die meiste Zeit physikalisch vom Netzwerk 
getrennt.

Wiederherstellen funktioniert per Livesystem-Boot und dann einfach per 
rsync das Backup wieder kopieren. Bei Bedarf noch ins System chrooten 
und den bootloader installieren/konfigurieren bzw. UUIDs in der fstab 
korrigieren.

Disclaimer: ich habe hauptsächlich ext4-Systeme im Einsatz und, wie oben 
mehrmals erwähnt, ist ext4 für diesen Ansatz nicht geeignet.
Das nehme ich aber in Kauf. Ich strebe nicht die akademisch perfekte 
Lösung an sondern eine komfortable Lösung die für mich dauerhaft 
funktioniert und die für eine Vielzahl an Systemen möglichst wenig 
Handgriffe erfordert.
Und das tut sie. Ich musste bereits Systeme wiederherstellen und es hat 
bisher immer geklappt.
Sollte es mal nicht klappen (wegen Inkonsistenzen o.Ä.) kann ich immer 
noch ins Backup-Verzeichnis chrooten und mir die Paketliste, oder, noch 
viel wichtiger, die Konfig-Files sichern.
Datenbanken könnte man innerhalb der Systeme noch per cron regelmäßig 
mit den Mitteln der jeweiligen DB dumpen.

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

Le X. schrieb:
> Ich sichere meine Systeme (...) mittels rsnapshot (basiert auf rsync)

Was kann das mehr als ein "rsync -a"? Die manual page von rsync muss man 
ja trotzdem verstanden haben und dann zusätzlich noch rsnapshot. Lohnt 
sich das? Es hat auch eine bewegte Vergangenheit:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986709

Aber unabhängig davon finde ich das Prinzip optimal. Ich mag das, wenn 
ich eine einzelne Datei aus dem Backup einfach mit (s)cp zurückholen 
kann. Und man kann es auch zweimal täglich laufen lassen weil es extrem 
viel schneller geht als ein Image-Backup.

Warum haben alle Leute soviel Angst davor, den Bootloader zu 
installieren?

: Bearbeitet durch User
von ●DesIntegrator ●. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Lesenswert?

Ich vermisse bei Backup-Tips allzuoft den Hinweis
ein Backup auch zu testen.

nur "eben mal sichern" ist wie die Katze im Sack.

von Bauform B. (bauformb)


Lesenswert?

●DesIntegrator ●. schrieb:
> Ich vermisse bei Backup-Tips allzuoft den Hinweis
> ein Backup auch zu testen.

Auch das ist bei der rsync-Lösung trivial.

von Le X. (lex_91)


Lesenswert?

Bauform B. schrieb:
> Was kann das mehr als ein "rsync -a"? Die manual page von rsync muss man
> ja trotzdem verstanden haben und dann zusätzlich noch rsnapshot. Lohnt
> sich das? Es hat auch eine bewegte Vergangenheit:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986709

Naja, rsnapshot ist halt etwas Komfort-Zucker auf rsync gestreut.
Du kannst Konfig-Files anlegen und deine backup-Strategien festlegen.
rsnapshot legt rotierende, inkrementelle Backups an und arbeitet dabei 
mit Hardlinks, d.h. nur das Delta zwischen zwei Backups wird übertragen 
(und belegt Speicherplatz).
Du kannst definieren dass du 7 tägliche Backups vorhalten möchtest und 
beim Erstellen des 8. wird das älteste Backup verworfen.
Das gleiche kannst du mit monatlichen/jährlichen Backups machen usw.
Und weil nur das Delta gesichert wird spielt es keine Rolle ob du 
tägliche Backups ziehst, dein Speicherverbrauch wird sich im Rahmen 
halten.

Im Prinzip kannst du das auch alles händisch mit rsync, cp -l usw. 
machen, aber es nimmt dir halt Arbeit ab.

Ich hab mir sogar noch eine ncurses-basierte TUI geschrieben die ich 
rsnapshot übergestülpt habe, aber das war mehr aus Spaß an der Freude 
;-)
Damit kann ich einzelnen Backups Kommentare zuordnen, mir einen 
Backup-Verlauf (sprich: log) darstellen lassen. Mir Anzeigen lassen ob 
die zu sichernden Hosts erreichbar sind. Darstellung des 
Speicherverbrauchs usw.

Bauform B. schrieb:
> Ich mag das, wenn
> ich eine einzelne Datei aus dem Backup einfach mit (s)cp zurückholen
> kann.

Das schätze ich auch sehr. Erst gestern habe ich wieder eine 
Konfigurationsdatei aus einem uralten Backup rausgekramt weil ich was 
nachschauen musste.
Als ich noch mehr mit Raspberries gemacht habe habe ich viel mit 
dd-basierten Backups experimentiert.
Aber das war mir alles zu umständlich bzw. zu "teuer" was den 
Speicherplatz betrifft. Und spätestens wenns darum geht die 
Datenpartition des fileservers zu sichern scheidet dd sowieso aus.
Ich mag aber ein einheitliches Vorgehen für alle zu sichernden Hosts.

: Bearbeitet durch User
von Eric (Gast)


Lesenswert?

Natürlich kann man das alles mit rsync machen. Von mir aus auch im 
laufenden Betrieb. Aber der TO wollte doch ein exaktes Abbild haben und 
das ist bei ext4 im laufenden Betrieb halt nicht gegeben. Mir würden bei 
den meisten Systemen sogar schon die Dotfiles und die Paketliste 
genügen. Datenbanken werden ohnehin 2x täglich per cronjob gesichert. 
Daten liegen ohnehin auf dem NAS (ZFS, Sicherung jede Nacht).

von foobar (Gast)


Lesenswert?

> Aber der TO wollte doch ein exaktes Abbild haben und das ist
> bei ext4 im laufenden Betrieb halt nicht gegeben.

Die snapshotfähigen Dateisysteme sind auch nur Augenwischerei.  Das 
Dateisystem mag korrekt sein, die Konsistenz der Anwendungsdaten können 
sie aber nicht sicherstellen.  Die wenigsten Anwendungen sind darauf hin 
gebaut worden, mitten im Betrieb abgeschossen und neugestartet zu werden 
(was anderes ist ein Snapshot und ein späterer Restore nicht).

Eine "sichere" Sicherung gibt es nur, wenn das System sauber 
runtergefahren ist.

von foobar (Gast)


Lesenswert?

Ich schrieb:
> Die snapshotfähigen Dateisysteme sind auch nur Augenwischerei.

Das bezieht sich auf den Snapshot im laufenden Betrieb.  Das soll nicht 
heißen, das sie nutzlos sind.  Sie können z.B. die Downtime drastisch 
verkürzen (switch to single-user mode, take snapshot, switch back to 
multi-user mode).

von (prx) A. K. (prx)


Lesenswert?

foobar schrieb:
> Die wenigsten Anwendungen sind darauf hin gebaut worden, mitten im
> Betrieb abgeschossen und neugestartet zu werden (was anderes ist ein
> Snapshot und ein späterer Restore nicht).

So selten ist das nicht. Gute Datenbanksysteme beispielsweise sind es.

von (prx) A. K. (prx)


Lesenswert?

foobar schrieb:
> Eine "sichere" Sicherung gibt es nur, wenn das System sauber
> runtergefahren ist.

So gesehen würden gerade die wichtigsten Systeme, wie etwa die deiner 
Bank, inhärent unsicher betrieben. ;-)

von Oliver S. (phetty)


Lesenswert?

Für einen Raspberry benutze ich:
https://github.com/framps/raspiBackup

Das kann ein Image auf einen USB-Stick schreiben oder ein Netzlaufwerk.
Im Crashfall kann man das Image dann auf eine neue SD-Karte schreiben 
und weitermachen. Das geht wohl eher für kleinere Systeme, einen 
kompletten Server würde ich so nicht sichern wollen.

Größere Server könnte man als VM laufen lassen und die dann "von unten" 
snappen.

von (prx) A. K. (prx)


Lesenswert?

Oliver S. schrieb:
> Größere Server könnte man als VM laufen lassen und die dann "von unten"
> snappen.

Macht man. Mit Veeam oder Nakivo beispielsweise. Da kommt man auch an 
Files aus den Backups ran, nicht nur an die kompletten Images.

Mit dem Datastore per NFS auf einem Snapshot-fähigen Filesystem 
funktionieren Image-Backups allen Unken zum Trotz auch recht gut.

: Bearbeitet durch User
von M.M.M (Gast)


Lesenswert?

Bauform B. schrieb:
> ●DesIntegrator ●. schrieb:
>> Ich vermisse bei Backup-Tips allzuoft den Hinweis
>> ein Backup auch zu testen.
>
> Auch das ist bei der rsync-Lösung trivial.

Nö, ist im vom TE genannten Kontext nicht trivial.

von ●DesIntegrator ●. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Lesenswert?

M.M.M schrieb:
> Bauform B. schrieb:
>> ●DesIntegrator ●. schrieb:
>>> Ich vermisse bei Backup-Tips allzuoft den Hinweis
>>> ein Backup auch zu testen.
>>
>> Auch das ist bei der rsync-Lösung trivial.
>
> Nö, ist im vom TE genannten Kontext nicht trivial.

ein vernünftig gesichertes System sollte einem schon was wert sein.

von Eric (Gast)


Lesenswert?

Echte COW Dateisysteme können dass. Da dauert das "Backup" dann auch nur 
1-2 Sekunden - auch im laufenden Betrieb.

foobar schrieb:
> Die snapshotfähigen Dateisysteme sind auch nur Augenwischerei.  Das
> Dateisystem mag korrekt sein, die Konsistenz der Anwendungsdaten können
> sie aber nicht sicherstellen.

von foobar (Gast)


Lesenswert?

Ich schrieb:
> Das Dateisystem mag korrekt sein, die Konsistenz der
> Anwendungsdaten können sie aber nicht sicherstellen.

Eric meint:
> Echte COW Dateisysteme können das.

Nein, können sie nicht!  Woher sollten sie wissen, wann die Daten einer 
Anwendung in einem konsistenten Zustand sind?  Das Dateisystem selbst 
ist ok, aber z.B. das erst zur Hälfte ausgepackte Archiv ist auch nur 
mit der Hälfte im Snapshot.

Die von prx erwähnten Datenbanken betreiben einen ziemlichen Aufwand, 
Anwendungen spezielle Funktionen zur Verfügung zu stellen, damit man 
mehrere Aktionen zu einer "transaction" zusammenzufassen kann, die dann 
nur komplett oder garnicht "committed" wird.  Auf der 
Kernel/Dateisystemeebene gibt es solche Funktionen nicht - da ist man 
schon froh über ein atomares Rename.

von (prx) A. K. (prx)


Lesenswert?

Eric schrieb:
> Echte COW Dateisysteme können dass. Da dauert das "Backup" dann auch nur
> 1-2 Sekunden - auch im laufenden Betrieb.

COW Filesysteme können von sich aus keinen konsistenten Zustand einer 
Anwendung sicherstellen, sondern nur des Filesystems selbst. Da muss 
schon die Anwendung selbst mitspielen. Sei es, indem sie von Haus aus so 
arbeitet, dass crash consistency auch application consistency darstellt. 
Sei es, indem es einen definierten System-Mechanismus gibt, der dies 
bewirkt, und in den sie sich einklinkt (siehe VSS in Windows). Sei es, 
indem entsprechende Scripte ausgelöst werden.

In VMware gibt es 2 zusätzliche Optionen, Snapshots zu erstellen. Bei 
"memory" wird der vollständige Zustand der VM gesichert, mit dem die VM 
an exakt der gesicherten Stelle weiterläuft, als wäre nichts geschehen. 
Bei "quiesce" geschieht das, was ich im vorigen Absatz erwähnt.

Eine Methode für Backups auf Basis von COW-Snapshots besteht als darin, 
von allen VMs auf dem Datastore einen temporären VMware-Snapshot mit 
"quiesce" Option anzulegen. Dann wird der Datastore snapshotted, 
anschliessend werden diese temporären VMware-Snapshots wieder 
weggeräumt.

https://www.reddit.com/r/vmware/comments/49flgc/snapshots_quiesce_or_memory_state/
https://kb.vmware.com/s/article/2044492

: Bearbeitet durch User
von oszi40 (Gast)


Lesenswert?

Genau das ist ein wunder Punkt, den man erst in Ernstfall bei der 
Wiederherstellung merkt. Viele Daten sichern heiß noch nicht, dass sie 
hinterher noch einem brauchbaren Zustand sind. Manche DB ist dann 
einfach kaputt. Beim ICE wechselt auch keiner die Räder während der 
Fahrt. :-)

von (prx) A. K. (prx)


Lesenswert?

Was ich vorhin über VMware schrieb, das geht natürlich auch ohne VMware. 
Die betroffene Anwendung wird in den "Backup-Modus" versetzt, in dem sie 
zwar weiterarbeitet, aber in entsprechend veränderter Weise. Dann gibts 
den COW Snapshot. Anschliessend läuft die Anwendung wieder normal - und 
räumt dabei evtl den Zwischenzustand auf.

Das ist aber nur eine Variante genereller Backup-Mechanismen und weder 
wirklich neu, noch inhärent mit Image-Backups verbunden. Denn ob man die 
Anwendungsdaten per VM Snapshot sichert, ob per COW Snapshot, oder ob 
man die von der Anwendung eingefrorenen Files auf konventionelle Art 
sichert, unterscheidet sich hauptsächlich in der Laufzeit des Backups.

Unabhängig davon ist es allerdings sinnvoll, eine Anwendung so zu 
konstruieren, dass sie nach einem Crash der Plattform nicht im Eimer 
ist, sondern auf einem nutzbaren Zustand wieder aufsetzt. Das macht dann 
nämlich am wenigsten Arbeit. Das kann beispielsweise bedeuten, dass man 
ein Dokument nicht einfach überschreibt, sondern daneben neu schreibt 
und die Files danach umbenennt. Eine Art COW auf Anwendungsebene.

: Bearbeitet durch User
von Eric (Gast)


Lesenswert?

(prx) A. K. schrieb:
> COW Filesysteme können von sich aus keinen konsistenten Zustand einer
> Anwendung sicherstellen, sondern nur des Filesystems selbst.

Ich habe mich ja auch nur auf das FS bezogen. Um einen konsistenten 
Zustand einer Anwendung sicherzustellen, muss die Anwendung zunächst 
angewiesen werden, die Daten im RAM auf die Platte zu schreiben. Das 
passiert unter anderem bei sqldump.

von P. Loetmichel (Gast)


Lesenswert?

Profis machen ihr Backup mit ufsdump.

von Eric (Gast)


Lesenswert?

P. Loetmichel schrieb:
> Profis machen ihr Backup mit ufsdump.

Nur solche die noch Solaris nutzen;)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.