Eigentlich wollte ich nur einen „einfachen“ Beitrag über das Thema SQL Server Backup schreiben, aber bei den Recherchen stellte ich fest, dass das Thema SQL Server Backup doch sehr umfangreich und „mächtig“ ist und es sehr wahrscheinlich nicht nur mit einem Beitrag getan ist. Daher werde ich die einzelnen Beiträge in 3 Blöcke aufteilen, so dass ich mich in jedem Beitrag einem bestimmten Schwerpunkt widmen kann.

Grundlagen / Voraussetzung / Vertragliches zum Thema SQL Server Backup

Jeder kennt das, man hat gerade wieder einen neuen SQL Server aufgesetzt und konfiguriert, die ersten User und die erste Datenbank wurden angelegt, vielleicht sogar schon diie ersten Tests der Applikation erfolgreich abgeschlossen…

Zu Anfang konfigurieren Applikationsverantwortliche, Drittdienstleister und vielleicht auch Enduser noch fleißig an allem herum und testen die einzelnen Einstellungen der Applikation, was bewirkt was und wie können angepriesene Features sinnvoll im Betrieb genutzen werden.

ABER was machen, wenn plötzlich gar nichts mehr geht, die Daten sind plötzlich weg, die Konfiguration so „verdreht“, dass man sich nicht mehr anmelden kann???

Dann ist das Geschrei groß, Daten und Konfiguration werden in der Datenbank gespeichert… wir müssen die Datenbank wieder herstellen… „Ach Mist, wir haben vergessen das Backup einzurichten…  😮

Also bevor mach solche „Spielereien“ anfängt, sollte man erst ein Backup einrichten ! Aber wie am Besten ?

• Wie oft muss die Datenbank gesichert werden?
• Wie schnell muss die Wiederherstellung funktionieren?
• Wie groß wird die Datenbank?
• Wie groß sind die täglichen Änderungen?
• Gibt es definierte Wartungsfenster?
• Muss beim Backup des SQL Servers etwas besonderes beachtet werden (Stichwort Konsistenz)
• Läuft zu einem bestimmten Zeitpunkt/-raum eine Bewirtschaftung?
• Welche Methoden muss ich einsetzen?
• Welche Tools und/oder Skripte muss ich ggf einsetzen?
• Gibt es vertragliche Definitionen zu obigen Fragen?

Fragen über Fragen, zu denen ich versuche eine Antwort zu liefern.

Vertragliche Rahmenbedingungen fürs SQL Server Backup:

Erst einmal sollte die vertragliche Seite überprüft werden! Muss ein SLA gewährleistet werden, enthält dieses Servicelevel Agreement bestimmte Vorgaben zu „Max Time of Data Lost“, „Max Time to Restore“ oder vielleicht sogar einen definierten Sicherungsplan, was wann wie oft gesichert werden muss.

Diesen vertraglichen Rahmen gilt es mit den einzurichtenden und zu planenden Sicherung abzudecken, damit beide Vertragsseiten durch ein einwandfreies und gut funktionierendes SQL Server Backup abgesichert sind und es nicht zu Problemen im Betrieb des SQL Servers kommt.

Beispiel für einen SLA

Wir betreiben für einen unserer Kunden einen SQL Server mit einer definierten Servicezeit (Bedienter Betrieb) von 8:00 – 18:00 Uhr an jedem Werktag (mit Ausnahme von bundeseinheitlichen Feiertagen), daraus ergeben sich laut dem Vertrag folgende Verfügbarkeiten:

Verfügbarkeit Monatsmittel	Verfügbarkeit Jahresmittel	Gesamt-Ausfallzeit Jahr [Std.]
95,38%	99,04%	25,00

