Desaster-Recovery einer KVM-UCS-Umgebung mit Bareos & Relax-Recover

pixel · October 29, 2018, 7:51am

Hallo zusammen,

mein Umgebung hat, wie sich zeigte, noch einige Defizite was die Datensicherung angeht bzw die Möglichkeit der Wiederherstellung bei einem Total-Ausfall.

Die Umgebung:

UCS-Backup als KVM-Host mit UVMM
UCS-Master als KVM-VM auf Host
UCS-Member als KVM-VM auf Host
Synology NAS in getrennten Gebäude (via WLAN) für externes Backup

Das Bareos-Backup habe ich auf dem KVM-Host angesiedelt. Dort ist auch ein gesondertes RAID5-Volume unter /backup gemountet. Hierein wird gesichert. Die Pfade habe ich nach der Bareos-Installation im App-Center entsprechenden angepasst. Was hierbei aber unter ging ist dass hier lediglich die Volumes rein geschrieben werden jedoch keine Bootstrap.

Das macht eine Wiederherstellung, wenn die Backup-Umgebung komplett weg ist und lediglich dasd Backup-Volume existiert extrem aufwendig.

Ist das so beabsichtigt oder was würde denn dagegen sprechen wenn nach dem setzen des Storage-Pfads die Bootstrap-File sowie ein Dump der Bareos-DB ebenfalls in diesen Pfad geschrieben wird? … Wie auch immer. Ob nun durch setzen des Pfades oder durch manuelle Konfiguration. Das macht Sinn sol, oder?

Mit diesen Rahmenbedingungen muss ich eine Lösung realisieren. So lange der Backup-Server läuft ist alles schick. Jemand löscht oder verändert Dateien, ich sichere diese einfach mit Bareos zurück. Das hat schon oft super geklappt. Aber wie gesagt. Wenn alles ausfällt ist dass echt ein Desaster.

Im Bareos-Handbuch finde ich einen Verweis auf Relax&Recover für diesen Fall. Ich habe mir auch schon die Webseite angeschaut bzw. bin dabei. Was ist hier das Konzept und wie ergänzt man damit Bareos? Das ist mir nicht ganz klar.

Hat jemand von Euch solch eine Umgebung (KVM mit UCS). Wie sichert Ihr?

Oder habe ich einen Fehler im Konzept und muss hier Änderungen vornehmen?

Viele Grüße
Sven

Moritz_Bunkus · November 5, 2018, 10:08am

Huhu,

zu Bareos kann ich nicht viel sagen, weil es Ewigkeiten her ist, dass ich es produktiv eingesetzt hatte (damals noch als Bacula).

Generell sind Backups, die auf dem selben physikalischen Server landen, keine sonderlich gute Idee, weil es zu wahrscheinlich ist, dass durch einen Festplattenausfall[1] dann wirklich alle Daten weg sind — inklusive des Backups. Natürlich ist es schön, wenn Daten physikalisch nah sind und eine Wiederherstellung dann schnell geht, aber es ist auch erheblich unsicher.

Was man natürlich machen kann, ist zwei Backups zu haben: einmal physikalisch nah (z.B. selber Server, lokales NAS) und zusätzlich ein Off-Site-Backup für mehr Sicherheit. Das ist genau das, wie ich das inzwischen meist fahre.

Womit wir dann beim Thema »welche Software« wären. Ich nutze Borg Backup sowohl für meine physikalisch nahen Backups als auch meine Off-Site-Backups. Warum?

