Erstellung von Schattenkopien für Anbieter

Der Erstellungsprozess für Schattenkopien

Ein Anforderer ist die Anwendung, die die Anforderung initiiert, um eine Schattenkopie zu erstellen. In der Regel ist der Antragsteller eine Sicherungsanwendung. Bei Bedarf ruft VSS die beteiligten Anbieter an. Die meisten Anbieter interessieren sich für drei spezifische Anforderungen des Anforderers.

1. Der Anforderer beginnt die Schattenkopienerstellungsaktivität mit einem Aufruf von IVssBackupComponents::StartSnapshotSet. Dadurch wird eine GUID- vom Typ VSS_ID generiert, die diesen spezifischen Schattenkopiensatz eindeutig identifiziert – die SnapshotSetId. Der Anbieter ist in diesem Schritt nicht beteiligt, aber die SnapshotSetId wird in allen nachfolgenden Schritten umfassend verwendet.
2. Für jedes Volume, das er in diesen Schattenkopiensatz aufnehmen möchte, ruft der Antragsteller IVssBackupComponents::AddToSnapshotSetauf. VSS bestimmt, welcher Anbieter zum Schattenkopien des Volumes verwendet wird.
   • Mehrere Anbieter können an einem Schattenkopie-Satz teilnehmen. Wenn z. B. das Systemvolume und ein Datenvolume Teil desselben Schattenkopie-Satzes sind, kann der Systemanbieter als Schattenkopienanbieter für das Systemvolume dienen, während ein Hardwareanbieter als Schattenkopie-Anbieter für das Datenvolume dienen kann. Beide Anbieter wären Teil des gleichen Schattenkopie-Satzes, und der Benutzer würde die gleiche Punkt-in-Time-Konsistenz in beiden Volumes erwarten.
   • Damit ein Hardwareanbieter ausgewählt wird, muss der Hardwareanbieter alle LUNs unterstützen können, die zum angegebenen Volume beitragen.
   • Alle registrierten Anbieter erhalten die Möglichkeit, während der Schattenkopienerstellung Unterstützung für ein bestimmtes Volume anzugeben. Wenn mehr als ein Anbieter die Unterstützung angibt, verwendet VSS zuerst Hardwareanbieter, dann Softwareanbieter und schließlich den Systemanbieter (wenn kein anderer Anbieter die Unterstützung für dieses Volume angibt).
   • Ein Antragsteller kann diese Standardreihenfolge außer Kraft setzen, indem er explizit angibt, dass der Anbieter die Schattenkopie erstellen muss.
   • Wenn es mehrere Hardwareanbieter gibt, die ein bestimmtes Volume unterstützen, gibt es keine Garantie für die Reihenfolge, in der die Hardwareanbieter aufgerufen werden.
3. Nach einem oder mehreren Aufrufen von AddToSnapshotSet-kann der Antragsteller mithilfe der IVssBackupComponents::D oSnapshotSet-Methode die Schattenkopie erstellen. VSS arbeitet dann mit dem System zusammen, um die Schattenkopie zu erstellen. Die DoSnapshotSet--Methode führt diese Arbeit asynchron aus, und der Antragsteller kann entweder abfragen oder warten, bis der Schattenkopienerstellungsprozess abgeschlossen ist.

Dieses Diagramm zeigt die Interaktionen zwischen dem Anforderer, dem VSS-Dienst, der VSS-Kernelunterstützung, allen beteiligten VSS-Autoren und allen VSS-Hardwareanbietern. Eine detaillierte Beschreibung dieser Interaktionen finden Sie unter "Schattenkopienerstellungsprozess".

Wenn der Erstellungsprozess der Schattenkopie abgeschlossen ist, kann der Antragsteller ermitteln, ob die Erstellung der Schattenkopie erfolgreich war, und falls nicht, die Quelle des Fehlers ermitteln.

Das Zeitintervall zwischen dem Fixieren und dem Auftauen der Writer-Anwendungen muss minimiert werden. Der Anbieter muss asynchron alle Vorbereitungsarbeiten im Zusammenhang mit der Schattenkopie starten (z. B. ein Hardwareanbieter, der die Synchronisierung verwendet) in der IVssHardwareSnapshotProvider::BeginPrepareSnapshot Methode, und warten Sie dann auf die Fertigstellungen in der IVssProviderCreateSnapshotSet::EndPrepareSnapshots-Methode.

