SQL-Express Datenbank Backup – Grundlagen

von Philipp Stiefel, ursprünglich veröffentlicht 10. Januar 2017

Basierend auf einem Foto von Christian Bardenhorst, hier verwendet unter CC0-Lizensierung

Microsoft SQL Server Express ist die kostenlose Edition von Microsofts SQL Server. SQL Server und besonders die Express Edition sind der natürliche Upgrade-Pfad von einer Access Anwendung mit reinem Access Backend, die in Bezug auf die Größe, die Anzahl der Benutzer und/oder die Anforderungen an die Sicherheit aus Access herausgewachsen ist.

Obwohl SQL Express kostenlos ist, bringt es tatsächlich alle Features mit, die man üblicherweise für den Backend-Server eines kleinen oder mittleren Datenbankprojektes benötigt. Alle, außer einem absolut kritischen. Es fehlt der SQL Agent. SQL Agent ist die Komponente des SQL Servers für die automatische Aufgabenplanung. Neben anderen nützlichen Anwendungsbereichen, wird sie verwendet um automatisch Backups deiner Datenbanken zeitgesteuert durchzuführen.

Ohne Backups kannst du bei einer produktiven Datenbank nicht auskommen. – Dass muss ich dir nicht erklären. – Hoffe ich.

SQL Express unterstützt die gleiche Backup-Funktionalität, wie die größeren Editionen des SQL Servers. Du kannst dort manuelle Backups genauso machen, wie du es mit der „Vollversion“ des SQL Servers machen würdest.

Wenn du dich jetzt erstmalig mit Backups auf dem SQL-Server auseinandersetzen musst, weil du deine Datenbank von Access auf den SQL Server upgesized hast, hast du vielleicht noch keine Vorkenntnisse zu diesem Thema. Da Backups kritisch sind, werde ich erstmal in die Theorie und Grundlagen von Backups auf dem SQL Server, inklusive SQL Express, abschweifen, bevor ich dir zeige wie du automatische Backups für SQL Express Datenbanken einrichten kannst.

Die Backup-Funktionalität des SQL Servers hat eine ganze Menge an Möglichkeiten. Da ich mich in diesem Artikel auf den Anwendungsbereich von SQL Express konzentriere, können wir aber damit davonkommen, uns nur die grundlegenden Optionen anzuschauen.

Wenn du ein manuelles Backup deiner Datenbank machst, wirst du höchstwahrscheinlich ein Komplett-Backup der Datenbank machen.

Dazu markierst du die Datenbank in der Objekt-Explorer-Baumstruktur des SQL Server Management Studios, und klickst den Sichern…-Eintrag im Untermenü Tasks des Kontextmenüs an. In dem Dialog fügst du eine Datei hinzu, indem du einen Ordner auswählst und den gewünschten Dateinamen angibst.  Du kannst dann OK klicken und der SQL Server erstellt ein Backup deiner Datenbank. – Einfach.

Wenn du dich darauf verlassen musst, dass das Backup konsistent erstellt wurde, solltest du, bevor du OK klickst, noch auf das Tab Optionen des Dialoges wechseln und dort die Option Sicherung nach dem Abschluss überprüfen aktivieren.

Wichtig: Wenn du eine produktive Datenbank sichern willst, um eine Kopie für deine Entwicklungsumgebung zu erstellen, oder für irgendeinen anderen Zweck, der dazu führt, dass die Backup-Datei irgendwo anders hin verschoben wird als üblich, oder kurz nach dem Backup wieder gelöscht wird, dann solltest du unbedingt die Option Kopiesicherung aktivieren. Dadurch wird diese Sicherung nicht als Basis für nachfolgende differenzielle Backups verwendet. Falls das Wiederherstellungsmodell der Datenbank auf Vollständig gestellt ist, wird das Transaktionsprotokoll dann nicht abgeschnitten. - Ich erkläre gleich die unterschiedlichen Backup-Typen. Dann wird klar, warum das sehr wichtig ist.