Borg unterstützt clientseitige Verschlüsselung, wodurch ich mir über Sicherheit der Off-Site-Backups keine Gedanken machen muss.
Borg unterstützt von Haus aus ACLs und erweiterte Attribute (super wichtig! Samba nutzt beides zum Speichern von NT-ACLs!), unabhängig davon, auf welchem Dateisystem die Backupdateien liegen (z.B. kann alles rsync-basierte wie rsnapshot oder dirvish da nicht mithalten, weil die üblichen Netzwerkdateisysteme wie NFS und CIFS erweiterte Attribute ordentlich transportieren, und zusätzlich bieten viele NASse wie Synology Diskstation nicht mal brauchbaren Support für ACLs über NFS).
Borg wird inzwischen von Hostern als Gegenstelle explizit unterstützt. So kann man z.B. bei Hetzner eine StorageBox mieten und direkt darauf per Borg via ssh Backups erstellen — kein zusätzlicher Server nötig, sicherer Transport und durch Borgs Verschlüsselung sichere Ablage. Das soll keine Werbung für besagten Hoster sein, sondern aufzeigen, wie einfach das inzwischen wird.
Borg unterstützt und nutzt standardmäßig clientseitige Deduplizierung und Kompression von Daten, wodurch es super platzeffizient ist (sogar viel effizienter als rsync-Hardlink-basierte Sachen wie z.B. dirvish, wie meine Praxis gezeigt hat). Dadurch, dass das schon clientseitig passiert, wird auch die zu transportierende Datenmenge deutlich reduziert. Deduplizierung auf Blockebene bedeutet weiterhin, dass Borg auch solche Dateien effizient sichern kann, die selber sehr groß sind, aber wo sich nur wenige Teile ändern.
Borg nutzt zwar clientseitiges Caching von Metadaten, aber selbst wenn die weg sind (Stichpunkt Disaster Recovery), braucht man nur den Borg-Client sowie die Verschlüsselungsinfos (die muss man gesondert sichern! Sind die mal weg, kommt man nicht mehr an die Daten ran) und kann sofort alles wiederherstellen, ohne langwierig eine Datenbank neu aufbauen zu müssen. Borg lädt die Metadaten automatisch neu herunter, falls der Cache mal weg sein sollte.
Als reinrassiges Kommandozeilentool lässt sich Borg wunderbar komplett scripten. Hat aber auch den Nachteil, dass man anfangs etwas Arbeit investieren muss, bis alles schön läuft inklusive E-Mail-Benachrichtigungen, automatischem Löschen alter Backups etc.

Aufgrund dieser ganzen Punkte kann ich Borg sowohl für mein physikalisch nahes Backup (z.B. auf ein NAS, dessen Dateisystem ich per CIFS gemountet habe) als auch für mein Off-Site-Backup (via ssh auf einen irgendwo stehenden Server) nutzen, was mir wiederum die Administration deutlich vereinfacht.

Deine zukünftige Lösung muss nicht zwangsläufig Borg sein. Aber geh bloß von den Backups auf dem gleichen Server weg…

Gruß
mosu

[1] RAID 5 ist heutzutage keine Sicherheit mehr. Bei mir selber und bei dreien meiner Kunden hatte ich inzwischen den Fall, dass nach Ausfall einer Platte eine neue eingeschoben wurde, und während des Rebuilds fiel eine zweite Platte aus. Damit war der komplette Inhalt hin. Warum das nicht verwunderlich ist? Weil normalerweise alle Platten im RAID-Verbund gleich alt und gleich abgenutzt sind. Und je größer die Platten, desto länger dauert ein Rebuild, während dessen alle Platten stark belastet werden. RAID 6 or bust.

pixel · November 7, 2018, 12:57pm

Danke für die ausführliche Info. Ja, das Backup ist auf der gleichen Maschine aber auf einem gesondertem Volume, sprich ein weiterer RAID-Verbund.

Wie Du sagst möchte ich jetzt noch ein Backup das räumlich getrennt ist. Borg werde ich mir dafür anschauen, das klingt gut für meinen Fall. Habe es jetzt übergangsweise mal mit rsync gemacht.

Eines meiner schwierigsten Probleme ist derzeit das sichern der qcow2-Files, also der Festplatten-Images der VM’s. Wie ich die am einfachsten weg sicher.

Das habe ich hier:

gepostet. Mein Verständnis-Problem mit den LVM-Snapshots ist (kann auch an meinem Englisch liegen!) ist dass die eigentlichen QCOW2-Files ja keine LV’s sind sondern lediglich im /var auf dem Host liegen was wiederum ein LV ist.

Die müsste ich noch irgendwie weg sichern. Dann wäre ich schonmal gut aufgestellt.

Gruß
Sven

Moritz_Bunkus · November 7, 2018, 1:15pm

Huhu,

Storage-Dateien von Virtualiserern darf man nicht einfach so wegkopieren. Da gibt’s grundsätzlich zwei Probleme:

Die Datei könnte sich durch die laufende Maschine ändern, während der Kopiervorgang läuft.
Innerhalb der Maschine läuft Software, die Daten in ihren Caches hat, die noch nicht in die Storage-Datei geschrieben wurde. Das sind nicht nur z.B. Datenbanken wie MySQL, sondern vor allem der Kernel selber, der diverse Dateisystemstrukturen im Speicher und noch nicht in der Storage-Datei hat.

Würde man das ignorieren und ein Backup so einer Datei wiederherstellen, so würde man sich gravierende Dateisystemschäden und Datenverlust einhandeln.

