Externe verschlüsselte Backups anlegen - Konsistenz?

[trendco]

Als zusätzlichen Schutz gegen Diebstahl, Brand, etc. möchte ich in regelmässigen Abständen noch externe verschlüsselte Backups bei meinem Web-Hoster ablegen. Das ganze löse ich mit Borg Backup: https://wiki.ubuntuusers.de/BorgBackup/ (Webspace per SSHFS rein mounten)

Momentan bin ich noch am überlegen, wie ich die VM's am besten konsistent sichern kann, vor allem wenn in manchen VM's Datenbanken laufen (MySQL, MSSQL). Am sichersten wäre vermutlich die VM's alle runter zu fahren, dann einen ZFS-Snapshot zu machen, VM's wieder starten und dann das Backup laufen zu lassen (Sicherung des ZFS-Snapshots). Allerdings gefällt mir diese Variante irgendwie nicht wirklich, denn Hänger beim herunterfahren der VM's könnten auftreten und eine gewisse Downtime ist dann eben auch da.

Meine Überlegung nun: Einen QM-Snapshot inkl. RAM von jeder VM anlegen mit "qm snapshot ID SNAPNAME --vmstate", dann einen ZFS-Snapshot vom Filesystem machen und anschliessen das Backup machen vom ZFS-Snapshot.

Wäre das denn eine sichere Lösung für konsistente Backups?
Oder müsste man die VM's vor dem QM-Snapshot erst noch suspenden?

 

[wolfgang]

Hi,

wenn du die VM nicht ausschalten willst/kannst wegen downtime,
würde ich dir auf alle falle empfehlen "Qemu Guest Agent" zu verwenden.
Der führt in der VM ein FS freeze aus was bei Windows den vss anspricht.
Es gibt den beim vss auch eine extra Implementierung für MSSQL.

siehe
https://pve.proxmox.com/wiki/Qemu-guest-agent


Was du auch machen kannst ist unsere "backup hocks" verwenden siehe
/usr/share/doc/pve-manager/examples/vzdump-hook-script.pl
und
man vzdump -> scripts

damit kannst du zum Beispiel den SQL Servern miteilen das ein Backup erstellt wird.

 

[trendco]

Mit dem "Qemu Guest Agent" möchte ich eigentlich nicht arbeiten, damit habe ich an anderer Stelle schon ein Problem.

Ginge denn die von mir erwähnte Variante auch?

 

[LnxBil]

Ob die Backups nun extern sind oder nicht ist ja erstmal egal für die Frage wie du aktuell denn überhaupt Backups machst? Die asynchron irgendwohin zu schieben ist für das Konsistenzproblem irrelevant.

Warum genau hast du Probleme mit dem qemu-agent? Kannst dir in den agent selbst einen hook reinschreiben, der z.B. ein logswitch durchführt und synct, dann bist du zum Zeitpunkt wenigstens crash-konsistent. Musst halt schauen was für ne DB engine in MySQL verwendest du wie gut das dann klappt. Datenbanken sichert man normalerweise ja eh über die Datenbank-Tools (und nein, ich meine keinen dump). Ich würde dir primär das vorschlagen. Du könntest z.B. einen Cold-Standby-aufbauen, der z.B. alle 15 Minuten die Replikation startet. So hättest du immer einen konsistenten Zustand der DB.

 

[tschanness]

Wo anders habe ich das mit einem DB snapshot gelöst. Sobald ein Backup der VM gestartet wird macht der zuerst einen snapshot der DB.

Jonas

 

[trendco]

Ich muss die Sache noch mal aufgreifen, auch für mein Verständnis:

Wenn ich einen QM-Snapshot inkl. RAM von einer VM anlege mit "qm snapshot ID SNAPNAME --vmstate", dann ist doch in dem Moment alles Konsistent oder nicht? Dann wird ja das System kurz eingefroren, d.h. Festplatte und der RAM. Somit dürfte es doch selbst bei Datenbank-Geschichten keinerlei Probleme geben, oder denke ich da falsch?

 