Um Missverständnisse zu vermeiden, lass mich hier kurz das Konzept der Sicherungsmedien (Backup Devices) des SQL Servers erklären. Die Datei, die wir im Backup-Dialog ausgewählt haben, ist nicht einfach nur ein direktes Dateiabbild der Sicherung. Sie ist ein Sicherungsmedium und sie kann eine beliebige Anzahl an Sicherungen einer Datenbank enthalten. Wenn du den gleichen Dateinamen für eine weitere Sicherung der Datenbank angibst, wird die Datei mit den Standardeinstellungen nicht überschrieben, sondern der Sicherungsvorgang wird eine weitere, zusätzliche Sicherung in dieser Datei (Sicherungsmedium) speichern.

Ein sehr nützliches Feature, das durch die Sicherungsmedien ermöglicht wird, ist der Zeitstrahl, der bei der Wiederherstellung eines Backups mit dem SQL Server Management Studio aus einem Backup Device mit mehreren Sicherungen, angezeigt wird. Über den Zeitstrahl kannst du den Zeitpunkt/Zustand der Datenbank auswählen, der wiederhergestellt werden soll. – Dies wäre auch mit einzelnen, unabhängigen Backup-Dateien grundsätzlich ebenfalls möglich, aber dann musst du die anzuwendenden Sicherungsdateien selbst aus dem Dateisystem heraussuchen.

Auf der anderen Seite, entsteht mit der Zeit natürlich ein Problem, wenn du alle Backups in dieselbe Datei (Sicherungsmedium) schreiben lässt. Eine einzelne Datei wird mit der Zeit ziemlich groß und es wird komplizierter die Aufbewahrungsdauer einzelner Backups zu verwalten. Daher ist es angeraten, die Backup-Dateien in gewissen Zeitabständen zu wechseln. Du solltest die Datenbank-(Sicherungs)-Größe sowie den weiteren Verwaltungsablauf der Backups bedenken, um eine sinnvolles Rotationsintervall der Backups festzulegen.

Wieviel Datenverlust bist du bereit zu tolerieren? – Du magst vielleicht schnell antworten: „Gar keinen!“

Natürlich, Sicherungen sind extrem wichtig. Also wäre es schön, wenn wir alles ständig sichern würden. Du kannst das anstreben, aber es hat seinen Preis dies mit einer vernünftigen Verlässlichkeit umzusetzen.

Sicherungen benötigen Speicherplatz. Ja, Speicherplatz ist billig heutzutage und die Datenbankgröße einer SQL-Express-Datenbank ist ohnehin auf 10 GB begrenzt. Dies wird also wahrscheinlich nicht die primäre Restriktion sein. Bedenke dennoch, dass du mehr als nur die Backups von ein paar Tagen aufheben musst, um gegen jedes mögliche Szenario von Datenverlust gewappnet zu sein.

Der Backup-Vorgang beeinträchtigt die Performance. Ein Datenbank-Backup auf der Festplatte zu erstellen, beansprucht einiges an Festplattendurchsatz, Arbeitsspeicher und CPU-Leistung, die währenddessen nicht mehr für die normale Arbeit des SQL Servers zur Verfügung steht. Diese Performancebeschränkung kann durchaus auch für die Nutzer deiner Anwendung spürbar sein und es kann auch einige Minuten dauern, eine große Datenbank zu sichern. – Bedenke, wir befinden uns hier immer noch in den Grenzen von SQL Express. Eine terabyte-große Datenbank zu sichern dauert wesentlich länger.

Die Backups auf irgendwo anders hin zu verschieben beleget Netzwerkbandbreite. Backups, die einfach nur auf demselben Rechner wie die Datenbank bleiben, sind immer noch in Gefahr. Um für Szenarios, wie z.B. ein Feuer im Gebäude vorbereitet zu sein, muss du (eine Kopie) deiner Backups an einem anderen Ort speichern.

