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.
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.
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.
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.
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.
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.
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.
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?
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.
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).
> 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.
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).
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.
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. ;-)
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.
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.
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.
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.
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.
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.
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
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. :-)
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.
(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.