[LnxBil]

Richtig. Das ist aber eben kein Backup, sondern ein Snapshot mit RAM-Inhalt. Snapshots werden nicht beim "normalen" Backup berücksichtigt, da musst du dich dann selbst drum kümmern.

 

[fabian]

Ich muss die Sache noch mal aufgreifen, auch für mein Verständnis:

Wenn ich einen QM-Snapshot inkl. RAM von einer VM anlege mit "qm snapshot ID SNAPNAME --vmstate", dann ist doch in dem Moment alles Konsistent oder nicht? Dann wird ja das System kurz eingefroren, d.h. Festplatte und der RAM. Somit dürfte es doch selbst bei Datenbank-Geschichten keinerlei Probleme geben, oder denke ich da falsch?

das kommt darauf an was du mit konsistenz meinst. konsistenz auf dateisystem ebene - ja. konsistenz auf applikationsebene - hängt von der applikation ab.

 

[trendco]

Kannst Du mir mal ein Praxis Beispiel nennen wo das dann ein Problem sein könnte?
Ich rätsel da gerade rum....

 

[fabian]

Kannst Du mir mal ein Praxis Beispiel nennen wo das dann ein Problem sein könnte?
Ich rätsel da gerade rum....

immer dann, wenn applikationen daten in teilen schreiben aber nicht damit zurecht kommen wenn nicht alle teile tatsächlich geschrieben sind. richtig geschriebene programme stellen das (wenn notwendig) sicher.

 

[trendco]

Aber wie könnte das denn passieren bei einem Snapshot wo Filesystem inkl. RAM eingefroren werden? Die Anwendung hätte doch dann den noch nicht gesschriebenen Teil auch im RAM?

 

[tschanness]

Datenstream übers netzwerk, der teilweise auf Disk ist, Teilweise im Ram, teilweise aber zum Snapshot noch nicht angekommen ist. Eher selten anzutreffen, aber nicht ganz auszuschliessen..

J.

 

[fabian]

Aber wie könnte das denn passieren bei einem Snapshot wo Filesystem inkl. RAM eingefroren werden? Die Anwendung hätte doch dann den noch nicht gesschriebenen Teil auch im RAM?

korrekt, hatte das "inklusive RAM" einfach überlesen. tut mir leid für die verwirrung.. wie @tschanness richtig geschrieben hat bleiben damit nur mehr so sachen wie netzwerk state, durchgereichte physische geräte o.ä. übrig, was sich nur mit komplett runterfahren und dann sichern ausschließen lassen würde.

 

[trendco]

Sehr schön. Dann würde ja meine oben genannte Variante funktionieren:

- PVE Snaposhot inkl. RAM
- ZFS Snapshot vom PVE Filesystem
- Backup per (eigen) Script, welches auch den/die Snapshot File(s) und die Konfig der VM unter "/etc/pve/qemu-server" mitsichert

Bzgl. dem ZFS Snapshot: Das ganze geht natürlich nur wenn Proxmox wie bei mir mit ZFS (rpool) installiert ist und dort auch die VM's liegen, oder eben ein anderer ZFS Storage vorhanden ist.



BTW: Gibt es beim "normalen" Backup eine Möglichkeit/Parameter, die Snapshots auch mit zu sichern? Hab da nix gefunden.

 

[fabian]

Sehr schön. Dann würde ja meine oben genannte Variante funktionieren:

- PVE Snaposhot inkl. RAM
- ZFS Snapshot vom PVE Filesystem
- Backup per (eigen) Script, welches auch den/die Snapshot File(s) und die Konfig der VM unter "/etc/pve/qemu-server" mitsichert

aber in diesem Fall würde es ja reichen, folgendes zu machen (siehe aber den Hinweis bezüglich eigener Backupstrategie am Ende des Posts!):