Jetzt frage ich erneut: Wieviel Datenverlust bist du bereit zu tolerieren?

Es gibt verschiedene Typen von Sicherungen, die du mit dem SQL Server erzeugen kannst. Du solltest zumindest die Grundlagen der gängigsten Backup-Typen kennen.

Vollständige Datenbank Backups

Wie der Name bereits andeutet, enthält ein vollständiges Datenbank-Backup alles was benötigt wird, um eine Datenbank nach einem Totalverlust wiederherzustellen. Sie sind einfach zu verstehen und einfach zu handhaben. Ihr Nachteil ist die beträchtliche Größe und die beträchtlichen Ressourcen, die es kostet, um sie für eine große Datenbank zu erstellen.

Differentielle Backups

Differentielle Backups enthalten nur die Änderungen in deiner Datenbank seit der letzten vollständigen Sicherung. Um eine Datenbank auf den Stand einer Differentiellen Sicherung wiederherzustellen, benötigst du die Differentielle Sicherung und die letzte vollständige Sicherung vor dieser Differentiellen Sicherung. Wenn du nicht einfach nur den neusten Stand deiner Datenbank wiederherstellen willst, kann das bedeuten, dass du eine ganze Reihe von Dateien durchgehen musst, um deine DB wieder in den gewünschten Zustand zu bringen.

Der positive Aspekt von Differentiellen Backups ist, dass sie wesentlich schneller erstellt werden können und dass sie nur einen Bruchteil des Speicherplatzes benötigen. Sie erzeugen weniger Last auf dem Server und du kannst sie wesentlich einfacher und schneller an einen anderen Ort kopieren oder verschieben. Also kannst du viel häufiger solche Backups machen, ohne dass es einen spürbaren, negativen Effekt hat.

Die Tatsache, dass differentielle Sicherungen wesentlich häufiger erstellt werden können, reduziert natürlich die Zeit zwischen zwei Backups. Allerdings ändern sie nichts an der grundlegenden Tatsache, dass du alle Änderungen nach der letzten Sicherung verlieren wirst, wenn wirklich eine Katastrophe eintritt.

Backups des Transaktionsprotokolls

Wenn du tatsächlich anstrebst, im Falle eines Desasters überhaupt keinen Datenverlust zu haben, musst du auch die Transaktionsprotokolle des SQL Servers sichern. Wenn das ungesicherte Ende des Transaktionsprotokolls nicht bei dem vernichtenden Ereignis zerstört wurde, ermöglicht diese Backup-Strategie eine point-in-time-recovery bis zum exakten Zeitpunkt der Störung.

Der Nachteil ist, dass die Transaktionslogdateien wesentlich größer werden, da kein Speicherplatz wiederverwendet werden darf, bis die Logdatei gesichert wurde. Sicherungen des Transaktionsprotokolls erfordern es, dass das Wiederherstellungsmodell für deine Datenbank auf Vollständig eingestellt wird.

Ich werde hier nicht tiefergehend auf die Sicherung des Transaktionsprotokolls eingehend, da ich davon ausgehe, dass du nicht die Express Edition des SQL Servers verwenden würdest, wenn deine Anwendung dieses Maß an Datensicherheit benötigt.

Wir haben nun die Grundlagen der Datensicherung mit dem SQL Server soweit behandelt, wie ich denke, dass jeder der mit dem SQL Server arbeitet, sie kennen sollte. Es gib weitere Themen, wie z.B. Partielle Backups, und Mediensätze die du ebenfalls kennen solltest, wenn du für eine wirklich große SQL Server Datenbank verantwortlich bist. Diese gehen jedoch weit über den Rahmen einer „kleinen“ SQL Express Datenbank hinaus.

Jetzt sind wir gut vorbereitet, um eine Sicherungsstrategie für unsere SQL Express Datenbank praktisch umzusetzen. Wie wir das ohne den SQL Agent technisch gut lösen können, erkläre ich im zweiten Artikel dieser Miniserie.

Share this article: