So sichern Sie SQL-Datenbanken auf einer Netzwerkfreigabe

Das regelmäßige Sichern von SQL-Datenbanken ist ein Muss. Wir haben bereits Möglichkeiten aufgezeigt, wie Sie problemlos alle Ihre SQL Server-Datenbanken auf einer lokalen Festplatte sichern können. Dies schützt jedoch nicht vor Laufwerks- und / oder Systemausfällen. Als zusätzliche Schutzschicht gegen diese Art von Katastrophen können Sie Ihre Sicherungen auf einer Netzwerkfreigabe kopieren oder direkt erstellen.

Lokal sichern und dann auf die Netzwerkfreigabe kopieren

Der bevorzugte und direkteste Weg, um diese Aufgabe auszuführen, besteht einfach darin, eine lokale Sicherung einer Datenbank zu erstellen und dann die entsprechende Sicherungsdatei auf eine Netzwerkfreigabe zu kopieren. Sie können dies tun, indem Sie ein Batch-Skript erstellen, das folgendermaßen aussieht:

SET LocalFolder = C: ProgrammdateienMicrosoft SQL ServerMSSQL.1MSSQLBackup
SqlCmd -E -Q "Sicherungsdatenbank MyDB To Disk ="% LocalFolder% MyDB.bak ""
XCopy "% LocalFolder% MyDB.bak" "\ 192.168.16.55BackupDatabases" / Z / V
DEL "% LocalFolder% MyDB.bak"

Dieses Skript führt (zeilenweise) Folgendes aus:

1. Legt eine Variable auf das lokale SQL-Sicherungsverzeichnis fest.
2. Erstellt eine SQL-Sicherung von MyDB (mit Windows-Authentifizierung) im lokalen SQL-Sicherungsverzeichnis.
3. Kopiert die lokale Sicherungsdatei in eine Netzwerkfreigabe.
4. Löscht die lokale Sicherungsdatei.

Auch dies ist die bevorzugte Methode, da sie sofort einsatzbereit ist und die Wahrscheinlichkeit eines Sicherungsfehlers minimal ist, da die Sicherung auf einer lokalen Festplatte erstellt wird. Wenn Sie jedoch nicht über genügend Speicherplatz verfügen, um lokale Kopien von Sicherungsdateien zu speichern, schlägt diese Aktion fehl. In diesem Fall müssen Sie zusätzlichen Speicherplatz oder ein Backup direkt auf einer Netzwerkfreigabe hinzufügen.

Direktes Backup auf eine Netzwerkfreigabe

Wenn Sie versuchen, eine Sicherung direkt auf einer Netzwerkfreigabe mit einem Befehl wie dem folgenden zu erstellen:

SqlCmd -E -Q "Sicherungsdatenbank MyDB To Disk =" \ 192.168.16.55BackupDatabasesMyDB.bak ""

Sie werden höchstwahrscheinlich einen Fehler wie folgt erhalten:

Meldung 3201, Ebene 16, Status 1, Server-JF, Zeile 1
Sicherungsgerät '\ 192.168.16.55BackupDatabasesMyDB.bak' kann nicht geöffnet werden. Betriebssystemfehler 5 (Zugriff wird verweigert.).
Meldung 3013, Ebene 16, Status 1, Server-JF, Zeile 1
BACKUP DATABASE wird abnormal beendet.

Dieser Fehler tritt auf, obwohl Sie den SQL-Sicherungsbefehl mit der Windows-Authentifizierung (Schalter -E) und dem Windows-Konto ausgeführt haben, um über Windows Explorer auf Dateien zugreifen und sie auf die Freigabe kopieren zu können.

Der Grund für das Fehlschlagen dieser Aktion ist, dass der SQL-Befehl innerhalb der Grenzen des Kontos ausgeführt wird, unter dem der SQL Server-Dienst ausgeführt wird. Wenn Sie die Liste Dienste auf Ihrem Computer anzeigen, wird höchstwahrscheinlich der SQL Server-Dienst (Spalte "Anmelden als") entweder als lokales System oder als Netzwerkdienst ausgeführt, bei dem es sich um Systemkonten handelt, die keinen Netzwerkzugriff haben.

Auf unserem System schlägt die Sicherung auf einem Befehl zur Netzwerkfreigabe fehl, da der SQL Server-Dienst als lokales System ausgeführt wird, das wiederum keine Netzwerkressourcen erhält.