Es gibt mehrere Zeitlimitfenster, denen Anbieter folgen müssen. Daher führen gut verhaltene Anbieter vor IVssProviderCreateSnapshotSet::P reCommitSnapshots und nach IVssProviderCreateSnapshotSet::P ostCommitSnapshotsalle unnötigen Verarbeitungen durch.

Der Schattenkopiensatz wurde behoben, wenn DoSnapshotSet- aufgerufen wird. Zusätzliche Volumes können später nicht hinzugefügt werden, da die zusätzlichen Volumes nicht den gleichen Zeitpunkt gemeinsam nutzen würden.

Es gibt eine Beschränkung von 64 Volumes im Schattenkopiensatz. Ein bestimmtes Volume kann einem gesamten LUN, einem Teil einer LUN oder Teilen mehrerer LUNs zugeordnet werden. Die meisten Konfigurationen verfügen über ein Volume pro LUN, obwohl beliebige Zuordnungen möglich sind.

Es gibt keine Beschränkung für die Anzahl der Schattenkopiensätze oder die Anzahl der Schattenkopiensätze eines ursprünglichen Volumes. Ein Anbieter kann bestimmte Grenzwerte definieren oder basierend auf verfügbaren Hardwareressourcen dynamisch einschränken.

Point-in-Time für Writerless-Anwendungen

VSS enthält spezielle Unterstützung, die den Punkt in der Zeit definiert, der für alle Volumes in einem Schattenkopie-Satz gemeinsam ist. Hardwareanbieter müssen nicht direkt mit diesen Kerneltechnologien zusammenarbeiten, da sie als Teil der normalen Verarbeitung des Schattenkopie-Commits aufgerufen werden. Es ist jedoch hilfreich, die verwendeten Mechanismen zu verstehen, da sie die Definition von "Point-in-time" für Writerless-Anwendungen erläutert (Anwendungen, die keine VSS Writer-Schnittstelle verfügbar gemacht haben und daher nicht am Erstellungsprozess der Volumeschattenkopie teilnehmen.)

Diese VSS-Kernelunterstützung für gemeinsame Point-in-Time wird zwischen dem VolSnap.sys Treiber, den Dateisystemen und VSS verteilt.

1. Bevor die VSS-Kernelunterstützung aufgerufen wird, hat VSS bereits Folgendes:

   1. Bestimmt, welche Volumes an der Schattenkopie beteiligt werden sollen.
   2. Bestimmt, welcher Anbieter auf jedem Volume verwendet werden soll.
   3. Fixierte Anwendungen, die Fixierungs-/Thaw-Nachrichten akzeptieren.
   4. Bereitete die Anbieter für die Schattenkopie vor, indem die PreCommitSnapshots- Methoden aufgerufen werden. Alle Anbieter warten jetzt auf die eigentliche Erstellung von Schattenkopien.

2. Der Zeitpunkt wird dann erstellt. VSS löscht die Dateisysteme gleichzeitig auf allen Volumes, die schatten kopiert werden sollen.

   1. VSS gibt einen IOCTL_VOLSNAP_FLUSH_AND_HOLD_WRITES-Steuerelementbefehl auf jedem Volume aus, der die Dateisysteme löscht. Diese IOCTL wird an den Speicherstapel an VolSnap.sysübergeben. VolSnap.sys enthält dann alle Schreib-IRPs, bis Schritt 4 unten. Jedes Dateisystem (z. B. RAW) ohne Unterstützung für dieses neue IOCTL übergibt den unbekannten IOCTL-Code nach unten – wo es erneut von VolSnap.sysgehalten wird. Auf NTFS-Volumes wird durch die Flush auch das NTFS-Protokoll commitsiert.
   2. Dadurch werden alle NTFS/FAT-Metadatenaktivitäten angehalten; Die Dateisystemmetadaten werden sauber zugesichert.
   3. Die Schattenkopie sofort: VolSnap.sys bewirkt, dass alle nachfolgenden Schreib-IRPs auf allen Volumes in die Warteschlange gestellt werden, die Schatten kopiert werden sollen.
   4. VolSnap.sys wartet auf alle ausstehenden Schreibvorgänge auf die kopierten Schattenvolumes. Die Volumes sind nun in Bezug auf Schreibvorgänge still und waren auf genau dem gleichen Moment auf jedem Volume still. Es gibt keine Garantien für Schreibvorgänge an vom Benutzer zugeordnete Abschnitte oder Schreibvorgänge, die zwischen (a) und (b) auf Dateisystemen ausgegeben werden, die das leere IOCTL (e.g. RAW) nicht implementieren.

