Konsistente Sicherung: Snapshots und Hooks

Zum Inhaltsverzeichnis

Ein Volume, das gerade benutzt wird, zum Beispiel die Platte einer laufenden virtuellen Maschine, ändert sich, während es gelesen wird. Das Abbild passt dann zu keinem Zeitpunkt. Deshalb macht der Agent bei einem LVM-Volume zuerst einen Snapshot, sichert diesen und entfernt ihn danach wieder. Das gilt für normale (thick) und für Thin-Volumes.

5.1 LVM-Snapshots#

# Standard (--snapshot auto): ist die Quelle ein LVM-Volume, wird ein Snapshot verwendet
bkp_agent --source /dev/vg0/icinga.disk --out /backup --name icinga

Zeigt --snapshot on auf eine Quelle ohne LVM, bricht der Agent ab:

Ausgabe:

[bkp_agent] ERROR --snapshot on: data.img is not an LVM logical volume
[bkp_agent] ERROR backup failed (see the message above)

5.1.1 Was zu beachten ist#

• Läuft der Platz für Änderungen (--snapshot-size) während der Sicherung voll, wird der Snapshot ungültig. Der Agent bricht dann ab und veröffentlicht nichts. Bei stark beschriebenen Volumes den Wert erhöhen.
• Pro Volume läuft immer nur ein Agent; ein zweiter meldet das und bricht ab.
• Nach einem Absturz übrig gebliebene Snapshots (<volume>_bkpsnap, mit dem LVM-Tag bkp_agent) räumt der nächste Lauf auf. Ein Volume gleichen Namens ohne dieses Tag wird nie angefasst.
• Im Run und im Monitor steht weiter das Original-Volume, nicht der Snapshot. Die Deduplizierung gegen frühere Runs funktioniert wie gewohnt.
• Bei einer fortsetzbaren Netzwerk-Sicherung bleibt der Snapshot nach einem Absturz gezielt stehen, statt sofort entfernt zu werden — siehe „Ausfallsichere Netzwerk-Sicherung“ in Kapitel 4.

5.2 Hooks: Gast einfrieren#

Ein Snapshot ist *absturzkonsistent*, als wäre der Strom ausgefallen. Journaling-Dateisysteme und Datenbanken mit Transaktionslog (SQL Server, PostgreSQL, MySQL/InnoDB) kommen damit in der Regel zurecht. Was eine Anwendung noch im eigenen Speicher hält, fehlt aber. Für *anwendungskonsistente* Sicherungen muss der Gast vor dem Snapshot seine Puffer zurückschreiben und kurz stillstehen. Das erledigen die Hooks. Sie sind absichtlich nicht an einen Hypervisor gebunden.

Cronjob mit Einfrieren des Gastes (libvirt/QEMU-Gast-Agent)

bkp_agent --source /dev/vg0/icinga.disk --target backup.example.org:9990 --target-dir vm1 \
          --tls-ca /etc/bkp/target.crt --api-key file:/etc/bkp/vm1.key --name icinga \
          --pre-snapshot  'virsh domfsfreeze icinga' \
          --post-snapshot 'virsh domfsthaw icinga'

Die Hooks bekommen BKP_SOURCE (Original-Volume), BKP_NAME, BKP_SNAPSHOT (Snapshot-Gerät) und BKP_PHASE (pre oder post) in der Umgebung. Der Agent meldet, wie lange der Gast zwischen Pre- und Post-Hook stillstand (consistency window), meist wenige Sekunden. Der Gast bleibt nur so lange eingefroren, wie zwischen den beiden Hooks vergeht; der Post-Hook läuft auch bei Fehlern, Zeitüberschreitung und SIGTERM.

Einfrieren per SSH: Den Gast immer über die Verbindung auftauen, die beim Einfrieren geöffnet wurde (SSH-Multiplexing). Eine *neue* Anmeldung an einem eingefrorenen Gast kann hängen, auf einem Debian-Gast schon nach etwa 20 Sekunden, weil der Gast beim Anmelden auf sein eingefrorenes Dateisystem schreiben will. Der Post-Hook kommt dann nicht durch, und der Gast bleibt eingefroren. Über die offene Verbindung taut er auch nach langem Einfrieren sofort auf. Mehrere Dateisysteme in umgekehrter Reihenfolge auftauen.

Xen-Domain mit Linux-Gast, per SSH eingefroren und über dieselbe Verbindung aufgetaut