Für beides benötigt man Lösungen. Nein, ein LVM-Snapshot des Dateisystems in dem die Storage-Dateien liegen, hilft hier gar nicht weiter.

Es gibt diverse Schritte, mit denen man das Ganze sicher erledigen kann. Die haben alle nichts mit Univention zu tun, sondern rein mit libvirt. Ich empfehle mal Googlen nach z.B. kvm backup qcow2 of running vms.

Einer der interessantesten und besten Treffer ist KVM live & incremental VM backup with BORG, der sich auch schön mit meiner Empfehlung für Borg übereinstimmt. Aufgrund der blockbasierten Deduplizierung eignet sich Borg ziemlich gut fürs Sichern von ganzen VM-Storage-Dateien.

Trotzdem sollte darüber nachgedacht werden, nicht die Storage-Dateien selber zu sichern, sondern innerhalb der VM selber ein Backupprogramm wie Borg einzurichten. Der große, große Nachteil der Sicherung der kompletten Storage-Datei ist, dass es unmöglich (oder zumindest sehr aufwändig) ist, einzelne Dateien wiederherzustellen.

Gruß
mosu

pixel · November 24, 2018, 7:59am

Danke schon mal für die Info und Sorry für die späte Rückmeldung.

Ja, denke und weiß dass es kein UCS Problem ist. Ich habe eines nicht erwähnt was die Sache eventuell vereinfacht …

Die VM’s nüssen nicht im laufenden Betrieb gesichert werden
In den VM’s läuft ein Bareos-Client, die qcow2 File möchte ich zusätzlich in anderes Genäude und um schnell eine VM wiederherzustellen

Gibt es hier nicht ein Skript oder Programm:

VM herunterfahren -> qow2-File weg schreiben -> VM wieder hochfahren

pixel · November 24, 2018, 8:37am

Und wenn sie doch im laufenden Betrieb gesichert werden dürfte ja diese Option:

--quiesce Libvirt will try to use guest agent to freeze and unfreeze domain’s mounted file systems. However, if domain has no guest agent, snapshot creation will fail.

Was genau ist mit “Guest-Agent” gemeint ? Ich habe als VM’s:

UCS
Windows7 / 10

Muss ich auf diesen etwas spezielles installieren?

pixel · November 24, 2018, 11:28am

Ich habe mir sowohl den Link von dir wie auch:

https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit

angeschaut. Im grundsatz ist die Vorgehensweise ja gleich:

Externer Snapshot wird erstellt
Laufendes System schreibt Änderungen in Snapshot
Man kann dir “Orginal-QCOW2-Files” weg sichern
Die im Snapshot aufgelaufenen Änderungen werden ins Orgina commitet

Zumindest habe das so verstanden. Hbe es auch hier mal getestet.

Meine VM “tux”:

virsh # domblklist tux
Target     Source
------------------------------------------------
vda        /var/lib/libvirt/images/tux_disk1.qcow2
vdb        /var/lib/libvirt/images/tux_disk2.qcow2

Anschließend die Snapshots für beide virtuellen Platten erstellt:

virsh snapshot-create-as --domain tux --atomic --disk-only --diskspec vda,file=/mnt/usbdisk/tux_disk1.qcow2 --diskspec vdb,file=/mnt/usbdisk/tux_disk2.qcow2

Die Option " --quiesce" hatte ich anfänglich auch im Aufruf aber dieser führte zu:

error: argument unsupported: QEMU guest agent is not configured

Noch ein Unterschied zwischen den beiden Seiten ist dass im Wiki von Libvirt die Option “–no-metadata” NICHT gesetzt wird. Da ist mir nicht ganz klar was diese bewirkt bzw. was für Metadaten es sind.

Ich habe dann, während die Snapshots als Overlay aktiv waren am System Veränderungen vorgenommen und Daten auf die Datenpartition (vdb) kopiert. Dabei konnte man beobachten wie die Overlays anwachsen.

Am Ende habe ich dann die Files mit:

virsh blockcommit tux vda --active --verbose --pivot
virsh blockcommit tux vdb --active --verbose --pivot

zusammen geführt und die Snapshots gelöscht.

Was ich nun nicht eischätzen kann ist ob die von dir angesprochene Problematik “Daten die innerhalb der VM noch anstehen und nicht auf der Disk sind” erfolgreich umschifft wurde und alles konsisten ist? Dann wäre das für mich eine brauchbare Lösung.

Viele Grüße
Sven