3. VSS weist jeden Anbieter an, die Schattenkopie zu übernehmen, indem die IVssProviderCreateSnapshotSet::CommitSnapshots Methoden aufgerufen werden. Die Anbieter sollten alle Vorbereitungen durchgeführt haben, damit dies ein schneller Vorgang ist.

   Beachten Sie, dass das E/A-System nur still steht, während diese CommitSnapshots Methoden ausgeführt werden. Wenn ein Anbieter eine Synchronisierung der QUELL- und Schattenkopie-LUNs durchführt, muss diese Synchronisierung abgeschlossen werden, bevor die CommitSnapshots--Methode des Anbieters zurückgegeben wird. Sie kann nicht asynchron ausgeführt werden.

4. Unmittelbar nachdem die CommitSnapshots Methode des letzten Anbieters zurückgegeben wurde, gibt VSS alle ausstehenden Schreib-IRPs (einschließlich der IRPs, die die Dateisysteme zum Abschluss ihrer Commitpfade blockieren) frei, indem ein weiteres IRP abgerufen wird, das an VolSnap.sysübergeben wurde.

5. Wenn der Schattenkopievorgang erfolgreich war, dann können Sie vsS jetzt:

   1. Ruft PostCommitSnapshots für die beteiligten Anbieter auf.
   2. Ruft CVssWriter::OnThaw für die beteiligten Autoren auf.
   3. Informiert den Antragsteller darüber, dass der Schattenkopieprozess abgeschlossen ist.

PreCommitSnapshots, CommitSnapshotssind PostCommitSnapshots zeitkritisch. Alle E/A von Anwendungen mit Autoren werden von PreCommitSnapshots auf PostCommitSnapshotsfixiert; alle Verzögerungen wirken sich auf die Anwendungsverfügbarkeit aus. Alle Datei-E/A, einschließlich schreibloser Anwendungs-E/A, werden während CommitSnapshotsangehalten.

Anbieter sollten alle zeitkritischen Arbeiten abschließen, bevor sie von EndPrepareSnapshotszurückkehren.

• CommitSnapshots- sollten innerhalb von Sekunden zurückgegeben werden. Die CommitSnapshots- Phase befindet sich im Fenster "Leeren und Halten". Die VSS-Kernelunterstützung bricht die Leerung und den Haltevorgang ab, die die E/A-Datei enthält, wenn die nachfolgende Version nicht innerhalb von 10 Sekunden empfangen wird, und VSS schlägt den Schattenkopienerstellungsprozess fehl. Andere Aktivitäten werden auf dem System ausgeführt, daher sollte sich ein Anbieter nicht auf die volle 10 Sekunden verlassen. Der Anbieter sollte win32-APIs nicht während des Commits aufrufen, da viele zu unerwarteten Schreibvorgängen und -blockieren führen. Wenn der Anbieter mehr als ein paar Sekunden benötigt, um den Anruf abzuschließen, gibt es eine hohe Wahrscheinlichkeit, dass dies fehlschlägt.
• Die vollständige Sequenz von PreCommitSnapshots zur Rückgabe von PostCommitSnapshots dem Fenster zwischen Autoren zugeordnet, die die Freeze- und Thaw-Ereignisse erhalten. Der Writer-Standardwert für dieses Fenster beträgt 60 Sekunden, aber ein Writer kann diesen Wert mit einem kleineren Timeout überschreiben. Beispielsweise ändert der Microsoft Exchange Server Writer das Timeout in 20 Sekunden. Anbieter sollten nicht mehr als eine Sekunde oder zwei in dieser Methode ausgeben.

Während CommitSnapshots muss der Anbieter keine Auslagerungsdatei-E/A vermeiden; Eine solche E/A hat eine sehr hohe Wahrscheinlichkeit für das Deadlocking. Insbesondere sollte der Anbieter keine Debug- oder Ablaufverfolgungsprotokolle synchron schreiben.