Erforderliche Verhaltensweisen für Schattenkopieanbieter

Ein Schattenkopie-Anbieter muss richtlinienkonform sein, um die Kompatibilität des Antragstellers sicherzustellen. Zur Laufzeit muss eine Sicherungsanwendung oder ein anderer Anforderer, der Schattenkopien verwendet, ohne kenntnis von spezifischen Implementierungsdetails des Anbieters ordnungsgemäß funktionieren.

Automagic Resource Management

Es muss möglich sein, dass der Antragsteller einfach einem Schattenkopiersatz ein Volume hinzufügen kann. Der Antragsteller kann Schattenkopieattribute wie VSS_VOLSNAP_ATTR_TRANSPORTABLE, VSS_VOLSNAP_ATTR_DIFFERENTIALund/oder VSS_VOLSNAP_ATTR_PLEX im _VSS_SNAPSHOT_CONTEXTangeben. Der Anbieter muss diese Attribute berücksichtigen. Wenn sie diese Attribute nicht berücksichtigen kann, sollte sie angeben, dass der Schattenkopiensatz nicht unterstützt wird, indem der *pbIsSupported- in IVssHardwareSnapshotProvider::AreLunsSupported auf FALSE-festgelegt wird.

Der Anbieter darf niemals zustimmen, eine Schattenkopie zu unterstützen, die nicht erstellt werden kann. Wenn der Antragsteller kein plex- oder differenzielles Attribut angibt, muss der Anbieter automagische Logik für die Zuordnung des Subsystembereichs für die Schattenkopie enthalten und die Schattenkopie mit der am besten geeigneten Methode erstellen. Der Hardwareanbieter darf keine anbieterspezifische API zum Verwalten der erforderlichen Schattenkopieeigenschaften enthalten.

Erstellte Schattenkopievolumes sind Read-Only und ausgeblendet

VSS legt Flags für jede betroffene LUN fest, sodass die resultierenden Schattenkopievolumes ausgeblendet und schreibgeschützt sind, wenn ein Computer mit Windows Server 2003 erkannt wird. Laufwerkbuchstaben und bereitgestellte Ordner werden nicht automatisch zugewiesen. VSS verwaltet diese Flags während des gesamten Lebenszyklus einer Schattenkopie.

Hardwareschattenkopie-LUNs müssen lese-/schreibgeschützt sein

VSS unterstützt Hardwareschattenkopien nur, wenn die zugrunde liegende LUN als Lese-/Schreibzugriff zugeordnet ist. Dies muss erfolgen, bevor die Schattenkopie erstellt wird; es kann nicht nach der Tatsache getan werden. Hardwareanbieter sollten diese Flags nicht ändern. Weitere Informationen dazu, wie VSS diese Flags verwendet, finden Sie unter Den Erstellungsprozess für Schattenkopien.

Hardwareschattenkopien werden vom Windows-Clusterdienst nicht unterstützt.

Der Windows-Clusterdienst kann LUNs nicht mit doppelten Signaturen und Partitionslayouts aufnehmen. Die Schattenkopie LUNs müssen an einen Host außerhalb des Clusters transportiert werden. Weitere Informationen finden Sie unter schnelle Wiederherstellung mit transportierbaren Schatten kopierten Volumes.

Schattenkopien, die dynamische Datenträger enthalten, müssen an einen anderen Host transportiert werden

Vor Windows Server 2008: Die systemeigene Unterstützung für dynamische Datenträger kann LUNs nicht mit doppelten Signaturen und Konfigurationsdatenbankinhalten aufnehmen. Die Schattenkopie LUNs müssen an einen anderen Gastgeber transportiert werden. VSS erzwingt dies, indem keine automatisch importierten Schattenkopien dynamischer Datenträger zugelassen werden. Ein Antragsteller sollte keine transportierbare Schattenkopie zurück in denselben Host importieren.

Ab Windows Server 2008: Diese Einschränkung wird entfernt.

Anbieter sind außerhalb des Prozesses

Alle Anbieter müssen als out-of-process COM-Komponenten implementiert werden.

Time-Critical Vorgänge