Damit SQL direkt auf einer Netzwerkfreigabe gesichert werden kann, müssen Sie den SQL Server-Dienst als lokales Konto ausführen, das Zugriff auf Netzwerkressourcen hat.

Bearbeiten Sie die Eigenschaften des SQL Server-Diensts, und konfigurieren Sie auf der Registerkarte Anmelden den Dienst so, dass er als alternatives Konto ausgeführt wird, das über Netzwerkzugriffsrechte verfügt.

Wenn Sie auf OK klicken, werden Sie gefragt, dass die Einstellungen erst wirksam werden, wenn der Dienst neu gestartet wird.

Starten Sie den Dienst neu.

In der Liste der Dienste sollte jetzt angezeigt werden, dass der SQL Server-Dienst als das von Ihnen konfigurierte Konto ausgeführt wird.

Wenn Sie jetzt den Befehl ausführen, um direkt auf einer Netzwerkfreigabe zu sichern:

SqlCmd -E -Q "Sicherungsdatenbank MyDB To Disk =" \ 192.168.16.55BackupDatabasesMyDB.bak ""

Sie sollten eine Erfolgsmeldung sehen:

Verarbeitet 152 Seiten für Datenbank 'MyDB', Datei 'MyDB' für Datei 1.
Verarbeitet 2 Seiten für Datenbank 'MyDB', Datei 'MyDB_log' in Datei 1.
BACKUP DATABASE hat erfolgreich 154 Seiten in 0.503 Sekunden (2.493 MB / Sek) verarbeitet.

Mit der Sicherungsdatei jetzt im Netzwerkfreigabeverzeichnis:

Überlegungen zur Netzwerkfreigabe

Beachten Sie, dass der Sicherungsbefehl eine direkte Verbindung mit der Netzwerkfreigabe erwartet, ohne dass Sie zur Eingabe der Anmeldeinformationen aufgefordert werden. Das Konto, für das Sie den SQL Server-Dienst als ausgeführt konfiguriert haben, muss über eine vertrauenswürdige Verbindung mit der Netzwerkfreigabe verfügen, von der aus die entsprechenden Anmeldeinformationen den Zugriff zulassen. Andernfalls kann ein Fehler wie dieser auftreten:

Meldung 3201, Ebene 16, Status 1, Server-JF, Zeile 1
Sicherungsgerät '\ 192.168.16.55BackupDatabasesMyDB.bak' kann nicht geöffnet werden. Betriebssystemfehler 1326 (Anmeldefehler: unbekannter Benutzername oder falsches Kennwort.).
Meldung 3013, Ebene 16, Status 1, Server-JF, Zeile 1
BACKUP DATABASE wird abnormal beendet.

Dieser Fehler zeigt an, dass der Benutzername und das Kennwort des Kontos von der Netzwerkfreigabe nicht akzeptiert wurden und der Befehl fehlgeschlagen ist.

Beachten Sie auch, dass die Sicherung direkt auf einer Netzwerkressource durchgeführt wird. Daher kann ein Fehler in der Netzwerkverbindung dazu führen, dass Ihre Sicherung fehlschlägt. Aus diesem Grund sollten Sie nur an stabilen Netzwerkstandorten sichern (d. H. Wahrscheinlich kein VPN)..

Auswirkungen auf die Sicherheit

Wie bereits erwähnt, wird die Verwendung der Methode bevorzugt, bei der Sie lokal sichern und dann auf eine Netzwerkfreigabe kopieren, da Sie damit den SQL-Dienst als Konto nur mit lokalem Systemzugriff ausführen können.

Wenn Sie den Dienst als alternatives Konto ausführen, öffnen Sie die Tür für potenzielle Sicherheitsprobleme. Beispielsweise könnte ein schädliches SQL-Skript unter dem alternativen Konto ausgeführt werden und Netzwerkressourcen angreifen. Darüber hinaus führen Änderungen am jeweiligen Konto (Änderungen / Ablaufen des Kennworts oder Löschen / Deaktivieren des Kontos) dazu, dass der SQL Server-Dienst nicht gestartet wird.

Beachten Sie diese Punkte, wenn Sie Ihre SQL Server-Instanz mit einem alternativen Konto ausführen. Dies sind zwar keine Show-Stopper, wenn geeignete Vorsichtsmaßnahmen getroffen werden, sollten Sie jedoch zusätzlichen Festplattenspeicherplatz hinzufügen und dann die lokale Sicherung und Kopie implementieren, damit Sie den SQL-Dienst mit einem lokalen Konto ausführen können.