SQL Server-Sicherungen mit Volume Shadow Copy

9

Viele bekannte Sicherungsdienstprogramme für Windows verwenden den in neuere Windows-Versionen integrierten Volume Shadow Copy Service, um einen Zeitpunkt-Snapshot der Festplatte zu erstellen und geöffnete Dateien sicher zu sichern.

Aber wie gut spielt dieser Mechanismus mit SQL Server? Ich weiß, dass ein SQL Server VSS Writer vorhanden ist, der die Zusammenarbeit von Sicherungssystemen mit SQL Server unterstützt, aber nicht alle Sicherungssysteme kennen SQL Server und nutzen die darin enthaltene sichernbezogene API.

Meine Frage ist also, was ist mit den Programmen, die nichts über SQL Server wissen?

Vermutlich erhalten sie zu einem bestimmten Zeitpunkt eine Momentaufnahme der MDF- und LDF-Dateien, wie sie zu einem einzigen Zeitpunkt vorhanden waren. Und vermutlich ist das SQL Server-Datenformat robust genug, um sicherzustellen, dass ein solcher Snapshot konsistent und verwendbar ist.

Funktionieren die Dinge so oder fehlt mir etwas? Gibt es "Fallstricke" bei der Verwendung eines solchen Sicherungsmechanismus, oder wäre ich sicher?

— tylerl
quelle

8

Kurze Antwort: Sie spielen nicht sehr gut zusammen, es sei denn, Sie haben den SQL Server entsprechend konfiguriert (und selbst dann würde ich es nicht empfehlen).

Hier finden Sie viele Informationen zum gemeinsamen Spielen von VSS und MSSQL:
MSKB919023: SQL Server 2005-Konnektivität und Volume Shadow Copy Service (VSS) .

Ein Wort der Warnung:

Vermutlich ist das SQL Server-Datenformat robust genug, um sicherzustellen, dass ein solcher Snapshot konsistent und verwendbar ist

Das ist eine große Annahme, die leider nicht immer sicher ist. Aus diesem Grund sind Ihre MSSQL-Wartungspläne unerlässlich, um sicherzustellen, dass Sie sich von Katastrophen erholen können.

— Mark Henderson
quelle

6

Sie sichern niemals MDF- und LDF-Dateien.

Sie führen Sicherungen (Pläne, SQL, SMO usw.) durch und sichern diese Sicherungsdateien.

Ehrlich gesagt verstehe ich nicht, was ein Anbieter über VSS sagt. Ich mag auch keinen Anbieter, der ein SQL Server-Plugin für Backups hat. Sie verwenden nur native SQL Server-Sicherungen

Zu Ihrer Information: Sie schließen auch MDFs und LDFs vom Virenscan aus.

— gbn
quelle

2

Wenn Sie keine Software mit einer SQL-Option haben, dann:

Erstellen Sie SQL-Wartungspläne oder geplante Sicherungsjobs für die Datenbanken, sichern Sie sie auf der Festplatte und sichern Sie den Server. Oder wenn Sie sie sichern, sichern Sie sie direkt an Ihrem Sicherungsspeicherort, falls Sie einen haben.

— Der Reiniger
quelle

2

Das Hauptproblem bei der VSS-Sicherung wird durch das Zwischenspeichern auf dem SQL Server verursacht.

Der aktuelle Status auf Ihrer Festplatte enthält nicht immer alle Datenbankänderungen. Backupsoftware muss sich dessen bewusst sein, um sicherzustellen, dass der SQL Server alle Caches schreibt, bevor Sie einen Snapshot erstellen.

Trotzdem: Die sicherste Methode ist immer noch das Sichern in SQL Management / mit SQL Server Tools.

Und Sie sollten alle SQL Server-Daten und Sicherungsdateien von Virusscannern (.bak, .mdf, .ldf) ausschließen.

— Andreas Rehm
quelle

3

Der gesamte Zweck der VSS Requestor \ Writer-Architektur besteht darin, sicherzustellen, dass die vertrauende Anwendung (z. B. Ihre Sicherungsanwendung) den Eigentümer (SQL Server \ Exchange usw.) anweisen kann, alle zwischengespeicherten Daten zu leeren und Transaktionen zu öffnen und anschließend den Festplatten-Cache des Betriebssystems zu leeren Schnappschuss machen. Ob es gut funktioniert, ist ein weiteres Problem, aber die Architektur tut so viel wie möglich, um sicherzustellen, dass die Dateien konsistent sind.

— Helvick

2

ähm, nein. Sofern Sie keine verrückte Konfigurationsänderung vorgenommen haben, befindet sich eine festgeschriebene Transaktion auf der Festplatte. Im Cache ist nichts festgeschrieben, was nicht auch auf der Festplatte festgeschrieben ist.

— Longneck