Lange Vorgänge wie Synchronisierungsplexes sollten in IVssHardwareSnapshotProvider::BeginPrepareSnapshotinitiiert werden. Diese Funktion sollte die asynchrone Vorbereitung starten und schnell zurückgeben. IVssProviderCreateSnapshotSet::EndPrepareSnapshots dient als "Rendezvous"-Funktion – der Anbieter kann synchron in dieser Methode warten, bis die Vorbereitungsarbeiten abgeschlossen wurden, die von BeginPrepareSnapshotgestartet wurde.

Anbieter dürfen keine Verzögerungen in IVssProviderCreateSnapshotSet::P reCommitSnapshots, IVssProviderCreateSnapshotSet:::CommitSnapshotsoder IVssProviderCreateSnapshotSet::P ostCommitSnapshots, da Anwendungen während dieser Aufrufe fixiert werden. CommitSnapshots- sollten innerhalb von Sekunden zurückgegeben werden, da dies während des Fensters "Leeren und Halten" aufgerufen wird, und die VSS-Kernelunterstützung bricht das Flush and Hold-Element ab, wenn die Freigabe nicht innerhalb von 10 Sekunden empfangen wird, was dazu führen würde, dass VSS den Erstellungsprozess der Schattenkopie fehlschlägt. Wenn der Anbieter mehr als ein paar Sekunden benötigt, um diesen Aufruf abzuschließen, besteht eine hohe Wahrscheinlichkeit, dass die Erstellung der Schattenkopie fehlschlägt.

Sorgfältige E/A während CommitSnapshots

Hardwareanbieter sollten während CommitSnapshotskeine E/A für die Volumes ausführen müssen, die an der Schattenkopie beteiligt sind. Wenn eine E/A erforderlich ist, dürfen Anbieter beim Behandeln der CommitSnapshots--Methode keine E/A mit einem ursprünglichen Volume initiieren.

Während CommitSnapshotsblockieren VSS-Kernelunterstützungstreiber E/A auf die ursprünglichen Volumes, die schatten kopiert werden. Wenn der Anbieter synchrone E/A für ein Volume verwendet, das sich im Schattenkopie-Satz befindet, wird diese E/A blockiert, und der Schattenkopie-Commitprozess wird inaktiviert. Der Anbieter sollte keine Win32-APIs während CommitSnapshots aufrufen, da sie eine hohe Wahrscheinlichkeit haben, dass E/A und ein Deadlock verursacht werden. Das Timeout der VSS-Kernelunterstützung unterbricht diesen Deadlock nach 10 Sekunden. Dies führt jedoch dazu, dass die Schattenkopie nicht erstellt wird.

Wenn E/A versucht werden muss, muss sie asynchron ausgeführt werden. Die E/A wird erst abgeschlossen, nachdem alle Anbieter von ihren CommitSnapshots- Methoden zurückgegeben haben. Im Allgemeinen ist es besser, solche Vorgänge im PostCommitSnapshots Aufruf auszuführen.

LuNs zum Lesen/Schreiben von Schattenkopien

In dieser Version unterstützt VSS nur LUNs mit Lese-/Schreibzugriff, auch wenn die Volumes schreibgeschützt verfügbar gemacht werden. Der Grund dafür ist, dass das System Datenstrukturen auf Datenträgern ändern muss, z. B.:

• Datenträgersignatur, die während des Schattenkopieprozesses geändert wird
• Partitionsbezogene Datenstrukturen, einschließlich derjenigen, die angeben, dass die Partition schreibgeschützt, ausgeblendet ist, eine Schattenkopie und sollte keine Laufwerkbuchstaben zugewiesen werden.

Eindeutige Seite 83-Informationen

Sowohl die ursprüngliche LUN als auch die neu erstellte Schattenkopie LUN müssen mindestens einen eindeutigen Speicherbezeichner in den Seiten 83-Daten enthalten. Mindestens eine STORAGE_IDENTIFIER mit einem Typ von 1, 2, 3 oder 8 und eine Zuordnung von 0 muss für das ursprüngliche LUN und die neu erstellte Schattenkopie LUN eindeutig sein.