Downtime von Microsoft SQL Server minimieren
Kleines Backup, schnelles Recovery
Knapp bemessene Wartungsfenster und die Maßgabe, Kosten zu reduzieren, sind zwei der alltäglichen Herausforderungen, denen sich Datenbankadministratoren gegenübersehen. So entsteht Optimierungsbedarf für den Backup- und Restore-Prozess. Die SQL-Server-eigenen Werkzeuge sind nützlich, reizen die Möglichkeiten aber nicht aus.
Die Datenmengen wachsen scheinbar unaufhörlich. Wurde die Größe von Datenbanken vor wenigen
Jahren noch in MByte angegeben, sind heute längst GByte und TByte die Regel. Je größer die
Datenbank, umso größer ist die Last, die die Backups erzeugen. Mit entsprechender Rechentechnik im
Hintergrund ist dies an sich kein Problem. Doch diese ist teuer. Deshalb werden Server und
Datenbanken eher konsolidiert denn erweitert.
Die Größe der zu sichernden Datenbanken ist gewiss eines der Hauptprobleme, jedoch nicht das
einzige. Die Anforderungen an die Sicherheit der Backups steigen. Einige prominente Datenaffären
der letzten Zeit sind noch in bester Erinnerung. In wachsenden und immer komplexeren IT-Umgebungen
wird häufiger eine Wiederherstellung benötigt als in einfachen Umfeldern mit wenigen Usern. Und
allzu oft fordern Betreiber heute ein schnelles Reporting über große Datenmengen zu jeder Zeit.
Dies führt dazu, dass immer größere Datenbanken entstehen, für die im Gegenzug eher kürzere
Zeitfenster für administrative Aufgaben bereitgestellt werden. Die Folgen trägt der Administrator.
So muss er vorhandene Backup-Zeiten effektiver nutzen, den benötigten Speicherplatz für Backups
minimieren und die Datenbank im Fehlerfall möglichst schnell wiederherstellen.
SQL Server bietet zwei Möglichkeiten des Backups: Sicherung auf Disk und auf Band. Dabei wird
die gesamte Datenbank unkomprimiert über das Netzwerk zum Speichersubsystem geleitet. Dies kann
schnell zur Belastung für das Netzwerk werden und Performance-Einbußen erzeugen. Gängige
Speichersysteme erzielen Durchsatzraten von etwa 50 MByte/s, neuere Produkte bis zu 250 MByte/s.
Die Sicherung einer 1TByte großen Datenbank dauert dann bis zu mehreren Stunden. Dies ist mit
Sicherheit zu lang für ein tägliches oder einigermaßen regelmäßiges Backup.
Bandlaufwerke sind die kostengünstigere Alternative und deshalb weit verbreitet. Sicherungen
dauern jedoch noch länger als bei der Benutzung von Disks. Selbst wenn sich das Backup noch
einigermaßen in den täglichen Ablauf integrieren lässt: Im Restore-Fall kann es zum Ärgernis
werden, wenn die Datenbank nicht schnell wiederhergestellt ist.
Mit der Protokollübertragung (Log Shipping) bietet SQL Server eine weitere Variante des Backups.
Nachdem eine Kopie der Datenbank angelegt ist, werden die Transaction-Logs kontinuierlich von der
Produktionsdatenbank übertragen. Die Vorteile dieser Vorgehensweise: Die Kopie der Datenbank ist
immer relativ aktuell, die Transaction-Logs belasten den Netzwerkverkehr weniger und es besteht die
Möglichkeit, lesend darauf zuzugreifen.
Sind klassische Verfahren noch zeitgemäß?
Kosten- und Zeitdruck zwingen zur Suche nach Alternativen. Die beiden erstgenannten
Backup-Verfahren lassen sich beispielsweise sinnvoll kombinieren. Während ältere Daten auf Bändern
gesichert und archiviert werden, bleibt das aktuelle Backup auf der Festplatte, das für über 90
Prozent der Restore-Fälle ausreicht. So nutzt man den Kostenvorteil der Tapes und kann dennoch im
Falle eines Falles die Datenbank relativ schnell von der Disk wiederherstellen.
Es gibt noch weitere Möglichkeiten, Backup und Recovery zu optimieren. Um die Größe der
Backup-Datei zu mindern, lassen sich die Daten komprimieren. Sinnvollerweise sollte dies geschehen,
bevor das Backup über das Netzwerk geschickt wird. Die Funktionen des SQL-Server-eigenen Backups
sind dabei begrenzt, auch wenn Microsoft in der Version von 2008 nachgebessert hat. So ist es jetzt
zwar möglich, das Backup zu komprimieren, diese Funktion ist jedoch nicht besonders flexibel. Die
Wahl eines Komprimierungslevels kann für die Optimierung von Backup und Restore jedoch wichtig sein
und muss im konkreten Fall entschieden werden: Je höher die Komprimierung, desto kleiner die
Backup-Datei und entsprechend weniger Zeit benötigt das Restore. Andererseits benötigt das Backup
selbst umso mehr Zeit, je höher der Komprimierungslevel ist. Wie effektiv eine solche Komprimierung
ist, hängt auch von der verwendeten Hardware ab. SQL Server bietet keine Möglichkeit, dies vorher
zu testen oder zu analysieren.
Um hohen Sicherheitsanforderungen zu entsprechen, kann eine Verschlüsselung des Backups
notwendig sein. Microsoft bietet mit SQL Server 2008 die Möglichkeit, Daten oder ganze Datenbanken
transparent zu verschlüsseln. Dies hebt jedoch den Vorteil der Backup-Komprimierung auf, da sich
verschlüsselte Daten deutlich weniger komprimieren lassen. Abgesehen davon werden die wenigsten
Unternehmen jetzt sofort auf die neue Version von SQL Server migrieren, sodass ihnen die neuen
Funktionen zunächst verwehrt bleiben.
Diese Lücken schließen Produkte von Drittanbietern wie beispielsweise Litespeed for SQL Server
von Quest Software. Microsoft selbst testete die Lösung anhand einer 1 TByte großen Datenbank. Die
Lösung benötigte für die Sicherung der gesamten Datenbank nur 31 Minuten, das Backup war etwa 115
GByte groß. Bei SQL Server selbst (Versionen vor 2008) entspricht die Größe des Backups der
Nettodatenmenge der Datenbank, in diesem Testfall tatsächlich knapp 1 TByte. Die Komprimierung auf
der Server-Seite sorgt für kleinere Backups und eine schnellere Ablage auf dem gewählten
Speichersystem. Da sich zusätzlich der CPU-Bedarf für das Backup begrenzen lässt, ist der Einfluss
auf die Netzwerkleistung bestimmbar.
Über die Komprimierung hinaus bieten solche Softwarelösungen zusätzliche Vorteile. Bei der
Auswahl eines Produkts kommt es darauf an, welche Anforderungen ein Unternehmen an Backup und
Recovery stellt. Abhängig von den vorherrschenden Sicherheitsanforderungen kann es sinnvoll sein,
die Daten zu verschlüsseln und gleichzeitig zu komprimieren. Häufig ist es nützlich, lediglich
einzelne Objekte oder sogar Tabellenzeilen wiederherzustellen, anstatt die gesamte Datenbank
zurückzuspielen. Dieses sogenannte Object Level Restore spart Zeit, Geld und Netzwerkverkehr und
erlaubt das Lesen von Datenbankinhalten aus Sicherungsdateien, ohne eine unter Umständen sehr große
Datenbank komplett wiederherstellen zu müssen. Darüber hinaus kann Litespeed mit seinem Log Reader
auf die SQL-Server-Transaktions-Logs zugreifen und alle Änderungen in der Datenbank mit Datum und
Transaktions-ID analysieren.
Nutzen Administratoren das SQL-Server-eigene Backup, besteht keine Möglichkeit, verschiedene
Optionen vorher zu prüfen. Die optimalen Einstellungen für ein effektives Backup variieren jedoch
in Abhängigkeit von der vorhandenen Hardware, der Art des Speichersystems sowie vom Charakter der
Daten. Noch interessanter wird es, wenn verschiedene Datenbanksysteme im Einsatz sind. Einige der
Lösungen von Drittanbietern stellen komfortable Repositorien bereit, die einen Überblick über alle
Backup- und Restore-Aktivitäten geben. Bei der Auswahl eines Produkts ist es wichtig zu prüfen, ob
es sich nahtlos in die SQL-Server-Umgebung integrieren lässt. Microsoft stellt dafür das VDI
(Virtual Device Interface) zur Verfügung. Ebenso wichtig ist es, dass ein mit einem Fremdprodukt
erstelltes Backup auch dann gelesen werden kann, wenn bei einem Restore dieses Fremdprodukt nicht
zur Verfügung stehen sollte.
Fazit
Zwar bietet SQL Server nützliche Optionen für das Backup an, diese lassen sich jedoch durch
Softwarelösungen von Drittanbietern sinnvoll erweitern. Vor allem die Komprimierung vor der
Übertragung über das Netzwerk und die Verschlüsselung der Daten sind zwei Funktionen, die im
Hinblick auf Kosten- und Zeiteinsparungen sowie Sicherheit zunehmend an Relevanz gewinnen.
Lesen Sie mehr zum Thema