Aber auch eben eine RTO (Recovery Time Objective) von 72h und eine RPO (Recovery Point Objective (RPO) von 24h.

Bei der Beurteilung einer Disaster-Recovery-Lösung sind folgende Punkte einer Business Impact Analyse zu beachten:

1. Recovery Time Objective (RTO) – Wie lange darf ein Geschäftsprozess/System ausfallen? Bei der Recovery Time Objective handelt es sich um die Zeit, die vom Zeitpunkt des Schadens bis zur vollständigen Wiederherstellung der Geschäftsprozesse (Wiederherstellung von: Infrastruktur – Daten – Nacharbeitung von Daten – Wiederaufnahme der Aktivitäten) vergehen darf. Der Zeitraum kann hier von 0 Minuten (Systeme müssen sofort verfügbar sein), bis mehrere Tage (in Einzelfällen Wochen) betragen.
2. Recovery Point Objective (RPO) – Wie viel Datenverlust kann in Kauf genommen werden? Bei der Recovery Point Objective handelt es sich um den Zeitraum, der zwischen zwei Datensicherungen liegen darf, das heißt, wie viele Daten/Transaktionen dürfen zwischen der letzten Sicherung und dem Systemausfall höchstens verloren gehen. Wenn kein Datenverlust hinnehmbar ist, beträgt die RPO 0 Sekunden. Quelle: Wikipedia

Anhand dieser Zahlen aus dem Vertrag muss man sich nun eine Backup-Strategie überlegen – wobei das eigentlich schon vorher festgelegt werden muss, sonst kann man solche Angebote nicht machen 🙂  – um dem Kunden und dem Vertrag dienlich zu sein.

• Welche Backup-Methode muss man also nun wählen, um diese Vorgabe von 24 Stunden maximalen Datenverlust zu gewährleisten?
• Wie oft müssen die Datenbanken gesichert werden?
• Welche Einstellung bzgl Recovery Mode müssen gewählt werden?
• Ist ein „Point-in-Time“ Restore notwendig?

Wie das immer so ist mit den Datenbanken und ihren „Eigenheiten“… eine allgemein gültige Empfehlung kann man nicht aussprechen… #ItDepends

Es ist also davon abhängig, was die Applikation für Anforderungen hat:

Was macht die Applikation mit den Daten? Handelt es sich „nur“ um die Quelle eines Reporting-Systems und können die Daten in angemessener Zeit aus anderen Quellen wieder bereitstellen? Oder werden die zu sichernden Datenbanken nur als „Zwischenschicht“ in einem ETL-Prozess benötigt. Oder handelt es sich um ein Online-Transaktions-System eines Payment-Dienstleister?

Jede Anwendung, jedes System hat eigene Anforderungen, so dass man eigentlich nur eine „Richtlinie“ definieren kann, an der man sich orientieren kann.

Eckpunkte zur Erstellung einer SQL Server Backup Strategie

Zu Anfang ein Beispiel aus dem Leben, nachdem ich an meiner bisherigen SQL Server Backup Strategie gezweifelt habe und diese anfing zu überdenken. Denn manchmal werden die folgenden Punkte nicht oder zu wenig beachtet und man hat dann im laufenden Betrieb langwierige Fehlersuchen bzw eine Suche nach der Nadel im Heuhaufen.

Erstellen Sie unbedingt eine Testumgebung, um die allgemeinen Werte und Bedingungen ihrer Systemlandschaft zu ermitteln. Was nützt es ihnen oder ihren Kunden, wenn sie eine gut strukturierte und sinnvoll geplante SQL Server Backup Strategie haben, diese aber nur in der Theorie einwandfrei funktioniert. Wir haben bisher eine solche unternehmensweite Strategie… alle SQL Server sollen mittels 3rd Party Tool gesichert werden… einmal täglich ein Vollsicherung und alle 20 Minuten (oder je nach SLA) eine TransactionLog-Sicherung. Diese Backup Strategie beruht aber auch darauf, dass dieses 3rd Party Tool kein Differential Backup kann.
Nun habe ich aber in einer Performance Analyse festgestellt, dass auf einem Sharepoint-SQL-Server die TransactionLog-Sicherung alle 20 Minuten läuft und somit eigentlich dauerhaft die Performance des SQL Servers beeinträchtigt, da die Laufzeit der Sicherung „zu hoch“ ist.

Dank eines TSQL-Statement von Brent Ozar konnte ich ermitteln, wie hoch die Transfer-Rate mittels 3rd Party Tools ist (bei separater Anbindung an die Backup Infrastruktur mit 10GBit) von sagenhaften 43Mbps im Schnitt… hier stimmt also irgendwas nicht. Wenn ich auf diesem System jetzt ein Backup2Disc mache, erhöht sich die Durchsatzrate auf ~250Mbps im Schnitt, das SQL Server Backup erhöht sich also um mehr als 5-fach, somit reduziert sich auch die Zeit in der der SQL Server durch das Backup belastet wird.

Daher gut überlegen und testen, testen und wieder testen!!!

Welcher Recovery-Mode muss gewählt werden?

Grundsätzlich sollte man seine Datenbanken regelmäßig sichern, darüber sind wir uns alle einig. Dann kommt es darauf an, welche Anforderungen die Applikation an die Datenbank stellt, hier muss man sich mit den Applikationsverantwortlichen abstimmen, welcher Recovery-Mode für die Datenbanken sinnvoll ist und was man ggf in Rücksicht auf die vertragliche Situation für einen Kompromiss finden muss.

Wie oft – in Abhängigkeit zum Recovery-Mode – muss gesichert werden?

Je nach Recovery-Mode (Simple, Full, Bulk-Logged) muss entschieden werden, wann welche Sicherung läuft und mit welcher Häufigkeit gesichert werden muss. Hier spielen die oben ermittelten Werte (RTO, RPO, Point-In-Time, Durchsatz) eine große Rolle, um einen passenden Schedule bestimmen zu können. Dies kann im laufenden Betrieb natürlich angepasst werden, wenn sich Prozesse (Bewirtschaftung, Verarbeitung, Reporting) ändern.

Womit soll gesichert werden? eigene TSL-Skripte, bewährte TSQL-Skripte oder 3rd-Party-Tool

Soll man das Rad noch einmal neu erfinden oder greift man auf bewährte Maintenance-Lösungen aus dem Netz zurück (z.B. das Maintenance-Skript von Ola Hallengren) oder gar ein 3rd Party Tool erwerben? Dies hängt natürlich von der Unternehmens-Backup-Strategie ab bzw von den oben bereits angesprochenen Rahmenbedingungen. Ich bin der Meinung, dass sich eine Lösung aus lokalem Backup mittels TSQL-Skripten/SQL-Agent-Jobs und 3rd Party-Tool bewährt hat. (meine persönlich bevorzugte Methode ist das Skript von Ola Hallengren (Backup2Disc) und dann eine Filesystem-Sicherung auf Tape)

Dies waren die grundlegenden Überlegungen, die man sich zum Thema SQL Server Backup machen sollte, da sie überaus wichtig sind. Aber wie bereits oben schon einmal erwähnt… #ItDepends
Jede Applikation, jeder Kunde, jedes Unternehmen, jeder SQL Server ist anders, daher kann dies nur als Leitfaden dienen.