Erforderliches Verhalten für Schattenkopieanbieter
Ein Schattenkopieanbieter muss richtlinienkonform sein, um die Kompatibilität des Anfordernden sicherzustellen. Zur Laufzeit muss eine Sicherungsanwendung oder eine andere Anfordernde, die Schattenkopien verwendet, ordnungsgemäß funktionieren, ohne dass sie über details zur Implementierung eines bestimmten Anbieters wissen muss.
Automatische Ressourcenverwaltung
Der Anfordernde muss einem Schattenkopiesatz einfach ein Volume hinzufügen können. Der Anfordernde kann Schattenkopieattribute wie VSS _ VOLSNAP _ ATTR _ TRANSPORTABLE, VSS _ VOLSNAP _ ATTR _ DIFFERENTIAL und/oder VSS _ VOLSNAP _ ATTR _ PLEX im _ VSS _ SNAPSHOT _ CONTEXTangeben. Der Anbieter muss diese Attribute verwenden. Wenn diese Attribute nicht unterstützt werden, sollte dies darauf hinweisen, dass der Schattenkopiesatz nicht unterstützt wird, indem * pbIsSupported in IVssHardwareSnapshotProvider::AreLunsSupported auf FALSE festgelegt wird.
Der Anbieter darf niemals zustimmen, eine Schattenkopie zu unterstützen, die er nicht erstellen kann. Wenn der Anfordernde kein Plex- oder differenzielles Attribut anberaumt, muss der Anbieter die automatische Logik für die Zuweisung von Subsystemspeicherplatz 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 werden Read-Only ausgeblendet.
VSS legt Flags für jede betroffene LUN so fest, dass die resultierenden Schattenkopievolumes ausgeblendet und schreibgeschützt sind, wenn sie von einem Computer erkannt werden, auf dem Windows Server 2003 ausgeführt wird. Laufwerkbuchstaben und bereitgestellte Ordner werden nicht automatisch zugewiesen. VSS verwaltet diese Flags während des gesamten Lebenszyklus einer Schattenkopie.
Hardwareschattenkopie-LUNs müssen gelesen/geschrieben werden
VSS unterstützt Hardwareschattenkopien nur, wenn die zugrunde liegende LUN als Lese-/Schreibzugriff zugeordnet ist. Dies muss vor dem Erstellen der Schattenkopie erfolgen. dies ist nach der Tatsache nicht mehr möglich. Hardwareanbieter sollten diese Flags nicht ändern. Weitere Informationen zur Verwendung dieser Flags durch VSS finden Sie unter Der Erstellungsprozess für Schattenkopien.
Der automatische Import von Hardwareschattenkopien wird für Windows Clusterdienst nicht unterstützt.
Windows Clusterdienst können LUNs mit doppelten Signaturen und Partitionslayout nicht aufnehmen. Die Schattenkopie-LUNs müssen auf einen Host außerhalb des Clusters transportiert werden. Weitere Informationen finden Sie unter Schnelle Wiederherstellung mit transportierbaren Schattenkopievolumes.
Schattenkopien, die dynamische Datenträger enthalten, müssen auf einen anderen Host transportiert werden.
Vor Windows Server 2008: Die native Unterstützung für dynamische Datenträger kann LUNs mit doppelten Signaturen und Konfigurationsdatenbankinhalten nicht unterstützen. Die Schattenkopie-LUNs müssen auf einen anderen Host transportiert werden. VSS erzwingt dies, indem automatischer Import von Schattenkopien von dynamischen Datenträgern nicht erlaubt wird. Eine anfordernde Person sollte keine transportierbare Schattenkopie zurück auf denselben Host importieren.
Ab Windows Server 2008: Diese Einschränkung wurde entfernt.
Anbieter sind out-of-Process
Alle Anbieter müssen als Out-of-Process-COM-Komponenten implementiert werden.
Time-Critical Vorgänge
Lange Vorgänge wie das Synchronisieren von Plexes sollten in IVssHardwareSnapshotProvider::BeginPrepareSnapshot initiiert werden. Diese Funktion sollte die asynchrone Vorbereitung starten und schnell zurückkehren. IVssProviderCreateSnapshotSet::EndPrepareSnapshots dient als "Rendezvous"-Funktion. Der Anbieter kann synchron in dieser Methode auf den Abschluss der Vorbereitungsarbeit warten, die von BeginPrepareSnapshot gestartet wurde.
Anbieter dürfen keine Verzögerungen in IVssProviderCreateSnapshotSet::P reCommitSnapshots, IVssProviderCreateSnapshotSet::CommitSnapshotsoder IVssProviderCreateSnapshotSet::P ostCommitSnapshots hinzufügen, da Anwendungen während dieser Aufrufe eingefroren werden. CommitSnapshots sollten innerhalb von Sekunden zurückgeben, da dies während des Leerens und Haltens aufgerufen wird, und vsS Kernel Support cancels the Flush and Hold if the release is not received within 10 seconds, which would VSS to fail the shadow copy creation process. Wenn der Anbieter mehr als einige Sekunden benötigt, um diesen Aufruf zu schließen, ist die Wahrscheinlichkeit hoch, dass die Erstellung der Schattenkopie fehlschlägt.
Sorgfältige E/A während CommitSnapshots
Hardwareanbieter sollten während CommitSnapshotskeine E/A-Bzw. E/A-Dienstleistungen für die volumes, die an der Schattenkopie beteiligt sind, machen müssen. Wenn E/A erforderlich sind, dürfen Anbieter keine E/A-Schritte für ein ursprüngliches Volume initiieren, während sie die CommitSnapshots-Methode behandeln.
Während CommitSnapshotsblockieren VSS Kernel Support-Treiber E/A auf den ursprünglichen Volumes, die schattenkopiert werden. Wenn der Anbieter synchrone E/A für ein Volume verwendet, das sich im Schattenkopiesatz befindet, wird diese E/A blockiert, und der Schattenkopie-Commitprozess wird deadlocked. Der Anbieter sollte keine Win32-APIs während CommitSnapshots aufrufen, da er eine hohe Wahrscheinlichkeit hat, E/A und einen Deadlock zu verursachen. Das VsS-Kernelunterstützungs-Timeout unterbricht diesen Deadlock nach 10 Sekunden, aber dies verursacht einen Fehler bei der Erstellung der Schattenkopie.
Wenn E/A-Vorgänge versucht werden müssen, muss dies asynchron erfolgen. Die E/A wird erst abgeschlossen, nachdem alle Anbieter von ihren CommitSnapshots-Methoden zurückgegeben wurden. Im Allgemeinen ist es besser, solche Vorgänge im PostCommitSnapshots-Aufruf durchzuführen.
Lese-/Schreibschattenkopie-LUNs
In dieser Version unterstützt VSS nur Lese-/Schreib-Schattenkopie-LUNs, auch wenn die Volumes als schreibgeschützt verfügbar gemacht werden. Der Grund dafür ist, dass das System Datenstrukturen auf dem Datenträger ändern muss, z. B.:
- Datenträgersignatur, die sich während des Schattenkopieprozesses ändert
- Partitionsbezogene Datenstrukturen, einschließlich derer, die angeben, dass die Partition schreibgeschützt, ausgeblendet, eine Schattenkopie ist und keinen Laufwerkbuchstaben zugewiesen werden sollte.
Eindeutige Informationen zu Seite 83
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 ein SPEICHERBEzeichner mit dem Typ 1, 2, 3 oder 8 und einer Zuordnung von 0 muss für die ursprüngliche LUN und die neu erstellte Schattenkopie-LUN eindeutig _ sein.