Importieren von transportablen schattenkopierten Volumes
Manchmal ist es wünschenswert, eine Schattenkopie auf einem System zu erstellen, aber die Schattenkopie auf einem zweiten System zu verwenden.
Betrachten Sie den Fall, in dem die zu sichernden Daten normalerweise von einem bestimmten System (systemOne) während des normalen Betriebs verwaltet werden und dass diese Daten physisch in einem Speicherarray oder einem Anwendung gespeichert werden.
Um Unterbrechungen von systemOne zu minimieren (da Sicherungsvorgänge ressourcenintensiv sein können), ist es wünschenswert, die Sicherung mit systemTwo durchzuführen, einem Sicherungsserver, der Zugriff auf dasselbe Speicherarray wie systemOne hat.
Die Schattenkopie sollte von systemOne ausgeführt werden, um eine ordnungsgemäße Schattenkopie zu gewährleisten – zusammenarbeiten mit den Autoren auf systemOne und bei bedarfsgerechtem Beibehalten des Zustands für laufende Aufgaben.
Daher muss systemOne eine transportierbare Schattenkopie erstellen, die systemTwo dann importiert.
Windows Server 2003, Standard Edition, Windows Server 2003, Web Edition und Windows XP: Transportable Schattenkopiersätze werden nicht unterstützt. Alle Editionen von Windows Server 2003 mit Service Pack 1 (SP1) unterstützen transportable Schattenkopiersätze.
Ein typisches Beispiel für das Importieren einer transportierbaren Schattenkopie kann wie folgt vorgehen:
Zunächst wird die vom Speicherarray bereitgestellte logische Einheit (LUN) als Volume auf systemOne (z. B. F:) eingebunden.
Ein Requester, der auf systemOne ausgeführt wird, instanziiert eine instance von IVssBackupComponents und fährt so fort, als würde er sich auf eine Sicherung vorbereiten. (Weitere Informationen finden Sie unter Übersicht über die Sicherungsinitialisierung, Übersicht über die Sicherungsermittlungsphase und Übersicht über Aufgaben vor der Sicherung .)
Der Anforderer auf systemOne ändert den Schattenkopiekontext, der normalerweise für den lokalen Sicherungsvorgang (VSS_CTX_APP_BACKUP) verwendet wird, um anzugeben, dass eine transportierbare Schattenkopie erstellt wird (VSS_VOLSNAP_ATTR_TRANSPORTABLE). Das transportierbare Attribut kann auch anderen Schattenkopiekontexten hinzugefügt werden.
Mit einem Schattenkopiekontext von VSS_CTX_APP_BACKUP | VSS_VOLSNAP_ATTR_TRANSPORTABLE erstellt der Anforderer, der sich auf systemOne befindet, eine Schattenkopie, indem er IVssBackupComponents::D oSnapshotSet aufruft.
SystemOne verwendet IVssBackupComponents::SaveAsXML , um den aktuellen Zustand des Sicherungskomponentendokuments und des IVssExamineWriterMetadata::SaveAsXML zu speichern, um die Writer-Metadatendokumente jedes Schreibers zu speichern. Die XML-Zeichenfolgen, die diese Dokumente enthalten, werden dann einem Anforderer zur Verfügung gestellt, der auf systemTwo ausgeführt wird.
Der Anforderer überträgt das Dokument der Sicherungskomponenten an systemTwo.
Beachten Sie, dass der Anforderer auf systemOne seine instance von IVssBackupComponents zu diesem Zeitpunkt nicht freigibt, wenn der Zweck der Schattenkopie für die Sicherung ist. Die Schnittstelle sollte geöffnet bleiben, bis systemTwo seine Sicherungsvorgänge erfolgreich abgeschlossen hat. Nur dann sollte der Anforderer ein BackupComplete-Ereignis ausstellen, da einige Autoren Protokolle abschneiden und nach einer erfolgreichen Sicherung andere Arbeiten ausführen. Wenn das Ziel der Schattenkopie Data Mining oder andere Zwecke ist, kann die Schnittstelle in diesem Schritt geschlossen werden.
Der Anforderer auf systemTwo ruft dann IVssBackupComponents::ImportSnapshots auf, um Zugriff auf die Schattenkopie zu erhalten, die vom Anforderer auf systemOne erstellt wurde.
Hinweis
Der Anforderer ist für die Serialisierung des Importschattenkopievorgangs verantwortlich. Wenn der Aufruf von IVssBackupComponents::ImportSnapshots fehlschlägt, sauber der VSS keine LUNs selbst auf. Der Anforderer muss die Bereinigung von LUNs initiieren.
Der Anforderer auf systemTwo fährt mit der Sicherung des kopierten Schattenmaterials genau so fort, als würde er eine Schattenkopie sichern, die er selbst erstellt hat (siehe Übersicht über die tatsächliche Sicherung von Dateien).
Der Anforderer auf systemTwo ruft das Geräteobjekt der Schattenkopie mithilfe von IVssBackupComponents::GetSnapshotProperties für die importierte Schattenkopie ab und fügt es an den Anfang der ursprünglichen Dateipfade an, die aus den Metadaten abgerufen wurden, um auf zu sichernde Dateien zuzugreifen.
Nach Der Verwendung der Schattenkopie muss der Anforderer auf systemTwo die Schattenkopie löschen. Wie bei nicht transportierbaren Schattenkopien führt das Freigeben von IVssBackupComponents unter systemTwo dazu, dass der VSS-Dienst die Schattenkopie löscht, wenn der Schattenkopienkontext automatisch freigegeben wird (z. B. VSS_CTX_BACKUP). Andernfalls muss der Anforderer auf systemTwo die Schattenkopie explizit löschen, wenn der Kontext eine dauerhafte Schattenkopie angibt (z. B. VSS_CTX_APP_ROLLBACK).
Anschließend signalisiert der Anforderer auf systemTwo dem Anforderer auf systemOne , dass er mit der Sicherung der transportierbaren Schattenkopie abgeschlossen ist.
Nachdem der Anforderer auf systemOne die Benachrichtigung erhalten hat, dass der Anforderer auf systemTwo die Sicherung der transportierbaren Schattenkopie abgeschlossen hat, benachrichtigt er die Writer auf seinem System, indem er ein BackupComplete-Ereignis mit einem Aufruf von IVssBackupComponents::BackupComplete generiert. An diesem Punkt kann der Anforderer auf systemOne seine instance von IVssBackupComponents freigeben.
Transportierbare Schattenkopien in einem Cluster: Transportable Schattenkopien müssen von außerhalb des Clusters importiert werden, solange das ursprüngliche Volume im Cluster eingebunden ist. Informationen zum Implementieren einer schnellen Wiederherstellung in einem Cluster finden Sie unter Schnelle Wiederherstellung mit transportablen Schattenkopiervolumes.