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.
:
Bearbeitet durch User
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.
Super, vielen Dank! Jetzt ärgere ich mich nur das ich das System auf ext4 installiert habe... :)
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.
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...
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
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
Ich vermisse bei Backup-Tips allzuoft den Hinweis ein Backup auch zu testen. nur "eben mal sichern" ist wie die Katze im Sack.
●DesIntegrator ●. schrieb: > Ich vermisse bei Backup-Tips allzuoft den Hinweis > ein Backup auch zu testen. Auch das ist bei der rsync-Lösung trivial.
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
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
(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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.