Proxmox backup: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Keine Bearbeitungszusammenfassung |
|||
| Zeile 1: | Zeile 1: | ||
=Snapshot= | =Snapshot= | ||
==Funktionsweise== | ==Funktionsweise== | ||
* Es wird ein Snapshot | * Es wird ein Snapshot der Datenbank erstellt. | ||
* | * Ein Delta wird erstellt, um nachfolgende Änderungen zu erfassen. | ||
* Änderungen werden ins Delta geschrieben. | * Änderungen werden ins Delta geschrieben. | ||
* Der Snapshot wird gebackupt. | * Der Snapshot wird gebackupt. | ||
* Nach dem Beenden des Backups werden Delta und Snapshot gemerged. | * Nach dem Beenden des Backups werden Delta und Snapshot gemerged. | ||
* Der Betrieb | * Der normale Betrieb wird fortgesetzt. | ||
==Vorteile== | ==Vorteile== | ||
* Keine Downtime | * Keine Downtime der Datenbank | ||
* | * Schnelle Erstellung und Wiederherstellung | ||
==Nachteile== | ==Nachteile== | ||
* Performance-Einbußen während des | * Performance-Einbußen während der Snapshot-Erstellung und des Mergings | ||
* Datenkonsistenzprobleme bei Änderungen während des Prozesses | * Datenkonsistenzprobleme bei Änderungen während des Prozesses | ||
* Erhöhter Speicherplatzbedarf | * Erhöhter Speicherplatzbedarf für Snapshots und Deltas | ||
* Komplexität und | * Komplexität und Verwaltungsaufwand | ||
* Längere Wiederherstellungszeiten bei großen Datenmengen | * Längere Wiederherstellungszeiten bei großen Datenmengen | ||
* Abhängigkeit von der Zuverlässigkeit der Snapshot-Technologie | * Abhängigkeit von der Zuverlässigkeit der Snapshot-Technologie | ||
* Sicherheitsrisiken durch unzureichend geschützte Snapshots | |||
=Suspend= | =Suspend= | ||
==Funktionsweise== | ==Funktionsweise== | ||
* Der aktuelle Zustand | * Die Datenbank wird in einen konsistenten Zustand gebracht (z.B. durch Sperren und Schreiben aller Puffer). | ||
* | * Der aktuelle Zustand der Datenbank wird in den Speicher geschrieben. | ||
* Die Datenbank wird in den Ruhezustand versetzt (Suspension). | |||
* Der Speicherzustand wird gesichert. | * Der Speicherzustand wird gesichert. | ||
* Nach Abschluss der Sicherung wird | * Nach Abschluss der Sicherung wird die Datenbank reaktiviert und der Betrieb fortgesetzt. | ||
==Vorteile== | ==Vorteile== | ||
* | * Keine Beeinträchtigung laufender Transaktionen | ||
* Relativ schnelle Wiederaufnahme des Betriebs | * Relativ schnelle Wiederaufnahme des Betriebs | ||
* | * Sicherstellung der Datenkonsistenz während der Sicherung | ||
* Geeignet für kurzfristige Wartungsarbeiten oder Systemupgrades | |||
==Nachteile== | ==Nachteile== | ||
* Kurzzeitige Downtime während des Übergangs in den und aus dem Ruhezustand | * Kurzzeitige Downtime während des Übergangs in den und aus dem Ruhezustand | ||
* Risiko von Datenverlust bei unvorhergesehenen Ereignissen während des Ruhezustands | * Risiko von Datenverlust bei unvorhergesehenen Ereignissen während des Ruhezustands | ||
* Nicht geeignet für | * Nicht geeignet für Datenbanken mit sehr hohem Verfügbarkeitsanspruch | ||
* Erhöhter Energieverbrauch im Vergleich zu vollständigem Stop | |||
=Stop= | =Stop= | ||
==Funktionsweise== | ==Funktionsweise== | ||
* | * Die Datenbank wird geordnet heruntergefahren, um einen konsistenten Zustand zu gewährleisten. | ||
* Alle laufenden | * Alle laufenden Transaktionen werden beendet. | ||
* Der | * Der aktuelle Zustand der Datenbank wird gesichert. | ||
* | * Die Datenbank wird vollständig gestoppt. | ||
==Vorteile== | ==Vorteile== | ||
* | * Vollständige Konsistenz der Daten während der Sicherung | ||
* Einfache und direkte Methode zur Sicherung des | * Einfache und direkte Methode zur Sicherung des Datenbankzustands | ||
* Geeignet für vollständige Systemwartungen oder -upgrades | * Geeignet für vollständige Systemwartungen oder -upgrades | ||
==Nachteile== | ==Nachteile== | ||
* Vollständige Downtime während der Sicherung und des Neustarts | * Vollständige Downtime der Datenbank während der Sicherung und des Neustarts | ||
* Potenzieller Datenverlust bei abruptem Stopp ohne vorherige Sicherung | * Potenzieller Datenverlust bei abruptem Stopp ohne vorherige Sicherung | ||
* Nicht geeignet für kritische | * Nicht geeignet für kritische Datenbanken, die kontinuierliche Verfügbarkeit erfordern | ||
Version vom 10. Juli 2024, 09:08 Uhr
Snapshot
Funktionsweise
- Es wird ein Snapshot der Datenbank erstellt.
- Ein Delta wird erstellt, um nachfolgende Änderungen zu erfassen.
- Änderungen werden ins Delta geschrieben.
- Der Snapshot wird gebackupt.
- Nach dem Beenden des Backups werden Delta und Snapshot gemerged.
- Der normale Betrieb wird fortgesetzt.
Vorteile
- Keine Downtime der Datenbank
- Schnelle Erstellung und Wiederherstellung
Nachteile
- Performance-Einbußen während der Snapshot-Erstellung und des Mergings
- Datenkonsistenzprobleme bei Änderungen während des Prozesses
- Erhöhter Speicherplatzbedarf für Snapshots und Deltas
- Komplexität und Verwaltungsaufwand
- Längere Wiederherstellungszeiten bei großen Datenmengen
- Abhängigkeit von der Zuverlässigkeit der Snapshot-Technologie
- Sicherheitsrisiken durch unzureichend geschützte Snapshots
Suspend
Funktionsweise
- Die Datenbank wird in einen konsistenten Zustand gebracht (z.B. durch Sperren und Schreiben aller Puffer).
- Der aktuelle Zustand der Datenbank wird in den Speicher geschrieben.
- Die Datenbank wird in den Ruhezustand versetzt (Suspension).
- Der Speicherzustand wird gesichert.
- Nach Abschluss der Sicherung wird die Datenbank reaktiviert und der Betrieb fortgesetzt.
Vorteile
- Keine Beeinträchtigung laufender Transaktionen
- Relativ schnelle Wiederaufnahme des Betriebs
- Sicherstellung der Datenkonsistenz während der Sicherung
- Geeignet für kurzfristige Wartungsarbeiten oder Systemupgrades
Nachteile
- Kurzzeitige Downtime während des Übergangs in den und aus dem Ruhezustand
- Risiko von Datenverlust bei unvorhergesehenen Ereignissen während des Ruhezustands
- Nicht geeignet für Datenbanken mit sehr hohem Verfügbarkeitsanspruch
- Erhöhter Energieverbrauch im Vergleich zu vollständigem Stop
Stop
Funktionsweise
- Die Datenbank wird geordnet heruntergefahren, um einen konsistenten Zustand zu gewährleisten.
- Alle laufenden Transaktionen werden beendet.
- Der aktuelle Zustand der Datenbank wird gesichert.
- Die Datenbank wird vollständig gestoppt.
Vorteile
- Vollständige Konsistenz der Daten während der Sicherung
- Einfache und direkte Methode zur Sicherung des Datenbankzustands
- Geeignet für vollständige Systemwartungen oder -upgrades
Nachteile
- Vollständige Downtime der Datenbank während der Sicherung und des Neustarts
- Potenzieller Datenverlust bei abruptem Stopp ohne vorherige Sicherung
- Nicht geeignet für kritische Datenbanken, die kontinuierliche Verfügbarkeit erfordern