|
|
| (11 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| =Snapshot=
| | </div> |
| ==Funktionsweise== | | <div style="margin-left: 20px;"> |
| * Es wird ein Snapshot der Datenbank erstellt.
| | [[Datei:backup.png|rechts|400px]] |
| * Ein Delta wird erstellt, um nachfolgende Änderungen zu erfassen.
| | </div> |
| * Änderungen werden ins Delta geschrieben.
| | </div> |
| * Der Snapshot wird gebackupt.
| |
| * Nach dem Beenden des Backups werden Delta und Snapshot gemerged.
| |
| * Der normale Betrieb wird fortgesetzt.
| |
|
| |
|
| ==Vorteile==
| | *[[Proxmox backup Konzepte]] |
| * Keine Downtime
| | *[[Proxmox backup Ad hoc]] |
| * Schnelle Erstellung und Wiederherstellung
| | *[[Backup Retention Policy]] |
| | | *[[Proxmox backup Automatisieren]] |
| ==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
| |
| * Längere Wiederherstellungszeiten bei großen Datenmengen
| |
| * Abhängigkeit von der Zuverlässigkeit der Snapshot-Technologie
| |
| * Manchmal Inkonsistenzen bei Datenbank
| |
| **Abhilfe Dump der Datenbank intern
| |
| | |
| =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 | |