O="-o ControlMaster=auto -o ControlPath=/run/bkp-freeze-%h -o ControlPersist=300"
bkp_xenV --name web01 \
    --pre-snapshot  "ssh $O root@web01 'fsfreeze -f /data; fsfreeze -f /'" \
    --post-snapshot "ssh $O root@web01 'fsfreeze -u /; fsfreeze -u /data'; ssh $O -O exit root@web01" \
    -- --sink backup

Bei Windows-Gästen übernimmt der QEMU-Gast-Agent das Einfrieren über VSS. Damit werden VSS-fähige Anwendungen wie SQL Server sauber angehalten; Anwendungen ohne VSS-Writer werden nur absturzkonsistent gesichert.

5.3 Windows: VSS-Schattenkopie#

bkp_agent.exe sichert ein Volume (\\.\C:) oder eine ganze Platte (\\.\PhysicalDrive0) von einer VSS-Schattenkopie und braucht dafür Administratorrechte. Die Optionen --snapshot, --pre-snapshot, --post-snapshot und --hook-timeout gelten wie unter Linux (Hooks laufen über cmd.exe).

Windows: Laufwerk C: per VSS sichern (Eingabeaufforderung als Administrator)

bkp_agent.exe --source \\.\C: --target backup.example.org:9990 --target-dir srv-win01 ^
    --tls-ca C:\ProgramData\AegisGrid\target.crt --api-key file:C:\ProgramData\AegisGrid\srv-win01.key ^
    --name srv-win01-c

• Ganze Platte: VSS kennt nur Volumes. Der Agent legt deshalb eine Schattenkopie aller Volumes der Platte in einem Schritt an (die Volumes sind damit untereinander konsistent) und setzt das Abbild aus mehreren Quellen zusammen: Partitionstabelle, Lücken und alles, was VSS nicht unterstützt (zum Beispiel eine FAT-EFI-Partition, dynamische Datenträger), werden direkt von der Platte gelesen, die Volumes aus den Schattenkopien. Das Log nennt pro Partition, woher sie gelesen wurde. Mit --snapshot on scheitert die Sicherung, wenn ein Volume nicht per VSS gesichert werden kann.
• Platte über ihre Kennung: Die Nummer in \\.\PhysicalDrive<n> kann sich nach einem Neustart oder beim Anschließen einer weiteren Platte ändern; dann würde eine andere Platte gesichert. Besser ist die Kennung der Platte: --source disk-id:{<GPT-Datenträger-GUID>} bzw. disk-id:mbr-<Signatur, 8 Hex-Ziffern> (so nennt sie auch die Quellenliste des Planers, GET /sources). Der Agent sucht die Platte bei jedem Lauf und nennt im Log ihre aktuelle Nummer; Kette, Fortsetzen und Index laufen über die Kennung weiter, auch wenn sich die Nummer ändert. Fehlt die Platte oder tragen zwei Platten dieselbe Kennung (eine kopierte Platte), bricht der Lauf mit einer Meldung ab, statt eine andere zu sichern. Unter Linux erfüllt der Link in /dev/disk/by-id denselben Zweck (für ein ZFS-Volume der Link in /dev/zvol).
• --vss-mode copy|full (Standard copy): copy entspricht VSS_BT_COPY; die Anwendungs-Logs (zum Beispiel von SQL Server) bleiben unverändert und andere Backup-Software wird nicht gestört. full entspricht VSS_BT_FULL: nach einer erfolgreichen Sicherung bekommen die VSS-Writer gemeldet, dass eine Vollsicherung abgeschlossen wurde, und kürzen ihre Logs.
• Grenzen: VSS macht nur Anwendungen mit VSS-Writer anwendungskonsistent (SQL Server, Exchange, Active Directory, Hyper-V u. a.). Für Software ohne Writer ist der Snapshot absturzkonsistent; dafür gibt es die Hooks (Dienst anhalten und wieder starten). Das VSS-Einfrierfenster ist auf wenige Sekunden begrenzt.
• Persistente Schattenkopie: Bei einer fortsetzbaren Netzwerk-Sicherung (--target) versucht der Agent standardmäßig (--vss-persistent auto) eine Schattenkopie, die einen Neustart übersteht; wird die Sicherung unterbrochen, bleibt sie bestehen und der nächste Lauf setzt vom selben Zeitpunkt fort, ohne die Quelle erneut zu lesen. Siehe „Ausfallsichere Netzwerk-Sicherung“ in Kapitel 4.