Datenbank Backups - Grundlagen
Eines der wichtigsten Themen im Bereich der Datenbank ist das Backup der Daten. Die in der Datenbank gespeicherten Daten sind in der Regel das Kapital einer Firma, auch wenn es sich nur um das (schnöde) Warenwirtschaftssystem handelt.
Als erstes jedoch möchte ich ein Paar Begriffe auf dem Bereich erläutern.
Recovery Time Objective vs. Recovery Point Objective
Diese beiden Begriffe stellen meines Erachtens nach die beiden wichtigsten Kriterien für die Erstellung einer Backupstrategie von Datenbanken dar.
Bei Recovery Time Objective (RTO) handelt es sich um die für die Wiederherstellung der Daten vorgegebene Zeit. Es handelt sich dabei um die Zeit vom Eintritt des Schadens bis zur abgeschlossenen Bereitstellung des Backups in Form einer wiederhergestellten Datenbank.
Bei Recovery Point Objective handelt es sich um die Zeitspanne, in der ein Datenverlust hingenommen wird / werden kann.
Recovery Time Objective
Dieser Begriff definiert die Zeit zwischen dem Eintritt des Schadenfalls und der vollständigen Wiederherstellung des Systems.
Um den Begriff besser zu veranschaulichen, hier ein einfaches Beispiel:
Ein Vollbackup wird einmal in der Nacht erstellt. Das Wiederherstellen eines Vollbackups von 100GB Größe kann je nach System schon eine bis mehrere Stunden in Anspruch nehmen. Die RTO beträgt in dem Fall eine bis mehrere Stunden, in dieser Zeit steht der Betrieb still, da die Datenbank nicht zur Verfügung steht.
Recovery Point Objective
Bestes Beispiel um RPO zu erklären ist der noch immer zu oft verwendete Fall eines Vollbackups einmal in der Nacht. In der Regel wird in diesem Szenario das Wiederherstellungsmodell Simple verwendet und einmal in der Nacht ein Backup der Datenbank erstellt.
Geht man mal von einer 24/7 Verwendung der Datenbank aus, liegt die RPO in diesem Beispiel bei 24 Stunden.
Beleuchten wir dieses Szenario etwas genauer:
Nehmen wir an die Datenbank wird jede Nacht um 1 Uhr gesichert und der Schadensfall tritt kurz vor Mitternacht des selben Tages ein. Dann verliert man die Daten der letzten knapp 24 Stunden. Wird die Datenbank in diesem Szenario (wenn auch nur zu den üblichen Geschäftszeiten)rege genutzt, verliert man die Daten eines kompletten Arbeitstages. Bei einer Firma mit 50 oder gar 100 Mitarbeitern kommen da schon einige Stunden an verlorener Arbeitsleistung zusammen. Zusätzlich zu den von den Mitarbeitern geleisteten Arbeitsstunden könnte hier noch ein Schaden durch eine verzögerte Auftragsabwicklung kommen. Im schlimmsten Fall sind die tagsüber eingetragenen Daten vollständig verloren.
Backup Methoden
Als nächstes schauen wir uns die verschiedenen im Microsoft SQL Server zur Verfügung stehenden Backupmethoden an.
Bei dieser Betrachtung wird auch wichtig zu verstehen, wie die verschiedenen Backupmethoden teilweise aufeinander aufbauen. Dies ist ein besonders wichtiger Punkt, da eine defekte Backupdateien in der Mitte des Backupstrangs die komplette Wiederherstellung der Datenbank unmöglich macht. Es ist also zusätzlich auch besonderer Augenmerk darauf zu legen, dass die erstellten Backupdateien verifiziert werden und an einem sicheren Ort liegen.
Bei längeren aufeinander aufbauenden Backupstrategien ist es teilweise auch ratsam, erstellte Backups automatisiert auf einem zweiten System wiederherzustellen, um die Funktionssicherheit der Backups zu gewährleisten.
Vollbackup
Das Vollbackup ist der Klassiker unter den Backups. Es erstellt einen Backupsatz welcher die komplette Datenbank beinhaltet. Bei der Wiederherstellung aus dem Backup wird die komplette Datenbank wiederhergestellt. Abgesehen von genügend Plattenplatz gibt es keine sonstigen Voraussetzungen für die Wiederherstellung eines Vollbackups.
Differentiellen Backup
Das differentielle Backup benötigt als erste Voraussetzung immer ein vorher erstelltes und bei der Wiederherstellung verfügbares Vollbackup. Ist das Vollbackup nicht verfügbar oder beschädigt, ist keine Wiederherstellung der Datenbank möglich.
Das differentielle Backup speichert bei jedem Lauf die Daten vom Zeitpunkt der Erstellung des Vollbackups bis zum Zeitpunkt der Erstellung des differentiellen Backups. Somit werden die Backups mit der Zeit immer größer, auf der anderen Seite wird auch immer nur das zuletzt erstelle differentielle Backup (und natürlich das Vollbackup) zur Wiederherstellung der Datenbank benötigt.
Somit sind zwei Schritte zur Wiederherstellung der Datenbank nötig:
- Wiederherstellung des Vollbackups
- Wiederherstellung des zuletzt erstellten differentiellen Backups
Bei der Auswahl des Zeitpunktes des Backups stehen nur die Zeitpunkte der Erstellung der seit dem letzten Vollbackup erstellen differentiellen Backups zur Verfügung. Die Wahl des Zeitpunktes ist somit relativ grobgranular.
Transaktionslog Backup
Beim Transaktions-Log Backup handelt es sich um eine besondere Art von Backup. Diese Backupdateien enthalten nicht die Daten aus der oder den Datenbankdatei(en), sondern alle seit dem letzten basierenden Backup ausgeführten und committeten Transaktionen. Das Wiederherstellen erfolgt quasi durch eine erneute Ausführung der in der Backupdatei gespeicherten Transaktionen.
Diese Art des Backups hat einige Vor- aber auch einige Nachteile.
Zu den Hauptvorteilen zählt der geringe Platzbedarf solcher Backups. Zudem ist durch diese Art des Backups eine deutlich fein granularere Wiederherstellung der Daten möglich.
Zu den eindeutigen Nachteiles dieses Backuptyps zählt der erhöhte Aufwand beim Wiederherstellen der Datenbank, da die Transaktions-Log Backups in der korrekten Reihenfolge wiederhergestellt werden müssen. Hierbei muss die Datenbank nach dem wiederherstellen, außer beim Wiederherstellen des letzten Backup im Recoverymodus verbleiben.