Best Practices: Backup-Tipps für SQL Server

Das Datenbank-Backup ist eine der wichtigsten Aufgaben eines Datenbank-Administrators (DBA). Ein erfahrener DBA sollte jeden Server so konfigurieren können, dass sich die bestmögliche Datenbank-Strategie realisieren lässt. Allerdings bringen einige DBAs in Unternehmen nicht die nötige Erfahrung mit oder sind eventuell keine ausgebildeten DBAs. Diese Mitarbeiter sind aber verantwortlich für die Backups der Datenbanken. Im Laufe der Jahre habe ich viele falsch konfigurierte Backup-Pläne gesehen, die leicht zu Datenverlust führen. Dieser Beitrag über Best Practices von SQL-Server-Backups soll helfen, die Daten so gut wie möglich zu schützen. Außerdem sollten Sie anschließend eine Datenbank von einer Datensicherung wiederherstellen können, falls das notwendig ist.

Die erste Regel beim SQL-Server-Backup lautet: Sie können niemals genug Backups haben. Es gibt viele Szenarien, die einem erfolgreichen Backup in die Quere kommen können. Dazu gehören unter anderem fehlender Speicherplatz, Ausfall von Festplatten oder Netzwerk-Probleme. Manchmal ist die Überlegung verlockend, in Wirklichkeit gar keine Datensicherung zu benötigen. Zum Beispiel steht mit einer Spiegelung der Datenbanken immer eine Kopie auf einem anderen Server zur Verfügung. Dieser Umstand lässt Sie womöglich wesentlich ruhiger schlafen und nicht so häufig an differentielle oder komplette Backups denken. Allerdings habe ich es erlebt, dass eine Datensicherung bei solch einer Konfiguration nützlich sein kann. Wir hatten einen Festplatten-Ausfall auf einem Spiegel-Server und aus irgendwelchen Gründen hat sich der Microsoft Distributed Transaction Coordinator (MSDTC) verschluckt. Dadurch wurde die primäre Datenbank beschädigt und in den Status SUSPECT gesetzt. Wir konnten diese Datenbank nicht wieder online bringen und mussten sie mithilfe eines Backups wiederherstellen. Auch wenn Sie den Datenbank-Server spiegeln, können Sie nicht vollständig auf diesen Mechanismus zum Schutz der Datenbank vertrauen.

Viele Firmen setzen auf eine Kombination aus täglichem Komplett-Backup und periodischer Datensicherung der Transaktions-Logs. Mit dieser Strategie können Sie die Datenbank zum Zeitpunkt des letzten erfolgreichen Transaktions-Backups wiederherstellen. Allerdings dauert das unter Umständen eine Weile. Nehmen wir an, dass Sie ein komplettes Backup der Datenbank um Mitternacht machen und die Transaktions-Logs alle zehn Minuten sichern. Sollte Ihre Datenbank nach einem Crash um 22:05 Uhr wiederherstellt werden müssen, brauchen Sie dafür das volle Backup und 120 Log-Backups. Auf SQL Server Mangement Studio, das ein Restore-Script für alle Backups generiert, können Sie sich nicht ausschließlich verlassen. Warum ist das so? Das funktioniert nur für Datenbanken, deren Speicher für die Sicherung des Backup-Verlaufs noch intakt ist. Verlieren Sie aus bestimmten Gründen den kompletten Server und müssen diesen wieder aufbauen, ist das Einspielen der 120 Log-Backups reine Handarbeit. Dabei sind differentielle Backups hilfreich.

Ein differentielles Backup beinhaltet alle Änderungen, die seit der letzten vollen Datensicherung eingeflossen sind. Verwenden wir das oben beschrieben Szenario noch einmal und bauen ein differentielles Backup ein. Sie führen dies alle drei Stunden aus, beginnen um drei Uhr in der Nacht und beenden es 21:00 Uhr. Um die Datenbank 22:00 Uhr wiederherzustellen, müssten Sie das komplette Backup von Mitternacht und das neueste differentielle Backup (in diesem Fall von 21:00 Uhr) einspielen. Zusätzlich sind noch die letzten sechs oder sieben Log-Backups zwischen 21:00 und 22:00 Uhr notwendig. Sie sehen, dass die benötigte Zeit für eine Wiederherstellung deutlich reduziert wird. Differentielle Backups sind in den meisten Fällen schnell gemacht und die Datengrößen sind akzeptabel. Oftmals müssen Sie diese Datensicherungen nicht mal lange aufheben. Ein oder zwei Tage reichen in der Regel aus.

Zu den Best Practices von SQL-Server-Backups gehört auch die Verwendung von Kompressionen, wann immer dies möglich ist. Backup-Komprimierung (Backup Compression) wurde mit SQL Server 2008 eingeführt. Leider unterstützte bei dieser Version nur die Enterprise Edition diese Funktion. In SQL Server 2008 R2 hat Microsoft das Feature aber auch für die Standard Edition verfügbar gemacht. Backup-Komprimierung hat gleich mehrere Vorteile. Datenbanken sind schneller gesichert. Die Wiederherstellung ist ebenfalls schneller. Zudem sparen Sie Storage-Kapazitäten.

Der einzige Nachteil ist, dass während des Backups des SQL-Servers die CPU stärker beansprucht wird. Wenn Sie die Datensicherungen allerdings außerhalb der Geschäfts- oder Hochlastzeiten der Server machen, sollte dieser Umstand für die meisten Datenbank-Server kein Problem sein. In der Regel sind die Datenbank-Server mehr von I/O und weniger von der CPU abhängig. Verwenden Sie die eingebaute Funktion Database Maintenance Plans, können Sie die Komprimierung den Backup-Aufgaben zuweisen. Ich empfehle Ihnen das Standard-Verhalten in den Server-Einstellungen der Backup-Kompression anzuschalten. Auf diese Weise werden die Backups immer komprimiert, auch wenn die Option „WITH COMPRESSION“ nicht im Backup-Befehl enthalten ist.

Eine weitere wichtige Aufgabe ist das Testen des Wiederherstellungs-Prozesses. Sie sollten sich auch auf jeden Fall versichern, dass die Backups zuverlässig funktionieren. Im entsprechenden Task des Database Maintenance Plans gibt es eine Checkbox. Über diese können Sie spezifizieren, dass der SQL Server die Integrität der Backups überprüft. Lassen Sie diese Option immer aktiviert. Sollte ein Backup unbrauchbar sein, wird die Software dieses so kennzeichnen und Sie umgehend informieren. Glauben Sie aber nicht, dass eine Wiederherstellung möglich ist, nur weil eine Datei als „OK“ markiert ist. Natürlich können Sie nicht jedes Backup testen. Allerdings sollten Sie einen Wartungs-Plan für jede Datenbank aufstellen und eine Wiederherstellung von Zeit zu Zeit testen. Einmal im Monat wäre zum Beispiel adäquat.

Legen Sie eine Kopie der Backups an einem sicheren Ort ab. Schreiben Sie die Backups auf eine lokale Festplatte, sichern Sie diese Dateien zusätzlich auf Band oder über das Netzwerk. Somit schützen Sie sich, wenn der Datenbank-Server komplett abstürzt. Was passiert aber, wenn das komplette Data Center beschädigt wird? Mögliche Ursachen sind Feuer, ein Unwetter oder irgendein anderes Desaster. Um einen totalen Schutz zu haben, sollte Ihre Backup-Strategie auch hierfür einen Plan vorsehen. Die Datenbänder an einem anderen Ort auslagern, würde das Problem lösen.