XCP-ng Backup: Unterschied zwischen den Versionen
| (4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 3: | Zeile 3: | ||
Xen Orchestra ist die fortschrittlichste Backup-Lösung und zu 100 % in XCP-ng integriert. Es gibt viele verschiedene Backup-Optionen: | Xen Orchestra ist die fortschrittlichste Backup-Lösung und zu 100 % in XCP-ng integriert. Es gibt viele verschiedene Backup-Optionen: | ||
| − | *Automated rolling snapshots | + | *[[Automated rolling snapshots]] |
| − | *Full Backup | + | *[[Full Backup]] |
| − | *Full Replication | + | *[[Full Replication]] |
| − | *Incremental Backup | + | *[[Incremental Backup]] |
| − | *Incremental Replication | + | *[[Incremental Replication]] |
| − | *Mirror backup | + | *[[Mirror backup]] |
| − | *XO Metadata backup | + | *[[XO Metadata backup]] |
*XCP-ng Metadata backup | *XCP-ng Metadata backup | ||
*Cloud enabled XO Metadata backup | *Cloud enabled XO Metadata backup | ||
| + | |||
| + | [[Datei:Xcp-backup-schema.png]] | ||
| + | |||
| + | Und sie kommen mit unterschiedlichen Funktionen: | ||
| + | |||
| + | *NFS, SMB, S3 compatible backup repositories | ||
| + | *Encryption | ||
| + | *Compression | ||
| + | *File level restore | ||
| + | *NBD-enabled for extra backup speed | ||
| + | *Rate limiting | ||
| + | *XO Proxy (backup remote sites without any VPN requirement) | ||
| + | |||
| + | == Smart Backup == | ||
| + | |||
| + | Es gibt zwei Möglichkeiten, welche VMs gesichert werden: | ||
| + | |||
| + | * Manuelles Auswählen mehrerer VMs | ||
| + | * Smart Backup | ||
| + | |||
| + | Das manuelle Auswählen von VMs kann eine Einschränkung sein, wenn sich Ihre Umgebung schnell ändert (d.h. häufig neue VMs hinzukommen, die gesichert werden müssen). In dieser Situation müssten Sie ständig das Backup-Job bearbeiten, um neue VMs hinzuzufügen. | ||
| + | |||
| + | Dank Smart Backup haben Sie jetzt mehr Flexibilität: Sie wählen keine spezifischen VMs aus, sondern den Status/Tag/Platzierung der VMs zum Zeitpunkt der Ausführung des Backup-Jobs. Lassen Sie uns einige Beispiele ansehen! | ||
| + | |||
| + | === Backup aller VMs in einem Pool === | ||
| + | |||
| + | Dieser Job sichert alle VMs im Pool "Lab Pool" zum geplanten Zeitpunkt: | ||
| + | |||
| + | Das bedeutet: Jede VM, die zu diesem Zeitpunkt in diesem Pool existiert, wird gesichert. Es spielt keine Rolle, ob Sie eine neue VM erstellen, diese wird ebenfalls gesichert, ohne dass der Backup-Job bearbeitet werden muss. | ||
| + | |||
| + | Sie haben nun die Möglichkeit, VMs in Produktionspools intelligent zu sichern! | ||
| + | |||
| + | Möchten Sie den Job etwas eingrenzen? Siehe unten. | ||
| + | |||
| + | === Backup-Filter === | ||
| + | |||
| + | Sie können auch: | ||
| + | |||
| + | * nur laufende (oder angehaltene) VMs sichern, wenn der Job ausgeführt wird | ||
| + | * nur VMs mit einem bestimmten Tag sichern | ||
| + | |||
| + | Erinnern Sie sich an die Prod-VMs? Ich habe jedem von ihnen einen Tag "prod" hinzugefügt: | ||
| + | |||
| + | Wenn Sie dies tun: | ||
| + | |||
| + | Das bedeutet, dass alle VMs im "Lab Pool" mit dem Tag "prod" gesichert werden. | ||
| + | |||
| + | == Remotes == | ||
| + | |||
| + | Remotes sind Speicherorte, an denen Ihre Backup- und Delta-Backup-Dateien gespeichert werden. | ||
| + | |||
| + | Um ein Remote hinzuzufügen, gehen Sie zum Menü Einstellungen/Remotes. | ||
| + | |||
| + | Unterstützte Remote-Typen: | ||
| + | |||
| + | * Lokal (jeder Ordner im XOA-Dateisystem) | ||
| + | * NFS | ||
| + | * SMB (CIFS) | ||
| + | |||
| + | == Dateiebene-Wiederherstellung == | ||
| + | |||
| + | Sie können auch spezifische Dateien und Verzeichnisse innerhalb einer VM wiederherstellen. Dies funktioniert mit all Ihren vorhandenen Delta-Backups. | ||
| + | |||
| + | '''WARNUNG''' | ||
| + | |||
| + | Die Dateiebene-Wiederherstellung ist nur bei Delta-Backups möglich. Aufgrund einiger technischer Einschränkungen ist es nicht möglich, eine Dateiebene-Wiederherstellung durchzuführen, wenn Sie eine Kette haben, die länger als 99 Einträge ist (d.h. eine Aufbewahrung länger als 99 Datensätze ohne ein vollständiges Backup dazwischen). Sehen Sie sich den Abschnitt zum Intervall für vollständige Backups an, um dies korrekt einzustellen. | ||
| + | |||
| + | '''WARNUNG''' | ||
| + | |||
| + | Die Dateiebene-Wiederherstellung ist nur auf einem einzelnen VDI möglich, sie unterstützt keine LVM-Volume-Gruppen, die sich über mehrere VDIs erstrecken. | ||
| + | |||
| + | == Verringerung der Aufbewahrungshäufigkeit mit dem Alter == | ||
| + | |||
| + | Es ist oft eine gute Idee, die Aufbewahrung älterer Backups mit abnehmender Häufigkeit zu konfigurieren. Zum Beispiel möchten Sie möglicherweise ein nächtliches Backup, aber Sie möchten nicht 365 Backups haben, um von vor einem Jahr wiederherzustellen. Die Lösung besteht darin, mehrere verschiedene Zeitpläne/Aufbewahrungsrichtlinien für denselben Backup-Job festzulegen. Ein vernünftiger Ansatz könnte sein, zu planen... | ||
| + | |||
| + | * ein nächtliches Backup, außer am Sonntag (Aufbewahrung von 6) | ||
| + | * ein wöchentliches Backup am Sonntag (Aufbewahrung von 4) | ||
| + | * ein monatliches Backup (Aufbewahrung von 12) | ||
| + | |||
| + | All diese können demselben Backup-Job zugewiesen werden. Beachten Sie, dass bei wöchentlichen und monatlichen Backups diese irgendwann auf denselben Tag fallen werden. Xen Orchestra ist so konzipiert, dass es bei einem Fehler (mit einer Fehlermeldung) nicht abstürzt, wenn ein Backup-Job für eine VM bereits läuft. Aus diesem Grund sollten Sie die Zeit für den monatlichen Job vor dem wöchentlichen Job festlegen, sodass im Falle eines Fehlers das wöchentliche Backup und nicht das monatliche ausfällt; wenn das wöchentliche Backup fehlschlägt, wird das monatliche an dieser Stelle im Aufbewahrungsplan vorhanden sein; wenn das monatliche Backup fehlschlägt, wird das wöchentliche nur 4 Wochen lang aufbewahrt und es entsteht eine Lücke in der monatlichen Aufbewahrung. | ||
| + | |||
| + | == Backup Health Check == | ||
| + | |||
| + | Die Backup-Gesundheitsprüfung stellt sicher, dass die Backups wiederhergestellt werden können. | ||
| + | |||
| + | === Verschiedene Überprüfungsstufen === | ||
| + | |||
| + | ==== Überprüfung des Starts ==== | ||
| + | |||
| + | XO stellt die VM wieder her, entweder durch Herunterladen für ein Delta-/Vollbackup oder durch Klonen für eine Notfallwiederherstellung oder kontinuierliche Replikation, und wartet dann darauf, dass die Gastwerkzeuge innerhalb eines Timeout von 10 Minuten (Start + Gastwerkzeuge) geladen werden. | ||
| + | |||
| + | Eine VM ohne Gastwerkzeuge wird die Gesundheitsprüfung nicht bestehen. | ||
| + | |||
| + | Die wiederhergestellte VM wird anschließend gelöscht. | ||
| + | |||
| + | ==== Ausführen eines Skripts ==== | ||
| + | |||
| + | Wenn eine VM während einer Backup-Gesundheitsprüfung den Tag xo-backup-healthcheck-xenstore hat, wartet XO auf ein Skript, das den Wert des Xenstore-Schlüssels vm-data/xo-backup-health-check entweder auf success oder failure ändert. | ||
| + | |||
| + | Im Falle eines Fehlers wird die Gesundheitsprüfung als fehlgeschlagen markiert und die (optionale) Nachricht im vm-data/xo-backup-health-check-error angezeigt. | ||
| + | |||
| + | Das Skript muss beim Start geplant werden. Es kann überprüfen, ob der Eintrag vm-data/xo-backup-health-check des lokalen Xenstore den Wert planned enthält, um zwischen einem normalen Start und einem Start während der Gesundheitsprüfung zu unterscheiden. Bei Erfolg muss es success in vm-data/xo-backup-health-check schreiben. Bei Misserfolg muss es failure in vm-data/xo-backup-health-check schreiben und kann optional Details in vm-data/xo-backup-health-check-error hinzufügen. | ||
| + | |||
| + | Das gesamte Timeout für eine Backup-Gesundheitsprüfung (Start + Gastwerkzeuge + Skripte) beträgt 10 Minuten. | ||
| + | |||
| + | Die wiederhergestellte VM wird anschließend gelöscht. | ||
| + | |||
| + | Ein Beispiel in Bash ist in @xen-orchestra/backups/docs/healthcheck example/wait30seconds.sh gezeigt. | ||
Aktuelle Version vom 16. Mai 2024, 08:44 Uhr
Xen Orchestra
Xen Orchestra ist die fortschrittlichste Backup-Lösung und zu 100 % in XCP-ng integriert. Es gibt viele verschiedene Backup-Optionen:
- Automated rolling snapshots
- Full Backup
- Full Replication
- Incremental Backup
- Incremental Replication
- Mirror backup
- XO Metadata backup
- XCP-ng Metadata backup
- Cloud enabled XO Metadata backup
Und sie kommen mit unterschiedlichen Funktionen:
- NFS, SMB, S3 compatible backup repositories
- Encryption
- Compression
- File level restore
- NBD-enabled for extra backup speed
- Rate limiting
- XO Proxy (backup remote sites without any VPN requirement)
Smart Backup
Es gibt zwei Möglichkeiten, welche VMs gesichert werden:
- Manuelles Auswählen mehrerer VMs
- Smart Backup
Das manuelle Auswählen von VMs kann eine Einschränkung sein, wenn sich Ihre Umgebung schnell ändert (d.h. häufig neue VMs hinzukommen, die gesichert werden müssen). In dieser Situation müssten Sie ständig das Backup-Job bearbeiten, um neue VMs hinzuzufügen.
Dank Smart Backup haben Sie jetzt mehr Flexibilität: Sie wählen keine spezifischen VMs aus, sondern den Status/Tag/Platzierung der VMs zum Zeitpunkt der Ausführung des Backup-Jobs. Lassen Sie uns einige Beispiele ansehen!
Backup aller VMs in einem Pool
Dieser Job sichert alle VMs im Pool "Lab Pool" zum geplanten Zeitpunkt:
Das bedeutet: Jede VM, die zu diesem Zeitpunkt in diesem Pool existiert, wird gesichert. Es spielt keine Rolle, ob Sie eine neue VM erstellen, diese wird ebenfalls gesichert, ohne dass der Backup-Job bearbeitet werden muss.
Sie haben nun die Möglichkeit, VMs in Produktionspools intelligent zu sichern!
Möchten Sie den Job etwas eingrenzen? Siehe unten.
Backup-Filter
Sie können auch:
- nur laufende (oder angehaltene) VMs sichern, wenn der Job ausgeführt wird
- nur VMs mit einem bestimmten Tag sichern
Erinnern Sie sich an die Prod-VMs? Ich habe jedem von ihnen einen Tag "prod" hinzugefügt:
Wenn Sie dies tun:
Das bedeutet, dass alle VMs im "Lab Pool" mit dem Tag "prod" gesichert werden.
Remotes
Remotes sind Speicherorte, an denen Ihre Backup- und Delta-Backup-Dateien gespeichert werden.
Um ein Remote hinzuzufügen, gehen Sie zum Menü Einstellungen/Remotes.
Unterstützte Remote-Typen:
- Lokal (jeder Ordner im XOA-Dateisystem)
- NFS
- SMB (CIFS)
Dateiebene-Wiederherstellung
Sie können auch spezifische Dateien und Verzeichnisse innerhalb einer VM wiederherstellen. Dies funktioniert mit all Ihren vorhandenen Delta-Backups.
WARNUNG
Die Dateiebene-Wiederherstellung ist nur bei Delta-Backups möglich. Aufgrund einiger technischer Einschränkungen ist es nicht möglich, eine Dateiebene-Wiederherstellung durchzuführen, wenn Sie eine Kette haben, die länger als 99 Einträge ist (d.h. eine Aufbewahrung länger als 99 Datensätze ohne ein vollständiges Backup dazwischen). Sehen Sie sich den Abschnitt zum Intervall für vollständige Backups an, um dies korrekt einzustellen.
WARNUNG
Die Dateiebene-Wiederherstellung ist nur auf einem einzelnen VDI möglich, sie unterstützt keine LVM-Volume-Gruppen, die sich über mehrere VDIs erstrecken.
Verringerung der Aufbewahrungshäufigkeit mit dem Alter
Es ist oft eine gute Idee, die Aufbewahrung älterer Backups mit abnehmender Häufigkeit zu konfigurieren. Zum Beispiel möchten Sie möglicherweise ein nächtliches Backup, aber Sie möchten nicht 365 Backups haben, um von vor einem Jahr wiederherzustellen. Die Lösung besteht darin, mehrere verschiedene Zeitpläne/Aufbewahrungsrichtlinien für denselben Backup-Job festzulegen. Ein vernünftiger Ansatz könnte sein, zu planen...
- ein nächtliches Backup, außer am Sonntag (Aufbewahrung von 6)
- ein wöchentliches Backup am Sonntag (Aufbewahrung von 4)
- ein monatliches Backup (Aufbewahrung von 12)
All diese können demselben Backup-Job zugewiesen werden. Beachten Sie, dass bei wöchentlichen und monatlichen Backups diese irgendwann auf denselben Tag fallen werden. Xen Orchestra ist so konzipiert, dass es bei einem Fehler (mit einer Fehlermeldung) nicht abstürzt, wenn ein Backup-Job für eine VM bereits läuft. Aus diesem Grund sollten Sie die Zeit für den monatlichen Job vor dem wöchentlichen Job festlegen, sodass im Falle eines Fehlers das wöchentliche Backup und nicht das monatliche ausfällt; wenn das wöchentliche Backup fehlschlägt, wird das monatliche an dieser Stelle im Aufbewahrungsplan vorhanden sein; wenn das monatliche Backup fehlschlägt, wird das wöchentliche nur 4 Wochen lang aufbewahrt und es entsteht eine Lücke in der monatlichen Aufbewahrung.
Backup Health Check
Die Backup-Gesundheitsprüfung stellt sicher, dass die Backups wiederhergestellt werden können.
Verschiedene Überprüfungsstufen
Überprüfung des Starts
XO stellt die VM wieder her, entweder durch Herunterladen für ein Delta-/Vollbackup oder durch Klonen für eine Notfallwiederherstellung oder kontinuierliche Replikation, und wartet dann darauf, dass die Gastwerkzeuge innerhalb eines Timeout von 10 Minuten (Start + Gastwerkzeuge) geladen werden.
Eine VM ohne Gastwerkzeuge wird die Gesundheitsprüfung nicht bestehen.
Die wiederhergestellte VM wird anschließend gelöscht.
Ausführen eines Skripts
Wenn eine VM während einer Backup-Gesundheitsprüfung den Tag xo-backup-healthcheck-xenstore hat, wartet XO auf ein Skript, das den Wert des Xenstore-Schlüssels vm-data/xo-backup-health-check entweder auf success oder failure ändert.
Im Falle eines Fehlers wird die Gesundheitsprüfung als fehlgeschlagen markiert und die (optionale) Nachricht im vm-data/xo-backup-health-check-error angezeigt.
Das Skript muss beim Start geplant werden. Es kann überprüfen, ob der Eintrag vm-data/xo-backup-health-check des lokalen Xenstore den Wert planned enthält, um zwischen einem normalen Start und einem Start während der Gesundheitsprüfung zu unterscheiden. Bei Erfolg muss es success in vm-data/xo-backup-health-check schreiben. Bei Misserfolg muss es failure in vm-data/xo-backup-health-check schreiben und kann optional Details in vm-data/xo-backup-health-check-error hinzufügen.
Das gesamte Timeout für eine Backup-Gesundheitsprüfung (Start + Gastwerkzeuge + Skripte) beträgt 10 Minuten.
Die wiederhergestellte VM wird anschließend gelöscht.
Ein Beispiel in Bash ist in @xen-orchestra/backups/docs/healthcheck example/wait30seconds.sh gezeigt.