1. Snapshot inkl. RAM vom zu sichernden Gast
2. Snapshot + VMState Volume + VM-Config per eigenem Skript sichern

je nach Storage ist es unterschiedlich, ob und wie du an den Snapshot(-inhalt) ran kommst.

Snapshots sind in ZFS z.B. keine herkömmlichen Files, können aber optional als Ordner (bei Datasets) oder Blockdevice (bei ZVols) exportiert und damit auch auf nicht ZFS Dateisysteme kopiert werden. alternativ bietet ZFS mit zfs send/receive auch einen sehr komfortablen Mechanismus, um ZFS Datasets zwischen verschiedenen Pools "zu verschicken". letzteres geht auch als Export/Import (zfs send in eine beliebige Datei, zfs receive gefüttert mit eben dieser Datei) und über Hostgrenzen hinweg (zfs send | ssh ... zfs receive), und wird z.B. von pve-zsync zur asynchronen Replizierung verwendet.

Bzgl. dem ZFS Snapshot: Das ganze geht natürlich nur wenn Proxmox wie bei mir mit ZFS (rpool) installiert ist und dort auch die VM's liegen, oder eben ein anderer ZFS Storage vorhanden ist.

korrekt - ZFS Snapshot ohne ZFS geht nicht

BTW: Gibt es beim "normalen" Backup eine Möglichkeit/Parameter, die Snapshots auch mit zu sichern? Hab da nix gefunden.

falls du mit "normalem" Backup VZDump meinst, gibt es so eine Möglichkeit nicht. VM/Container-Snapshots und VZDump-Backups sind in PVE orthogonal, auch wenn manche VZDump-Backup Modi intern einen temporären Snapshot zur Konsistenzsicherung verwenden du kannst natürlich deine eigene Backupstrategie basierend auf z.B. ZFS Snapshots machen (gibt hier im Forum einige Leute die das tun), allerdings musst du dich dann eben um die korrekte Umsetzung dieser Strategie inkl. Restoremöglichkeit kümmern.

 

[trendco]

Snapshot + VMState Volume + VM-Config per eigenem Skript sichern

Was meinst Du mit "VMState Volume"?
Den .raw File der den RAM abbildet?


ZFS send/receive ist klar, aber ich habe ja im ersten Post gesschreiben das es hier um ein zusätzliches externes, verschlüsseltes Backup geht. Dazu mounte ich das Webdrive meines Hosters per sshfs und mache das Backup mit "Borg Backup".
Trotzdem gute Ausführung, hilft dem ein oder andern vielleicht wenn er hierüber stolpert

 

[fabian]

Was meinst Du mit "VMState Volume"?
Den .raw File der den RAM abbildet?

ja - der RAM-Inhalt wird je nach Storagekonfiguration unterschiedlich gespeichert, deswegen hab ichs so allgemein formuliert. im Snapshot in der VM-Konfiguration ist ersichtlich, wo es liegt - und dann ist wahrscheinlich auch klar, wie es kopiert werden kann.

ZFS send/receive ist klar, aber ich habe ja im ersten Post gesschreiben das es hier um ein zusätzliches externes, verschlüsseltes Backup geht. Dazu mounte ich das Webdrive meines Hosters per sshfs und mache das Backup mit "Borg Backup".
Trotzdem gute Ausführung, hilft dem ein oder andern vielleicht wenn er hierüber stolpert

wie gesagt, zfs send geht auch in eine Datei auf einem beliebigen Dateisystem, und anschließend lässt sich mit zfs receive der Inhalt wieder in einen ZFS Pool zurückspielen (allerdings ohne diesen Schritt nicht direkt auslesen ). aber ZFS lässt das (R/O) mounten von Snapshots ohnehin zu, dann lassen sich die Inhalte quasi mit beliebigen Backuptools sichern. damit bist du halt schon weit entfernt von der in PVE integrierten VZDump Backuplösung.

 

[trendco]

Dann geh ich das mal an...

 

