Wir wurden gefragt, ob wir nicht einmal etwas zur Sicherung von MSSQL mit NetWorker schreiben können.
Da die NetWorker Dokumentation und der Compatibility Guide schon sehr aussagekräftig sind und beschreiben, wie man das Backup einrichtet, möchten wir an dieser Stelle unsere Empfehlungen und eine Übersicht der Möglichkeiten bereitstellen.
NetWorker und MSSQL sich eine ziemlich gute Kombination. Es werden alle MSSQL Konstellationen unterstützt, egal ob Single-Node, schwenkbarer Cluster oder AAG.
Über den NMC Wizard kann man mit wenigen Klicks einen kompletten Cluster ins Backup aufnehmen, da NetWorker sich mit dem Cluster unterhält und erkennt, was dieser für Ressourcen (z.B. AAGs) hat. Es ist möglich, auch nur ausgewählte Datenbanken oder Instanzen zu sichern, bzw. Datenbanken zu exkludieren. Neue Datenbanken in einer Instanz werden automatisch erkannt und gesichert, sofern man die komplette Instanz ins Backup aufgenommen hat. Hat man nur einzelne Datenbanken aufgenommen, funktioniert dieser Automatismus natürlich nicht.
All diese Dinge können natürlich auch restored werden. Bei NetWorker Versionen unter 19 gibt es dazu zwei Möglichkeiten:
1) Der NetWorker User for SQL Server. Dieser wird automatisch mitinstalliert und bietet Features wie z.B. Restores von mehreren Datenbanken auf einen anderen Server. Allerdings unterstützt das Tool keine AAGs.
2) Das SQL Server Managament Studio (SSMS) Plugin. Dieses kann optional (bzw. unsere Empfehlung: Immer mitinstallieren) bei der Installation ausgewählt werden und unterstützt auch AAGs. Allerdings kann man, wenn man Datenbanken von einem anderen Server restoren möchte, nur jeweils eine Datenbank restoren. Wenn man mehrere Datenbanken vom aktuellen Server restoren möchte, geht dies jedoch.
Mit NetWorker 19 wurde der NetWorker User for SQL abgeschafft. D.h. hier gibt es nur noch das SSMS Plugin mit den oben genannten Vor- und Nachteilen.
Mit beiden Tools kann man Ad-hoc Backups durchführen, sodass z.B. auch der DBA Backups erstellen kann, falls er gerade eines braucht.
Mit dem Nachteil beim SSMS Plugin mit dem Restore von mehreren Datenbanken muss man leider leben, es sei denn, dass Dell EMC hier noch etwas ändert. Es gibt jedoch die Möglichkeit, Restores auch auf der Kommandozeile zu starten. Hier könnte man sich z.B. Batch-Dateien erstellen, die nacheinander, oder wenn man mehrere Dateien gleichzeitig startet, auch gleichzeitig Restores durchführt.
Bei MSSQL gibt es drei, bzw. vier verschiedene Backup Level. Im Gegensatz zu anderen Datenbanken (z.B. Oracle) hat NetWorker hier auch die Hoheit über die Backup Level und erkennt aufeinander aufbauende Backups, sodass ein Full Backup, dessen Aufbewahrungszeit abgelaufen ist, auch erst gelöscht wird, wenn alle darauf aufbauenden Backups ebenfalls abgelaufen sind.
Folgende Backup Level werden unterstützt:
Full – Recht eindeutig 🙂
Level 1 (auch Differential oder Cumulative Incremental genannt) – Sichert die Änderungen zum letzten Full Backup
Incremental – Sichert die Transaction Logs und schneidet sie ab.
Logs Only – Im NetWorker auch txnlog genannt. Sichert ebenfalls die Transaction Logs und schneidet diese ab. Ob man Incremental oder Logs Only nimmt, ist egal.
Man kann die gleiche Client Ressource verwenden und sie in unterschiedliche Gruppen stecken, z.B. um in einer Gruppe Full & Diff Backups zu machen und mit einer anderen Gruppe dann die Transaction Logs zu sichern. Dies ist auch unsere Empfehlung. Je nach Bedarf kann man die Client Ressource kopieren. Z.B. wenn man unterschiedliche SLA-Anforderungen für einzelne Datenbanken hat und bestimmte Datenbanken öfters sichern möchte.
In den Application Information der Client Ressource kann man mit Parametern einige Dinge beeinflussen. Der Wizard fragt diese ebenfalls ab.
In der Dokumentation gibt es für alle Parameter auch eine Beschreibung.
Diese drei Parameter sollten unserer Meinung nach auf die folgenden Werte gesetzt werden:
NSR_SKIP_SIMPLE_DB=TRUE
Wenn sich eine Datenbank im Simple Recovery Model befindet, schreibt sie keine Transaction Logs. Steht dieser Parameter auf False, bedeutet dies, dass der NetWorker bei einem Transaction Log Backup stattdessen ein Full Backup durchführt. Das will man im Normalfall aber nicht. Der Parameter gilt ausschließlich für die Backup Level incr und logs only.
NSR_SKIP_LOGGAP_DETECTION=FALSE
Wenn aus irgendeinem eine Lücke in den Transaction Logs ist (z.B. weil diese mit einem anderen Backup Tool gesichert worden sind oder weil der DBA diese abgeschnitten hat), führt dies dazu, dass eine Datenbank nicht mehr über die Transaction Logs zu einem beliebigen Zeitpunkt restored werden kann, bzw. nur noch bis zum Anfang der Lücke. Steht dieser Parameter auf TRUE, macht NetWorker trotzdem ein Backup und ignoriert die Lücke. Unsere Empfehlung ist hier FALSE. In dem Fall beendet sich das Backup mit einem Fehler, sodass man über dieses Problem unterrichtet wird und klären kann, wo das herkommt.
NSR_SKIP_NON_BACKUPABLE_STATE_DB=TRUE
Datenbanken können sich in einem Modus befinden, in dem sie nicht gesichert werden können. Z.B. können sie offline sein oder es kann gerade ein Restore laufen. Setzt man diesen Parameter auf TRUE, versucht NetWorker nicht, die betroffenen Datenbanken zu sichern. Im Normalfall gibt es ja einen Grund dafür, dass sie sich in diesem Status befinden, daher kann NetWorker diese Datenbanken unserer Meinung nach ruhig überspringen. Möchte man doch über solche Vorkommnisse unterrichtet werden, setzt man ihn auf FALSE.
Seit 2006 bin ich im Data Protection Bereich tätig und habe über die Jahre Erfahrungen mit diversen Produkten sammeln können. Darunter NetBackup, Avamar und natürlich vor allem NetWorker. Mit NetWorker habe ich seit meiner Ausbildung zum Fachinformatiker – Fachrichtung Anwendungsentwicklung – zu tun und habe mich auch auf diesen spezialisiert – vor allem in Kombination mit der Data Domain als Backup Storage. Darüber hinaus programmiere ich gerne in der Sprache Perl, sei es nun beruflich oder privat.