[LnxBil]

Dann geh ich das mal an...

Ich kenne keine Virtualisierungslösung und auch keine Backup-Lösung die das so (kompliziert) macht. Die meisten "korrekt" geschriebenen Programme haben einen Backup-Modus, bei dem man die Anwendung dazu bringt einen konsistenten Zustand zu schreiben und dann ein OK zurückmeldet. Dies passiert z.B. bei Exchange und MSSQL wenn man Volumenschattenkopie verwendet. Die Technik ist somit prima, da der VSS vom qemu-agent beim Proxmox VE Backup aus getriggert wird und somit "magisch" ein konsistentes online-Backup möglich ist.

Wie bereits vorher geschrieben kann man unter Linux auch mittels qemu-agent hooks z.B. einen Logswitch und ein paar syncs vor dem Backup machen und somit die Datenbank in einen konsistenten Zustand zu überführen. Alle aktuell andauernden und noch nicht abgeschlossenen Transaktionen werden natürlich nicht auf die Platte geschrieben und sind auch in einem RAM-Snapshot der wiederhergestellt wird nur dann noch aktiv und lebensfähig wenn keine Netzwerkkomponenten mitspielen. Bei diesen Speicherabbildern kann es auch zu Problemen mit der spontanen Zeitumstellung kommen.

Das Problem was du zu lösen versuchst ist eigentlich schon so alt wie die IT. Mittlerweile hat man das Problem eigentlich gut im Griff, da die Hersteller erkannt haben, dass sie sich selbst am Besten und auch als Einzige um das Problem eines konsistenten Backups kümmern können (im Prinzip das was @fabian gesagt hat).

Du musst dir überlegen, wann du dein Snapshot-Backup benötigst und was du damit machen kannst bzw. was du danach noch machen musst um wieder auf einem aktuellen Stand zu sein. Das reine Backup alleine bringt normalerweise nichts außer von 0 auf "man hat etwas" zu kommen (Disaster Recovery), dann muss man eigentlich immer (es sei den du hast ein Backup eine Sekunde vor dem Crash) ein konsistentes Datenbankbackup (was man natürlich auch immer noch erstellen muss) nehmen und die Datenbank dementsprechend nachfahren bis zum aktuellen Punkt, denn gearbeitet wird immer und alte bzw. nicht aktuelle Daten sind oft so wenig zu gebrauchen wie keine. Das ist natürlich abhängig von der Last des Systems, aber wenn du keine Last auf dem System hast ist es auch nicht schwer einen konsistenten Zustand zu speichern. Die Wahrscheinlichkeit diesen beim "normalen" Crash-konsistenten Backup ohne Techniken wie VSS zu erhalten sind recht hoch.

Ich will das jetzt nicht schlecht reden was du vor hast, aber in meiner Erfahrung sollte fast alle Energie investiert werden, dass das Disaster-Recovery auf keinen Fall notwendig wird und das geht am kosteneffizientesten mit einer anwendungsspezifischen und oft bereits eingebauten Replikation wie z.B. bei Datenbanken mit archivierten Redo Logdateien/WALs oder wie auch immer der Term in der verwendeten Datenbank gerade ist. Ich würde hier eine Replikation in eine andere VM machen, die auf einem anderen Knoten oder gleich anderen Cluster läuft. Wiederanlaufzeit bei einem Problem ist dann im Zeitfenster der Replikationsfrequenz und ist das kosteneffizienteste was ich mir vorstellen kann.

 

[trendco]

Danke für Deine detailierte Ausführungen.

In dem geannten Fall geht es allerdings um ein W7 System an dem nur tagsüber von den Clients aus gearbeitet wird. Bei Nacht wenn das Backup läuft , wird die MySQL DB eigentlich nie angeprochen. Das einzige was nachts auch läuft, ist der interne Email Server der Mails zyklisch vom Provider abholt. Somit dürfte das ganze hier eigentlich kein Problem darstellen.