DE112021004991T5

DE112021004991T5 - Verwaltung einer wiederherstellung eines datenspeicher-datenvolumens

Info

Publication number: DE112021004991T5
Application number: DE112021004991.7T
Authority: DE
Inventors: Lourie Goodall; Erika Dawson; Joseph M. Swingler
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2020-09-24
Filing date: 2021-09-16
Publication date: 2023-07-06
Also published as: KR20230056707A; AU2021348394B2; GB202305748D0; WO2022063020A1; US20220091944A1; US20220413973A1; JP2023542287A; GB2614675A; US11461193B2; CN116324732A; AU2021348394A1

Abstract

Es werden ein Computerprogrammprodukt, ein System und ein Verfahren zum Durchführen eines Restore an Datenvolumen in einem Datenspeichersystem bereitgestellt. Ein virtuelles Restore eines Datenvolumens von Daten, das in einem Speicher gespeichert ist, wird mithilfe eines Zieldatenvolumens durchgeführt. Das virtuelle Restore enthält ein Konfigurieren von Metadaten, die dem Zieldatenvolumen zugehörig sind, um das Zieldatenvolumen dem Wiederherstellungsdatenvolumen als virtuelles Restore des Wiederherstellungsdatenvolumens zuzuordnen. Als Reaktion auf eine Anforderung von Daten, die auf dem Wiederherstellungsdatenvolumen gespeichert sind, durch einen Host wird ein physisches Restore von Daten des Wiederherstellungsdatenvolumens mithilfe des Zieldatenvolumens durchgeführt. Das physische Restore enthält ein Übertragen von Daten auf das Zieldatenvolumen von dem Wiederherstellungsdatenvolumen, dem das Zieldatenvolumen durch das virtuelle Restore zugeordnet worden ist. Darüber hinaus werden übertragene Daten als Daten des Zieldatenvolumens statt als Daten des Wiederherstellungsdatenvolumens neu benannt.

Description

HINTERGRUND
Die vorliegende Erfindung bezieht sich auf ein Computerprogrammprodukt, ein System und ein Verfahren zum Verwalten einer Wiederherstellung eines Datenvolumens in einem Datenspeichersystem.
Zur Langzeitspeicherung von Daten sind verschiedene Speichereinheiten genutzt worden. Beispielsweise können Daten auf einem Magnetband gespeichert werden. Die Sammlung solcher Bänder wird häufig als Bandarchiv bezeichnet, und mithilfe eines Bandlaufwerks werden Daten auf die Bänder geschrieben und von diesen gelesen. Das Magnetband kann zum Beispiel in einer Kassette transportiert und bei Bedarf durch Roboter in ein Bandlaufwerk geladen werden. Wenn es in das Bandlaufwerk geladen ist, wird das Band der Kassette an einem Lese-/Schreibkopf des Bandlaufwerks vorbeigeführt, um zu ermöglichen, dass Daten auf das Band der Kassette geschrieben oder von diesem gelesen werden.
Mainframe-Hosts und Speichersteuereinheiten tauschen mithilfe von Bandprotokollen Daten mit Langzeitspeichereinheiten aus. Bei virtuellen Bändern emulieren Virtual Tape Server (virtuelle Band-Server, VTS) Bandeinheiten. Das TS7700 von der International Business Machines Corporation ist ein solcher VTS, der ein Bandarchiv mit Bandlaufwerken emuliert. Ein Mainframe-Host betrachtet das TS7700 als Bandarchiv. So erscheint ein virtueller Band-Server wie das TS7700 einem Mainframe-Host und tauscht Daten mit dem Mainframe-Host aus, als wäre er ein Bandarchiv. Statt mit physischen Bandkassetten arbeitet ein virtueller Band-Server jedoch mit logischen Datenvolumen, die man sich als virtuelle Banddatenvolumen vorstellen kann. So wie bei einer Bandkassette wird jedem logischen Datenvolumen eine VOLSER (volume serial number, Datenvolumen-Folgenummer) und eine Versionsnummer zugewiesen, die die jeweilige Version dieser Datenvolumen-Folgenummer kennzeichnet.
Bandarchive einer Bandspeichereinheit enthalten typischerweise eine Reihe leerer Bandkassetten, die zum Speichern von Daten bereit sind. Ein Mainframe-Host katalogisiert diese Banddatenvolumen nach ihrer VOLSER, um nachzuverfolgen, welche Banddatenvolumen verfügbar sind, welche Banddatenvolumen Daten enthalten und worin der Inhalt dieser Daten besteht. Wenn ein bestimmter Datensatz benötigt wird, weiß der Mainframe infolgedessen, welches durch seine VOLSER gekennzeichnete Banddatenvolumen aus dem Bandarchiv zu laden ist, um den bestimmten Datensatz aus dem Speicher abzurufen. Wenn die auf einem Banddatenvolumen gespeicherten Daten nicht mehr benötigt werden, kann das Banddatenvolumen in eine „Arbeits“-Kategorie versetzt werden, damit das Banddatenvolumen und seine zugehörige VOLSER wiederverwendet werden.
Bei einer bekannten Bandspeichereinheit katalogisiert und verwaltet ein Speicher-Manager diese Banddatenvolumen auch nach ihrer VOLSER. Anders als der Mainframe-Host kennt die Logik des Speicher-Managers der Bandspeichereinheit den Inhalt eines durch eine VOLSER gekennzeichneten Banddatenvolumens nicht, sondern verfolgt, wo in dem Bandarchiv das jeweilige Banddatenvolumen mit dieser VOLSER gespeichert wird und wie sie das Banddatenvolumenmit dieser VOLSER verwalten sollte (z.B. wie lange er aufzubewahren ist, nachdem er gelöscht worden ist, wie viele Kopien zu behalten sind, wo diese Kopien zu erstellen sind usw.).
Eine einzelne Bandkassette (VOLSER) kann eine große Menge an Daten speichern, daher packt der Host typischerweise eine große Menge an Daten zusammen, bevor er sie auf das Band schreibt. Eine VOLSER kann mehrere Datensätze (potenziell Tausende von Datensätzen) enthalten. Ein virtueller Band-Server wie zum Beispiel das TS7700 kann auch die VOLSER über einen durch einen Host-Benutzer angegebenen Zeitraum aufbewahren, selbst nachdem der Mainframe-Host die aktiven Daten freigegeben und die VOLSER als gelöscht markiert hat. Diese Praxis wird im Falle einer versehentlichen oder böswilligen Aktivität angewendet, bei der jemand die VOLSER in dem Host vorzeitig zum Löschen markiert. In einem TS7700 wird dies als Kategorieaufbewahrung bezeichnet. Ein Benutzer kann einen Aufbewahrungszeitraum von Stunden bis hin zu Jahren für ein beliebiges Datenvolumen mit Daten festlegen. Die in der VOLSER enthaltenen Daten werden jedoch letztendlich gelöscht.
Unabhängig davon, ob es sich um ein physisches Banddatenvolumen oder ein logisches Datenvolumen eines virtuellen Band-Servers handelt, entsteht gelegentlich die Notwendigkeit, ein Restore an einem Datenvolumen durchzuführen oder diesen wiederherzustellen. Möglicherweise ist zum Beispiel eine ältere Version eines Datenvolumens gelöscht worden, jedoch wird künftig erkannt, dass die bestimmte Version des Datenvolumens noch benötigt wird. Aus diesem Grund kann es wünschenswert sein, ältere Versionen von Daten aufzubewahren. Änderungen der Version eines logischen Datenvolumens treten auf, wenn keine der Daten darauf mehr gültig sind oder jegliche aktiven Daten aufgrund eines FREIGABE-Prozesses auf ein weiteres logisches Datenvolumen versetzt wurden. Dieses Datenvolumen würde gelöscht und wieder aufgenommen, um für neue Datenschreibvorgänge wiederverwendet zu werden. Die Versionen logischer Datenvolumen können sich auch ändern, wenn die Daten daran angehängt werden. In diesem Fall wird dieselbe VOLSER weiterverwendet, aber der Versionsstand ändert sich. In jedem dieser Fälle könnte die ältere Version der Daten je nach Bedarf des Benutzers für eine gewisse Zeit aufbewahrt werden, für den Fall, dass an einer älteren Version eines logischen Datenvolumens ein Restore durchgeführt oder diese wiederhergestellt werden muss.
Ein bekannter Wiederherstellungsprozess (der auch als Restore-Prozess bezeichnet wird) führt an der älteren Version des logischen Datenvolumens ein Restore zu einem Datenvolumen mit derselben VOLSER-Kennung (ID) wie das gelöschte Datenvolumen durch. Falls jedoch das Datenvolumen dieser VOLSER aktuelle gültige Daten enthält und ihm außerdem durch eine Aufbewahrungsrichtlinie eine „Rückstellungs“-Eigenschaft zugewiesen worden ist, würde ein Restore des Datenvolumens zu derselben VOLSER eine Rückstellungseigenschaft verletzen, die erfordert, dass das Datenvolumen ohne Modifizierung über einen vorgeschriebenen Rückstellungszeitraum zurückgestellt wird. Wenn die VOLSER des Datenvolumens, an dem ein Restore durchzuführen ist, als LWORM-Datenvolumen (Logical Write Once, Read Many) kategorisiert worden ist, verstößt es gleichermaßen gegen diese strengen Schutzregeln, wenn zugelassen wird, dass an dieser älteren Version ein Restore zu derselben VOLSER durchgeführt wird.
Ein weiterer bekannter Ansatz führt ein Restore an einer älteren Version eines Datenvolumens zu einer anderen Arbeits-VOLSER durch. Diese bekannten Restore-Verfahren erfordern jedoch, dass das Datenvolumen physisch kopiert oder in das Arbeitsdatenvolumen versetzt wird, bevor das Datenvolumen als ,restored' betrachtet wird. Ein(e) solche(s) physische(s) Kopieren oder Datenversetzung erfordert typischerweise, dass das Datenvolumen aus dem Speicher gelesen wird, die gelesenen Daten modifiziert werden und anschließend in die Speichereinheit zurückgeschrieben werden. Beispielsweise werden Daten, die von dem Datenvolumen, an dem ein Restore durchgeführt wird, gelesen werden, typischerweise neu benannt, indem Metadaten so aktualisiert werden, dass sie mit der VOLSER übereinstimmen, zu der das Restore durchgeführt wird. Auf diese Weise werden jegliche Metadaten, die eine Datei beschreiben oder in einer Datei enthalten sind, die auf die VOLSER verweist, so aktualisiert, dass sie die neue VOLSER anstelle der alten VOLSER benennen. Eine Modifizierung der Daten des Datenvolumens, an dem ein Restore durchgeführt wird, kann jedoch gegen rechtliche Beschränkungen für das Datenvolumen verstoßen, die eine Modifizierung oder einen Austausch der Daten verbieten. Darüber hinaus können die Daten eines Datenvolumens, das als schreibgeschützt markiert ist, wie zum Beispiel WORM (Write Once, Read Many), nicht modifiziert oder ausgetauscht werden, ohne gegen die Schreibschutzbeschränkung zu verstoßen.
KURZDARSTELLUNG
Es werden ein Computerprogrammprodukt, ein System und ein Verfahren zum Durchführen eines Restore an einem Datenvolumen für Daten in einem Speicher bereitgestellt. Ein virtuelles Restore eines ersten Datenvolumens von Daten, das in dem Speicher gespeichert ist, wird mithilfe eines zweiten Datenvolumens durchgeführt. Bei einer Ausführungsform sind die Metadaten, die dem zweiten Datenvolumen zugehörig sind, dazu konfiguriert, das zweite Datenvolumen dem ersten Datenvolumen als virtuelles Restore des ersten Datenvolumens zuzuordnen. In einem weiteren Aspekt wird als Reaktion auf eine Anforderung von Daten, die auf dem ersten Datenvolumen gespeichert sind, durch einen Host ein physisches Restore von Daten des ersten Datenvolumens mithilfe des zweiten Datenvolumens durchgeführt. Bei einer Ausführungsform enthält das physische Restore ein Übertragen von Daten auf das zweite Datenvolumen von dem ersten Datenvolumen, dem das zweite Datenvolumen durch das virtuelle Restore zugeordnet worden ist. Darüber hinaus werden übertragene Daten als Daten des zweiten Datenvolumens statt als Daten des ersten Datenvolumens neu benannt.
Bei der obigen Ausführungsform wird ein Zugreifen auf Daten des ersten Datenvolumens verzögert, bis ein Zugriff auf die Daten durch den Host angefordert wird. Infolgedessen wird ein schnelles und kostengünstiges Restore bei einem virtuellen Restore erleichtert. Des Weiteren kann eine Modifizierung von Daten auf dem ersten Datenvolumen in Verbindung mit einem Restore des ersten Datenvolumens während eines virtuellen und physischen Restore des ersten Datenvolumens vermieden werden. Dementsprechend kann ein Restore ungeachtet jeglicher Beschränkungen für eine Modifizierung von Daten des ersten Datenvolumens erreicht werden.
Bei einer weiteren Ausführungsform enthält das Übertragen von Daten auf das zweite Datenvolumen von dem ersten Datenvolumen ein Empfangen einer Anforderung durch den Host, das zweite Datenvolumen in ein Speicherlaufwerk zu laden, und als Reaktion auf die Anforderung: ein Laden des zweiten Datenvolumens in ein Speicherlaufwerk, Laden des ersten Datenvolumens in ein Speicherlaufwerk und Kopieren von Daten des ersten Datenvolumens, das durch die Metadaten für das zweite Datenvolumen dem zweiten Datenvolumen zugeordnet worden ist.
Bei der obigen Ausführungsform wird ein Laden des ersten Datenvolumens, um auf Daten des ersten Datenvolumens zuzugreifen, verzögert, bis ein Laden des zweiten Datenvolumens durch den Host angefordert wird. Infolgedessen erleichtert das virtuelle Restore ein schnelles und kostengünstiges Restore des ersten Datenvolumens, bis er für ein angefordertes physisches Restore geladen wird. Des Weiteren kann eine Modifizierung von Daten auf dem ersten Datenvolumen in Verbindung mit einem Restore des ersten Datenvolumens während eines virtuellen und physischen Restore des ersten Datenvolumens vermieden werden, da die Daten während des physischen Restore auf das zweite Datenvolumen und nicht auf das erste Datenvolumen neu benannt werden. Dementsprechend kann ein Restore ungeachtet jeglicher Beschränkungen für eine Modifizierung von Daten des ersten Datenvolumens erreicht werden.
Bei einer weiteren Ausführungsform enthält das Neubenennen von übertragenen Daten in Daten des zweiten Datenvolumens anstelle von Daten des ersten Datenvolumens ein Modifizieren von Header-Daten, die von dem ersten Datenvolumen gelesen werden, während Daten auf dem zweiten Datenvolumen gespeichert werden, um Daten, die von dem ersten Datenvolumen kopiert werden, als Daten für das zweite Datenvolumen statt für das erste Datenvolumen zu kennzeichnen, und so wird ein Modifizieren von Header-Daten, die von dem ersten Datenvolumen gelesen werden, verzögert, bis ein Zugriff auf die Daten durch den Host angefordert wird.
Bei der obigen Ausführungsform wird ein Neubenennen von Daten verzögert, bis ein Laden des zweiten Datenvolumens durch den Host angefordert wird. Infolgedessen erleichtert das virtuelle Restore ein schnelles und kostengünstiges Restore des ersten Datenvolumens, bis Daten für ein angefordertes physisches Restore neu benannt werden. Darüber hinaus kann eine Modifizierung von Header-Daten auf das erste Datenvolumen in Verbindung mit einem Restore des ersten Datenvolumens während eines virtuellen und physischen Restore des ersten Datenvolumens vermieden werden. Stattdessen werden Header-Daten des zweiten Datenvolumens modifiziert, um Benutzerdaten neu zu benennen, die auf das zweite Datenvolumen übertragen worden sind, und werden während des physischen Restore auf das erste Datenvolumen nicht modifiziert.
Bei einer weiteren Ausführungsform weist das erste Datenvolumen eine erste Datenvolumen-Folgenummer auf und weist das zweite Datenvolumen eine zweite Folgenummer auf, die sich von der ersten Datenvolumen-Folgenummer unterscheidet. Das Modifizieren von Header-Daten zum Speichern auf das zweite Datenvolumen während des physischen Restore des ersten Datenvolumens enthält ein Austauschen der ersten Folgenummer des ersten Datenvolumens in Header-Daten gegen die zweite Datenvolumen-Folgenummer des zweiten Datenvolumens, während Header-Daten und Benutzerdaten von dem ersten Datenvolumen gelesen werden und gelesene Daten auf das zweite Datenvolumen kopiert werden.
Bei der obigen Ausführungsform wird ein Neubenennen von Daten mit der Folgenummer des zweiten Datenvolumens verzögert, bis ein Laden des zweiten Datenvolumens zum Anfordern von Daten des ersten Datenvolumens durch den Host angefordert wird. Infolgedessen erleichtert das virtuelle Restore ein schnelles und kostengünstiges Restore des ersten Datenvolumens, bis Daten für ein angefordertes physisches Restore mit einer anderen Folgenummer neu benannt werden. Darüber hinaus kann eine Modifizierung der Folgenummer in Header-Daten auf das erste Datenvolumen in Verbindung mit einem Restore des ersten Datenvolumens während eines virtuellen und physischen Restore des ersten Datenvolumens vermieden werden. Stattdessen werden Folgenummer-Header-Daten auf das zweite Datenvolumen modifiziert, um Benutzerdaten neu zu benennen, die auf das zweite Datenvolumen übertragen worden sind, und werden während des physischen Restore auf dem ersten Datenvolumen nicht modifiziert.
Bei einer weiteren Ausführungsform wird das erste Datenvolumen vor dem Laden des ersten Datenvolumens als schreibgeschütztes Datenvolumen kategorisiert, um eine Modifizierung des ersten Datenvolumens durch das Restore des ersten Datenvolumens sowohl während des virtuellen Restore als auch während des physischen Restore des ersten Datenvolumens zu verhindern.
Bei der obigen Ausführungsform kann das zweite Datenvolumen als schreibgeschützt kategorisiert werden, um eine Einhaltung von rechtlichen und Richtlinienbeschränkungen für das zweite Datenvolumen sicherzustellen, da sowohl das virtuelle Restore als auch das physische Restore ohne jegliche Modifizierung der Daten des zweiten Datenvolumens ausgeführt werden können. Dementsprechend kann ein Restore ungeachtet jeglicher Beschränkungen für eine Modifizierung von Daten des ersten Datenvolumens erreicht werden.
Bei einer noch weiteren Ausführungsform wird vor einer Initiierung des virtuellen Restore des ersten Datenvolumens das erste Datenvolumen in eine Aufbewahrungskategorie kategorisiert, in dem Datenvolumen über einen Zeitraum hinweg aufbewahrt werden, nachdem sie zur Löschung vorgesehen sind. Das virtuelle Restore des ersten Datenvolumens enthält des Weiteren ein Neukategorisieren des ersten Datenvolumens in einer Rückstellungskategorie, in der eine Modifizierung von Datenvolumen verhindert wird. Als Reaktion auf einen Abschluss des Übertragens von Daten von dem ersten Datenvolumen auf das zweite Datenvolumen während des physischen Restore des ersten Datenvolumens wird das erste Datenvolumen von der Rückstellungskategorie zurück in die Aufbewahrungskategorie neu kategorisiert.
Bei der obigen Ausführungsform kann eine Modifizierung des ersten Datenvolumens durch das Restore des ersten Datenvolumens sowohl während des virtuellen Restore als auch des physischen Restore des ersten Datenvolumens vermieden werden. Dementsprechend kann das erste Datenvolumen neu in eine Rückstellungskategorie kategorisiert werden, um sicherzustellen, dass eine Modifizierung des ersten Datenvolumens verhindert wird. Auf diese Weise kann ein Restore ungeachtet jeglicher Beschränkungen für eine Modifizierung von Daten des ersten Datenvolumens erreicht werden.
Bei einer noch weiteren Ausführungsform wird das zweite Datenvolumen zumindest eine Richtlinie zugewiesen, wobei die Richtlinie Parameter für einen Zeitraum, wie lange ein Datenvolumen zu behalten ist, und/oder für eine zulässige Anzahl von Versionen des Datenvolumens definiert. Mit dieser Ausführungsform kann ein virtuelles Restore erleichtert werden.
Bei einer weiteren Ausführungsform wird ein drittes Datenvolumen in den Speicher importiert, wobei das Importieren ein Durchführen eines virtuellen Restore des dritten Datenvolumens mithilfe eines vierten Datenvolumens enthält, das eine Datenvolumen-Folgenummer aufweist, die einer Konvention zur Datenvolumen-Folgenummerierung des Speichers entspricht. Das virtuelle Restore des dritten Datenvolumens enthält ein Konfigurieren von Metadaten, die dem vierten Datenvolumen zugehörig sind, um das vierte Datenvolumen dem dritten Datenvolumen als virtuelles Restore des dritten Datenvolumens zuzuordnen.
Bei der obigen Ausführungsform wird ein Zugreifen auf Daten des dritten Datenvolumens während des Imports verzögert, bis ein Zugriff auf die Daten durch den Host angefordert wird. Infolgedessen wird ein schneller und kostengünstiger Import erleichtert. Des Weiteren kann eine Modifizierung von Daten auf das dritte Datenvolumen in Verbindung mit einem Import des dritten Datenvolumens vermieden werden. Dementsprechend kann ein Import ungeachtet jeglicher Beschränkungen für eine Modifizierung von Daten des dritten Datenvolumens erreicht werden.
Bei einer noch weiteren Ausführungsform wird das zweite Datenvolumen gelöscht und wird ein zweites virtuelles Restore des ersten Datenvolumens mithilfe eines dritten Datenvolumens durchgeführt. Das zweite virtuelle Restore enthält ein Konfigurieren von Metadaten, die dem dritten Datenvolumen zugehörig sind, um das dritte Datenvolumen dem ersten Datenvolumen als zweites virtuelles Restore des ersten Datenvolumens zuzuordnen.
Bei der obigen Ausführungsform bleibt das erste Datenvolumen im Verlauf des ersten und des zweiten virtuellen Restore des ersten Datenvolumens unveränderlich. Infolgedessen kann für das erste Datenvolumen wieder und wieder nach Bedarf rekursiv ein Restore durchgeführt werden, wobei er bei jedem Restore unveränderlich bleibt.
Bei einer weiteren Ausführungsform wird das erste Datenvolumen in einem Sekundärspeicher gespeichert, der mit einem Speicher-Server verbunden ist, der einen Primärspeicher aufweist. Das erste Datenvolumen bleibt während des gesamten virtuellen Restore des ersten Datenvolumens in dem Sekundärspeicher ungeladen.
Da bei der obigen Ausführungsform das Laden des ersten Datenvolumens, um auf Daten des ersten Datenvolumens zuzugreifen, verzögert wird, bis das Laden des zweiten Datenvolumens durch den Host angefordert wird, wird während des virtuellen Restore auf das erste Datenvolumen in dem Sekundärspeicher möglicherweise nicht zugegriffen, wodurch der Aufwand zum Übertragen von Daten von dem ersten Datenvolumen in den Sekundärspeicher in Verbindung mit dem virtuellen Restore vermieden wird.
Figurenliste

1 veranschaulicht eine Ausführungsform einer Speicherumgebung, die eine Verwaltung einer Wiederherstellung eines Datenspeicher-Datenvolumens gemäß der vorliegenden Beschreibung einsetzt.
1A veranschaulicht eine Ausführungsform eines Host wie zum Beispiel einer Speichersteuereinheit, die eine Verwaltung einer Wiederherstellung eines Datenspeicher-Datenvolumens gemäß der vorliegenden Beschreibung einsetzt.
2 veranschaulicht eine Ausführungsform eines Richtlinien-Pools, der Aufbewahrungsrichtlinien definiert.
3 veranschaulicht eine Ausführungsform eines Versionsobjekts mit eigentlichen Daten für eine Version eines Objekts.
4 veranschaulicht eine Ausführungsform von Versionsmetadaten mit Metadaten zu einem Versionsobjekt.
5A veranschaulicht eine Ausführungsform von Vorgängen eines virtuellen Restore- oder Wiederherstellungsprozesses, der eine Verwaltung einer Wiederherstellung eines Datenspeicher-Datenvolumens gemäß der vorliegenden Beschreibung einsetzt.
5B veranschaulicht eine Ausführungsform von Vorgängen eines physischen Restore- oder Wiederherstellungsprozesses, der eine Verwaltung einer Wiederherstellung eines Datenspeicher-Datenvolumens gemäß der vorliegenden Beschreibung einsetzt.
6A veranschaulicht eine ausführlichere Ausführungsform von Vorgängen des virtuellen Wiederherstellungsprozesses von 5A.
6B veranschaulicht eine ausführlichere Ausführungsform von Vorgängen des physischen Wiederherstellungsprozesses von 5B.
7A bis 7G stellen Ausführungsformen von Katalogeinträgen eines Bandarchivs eines VTS in verschiedenen Phasen des virtuellen und des physischen Wiederherstellungsprozesses von 6A bis 6B dar.
8A ist eine Ausführungsform eines Katalogeintrags eines VTS, der ein Zuordnen eines Zielarbeitsdatenvolumens zu einem Wiederherstellungsdatenvolumen für den virtuellen Wiederherstellungsprozess von 5A und 6 darstellt.
8B ist eine Ausführungsform eines Katalogeintrags eines Host, der ein Zuordnen eines Zielarbeitsdatenvolumens zu einem Wiederherstellungsdatenvolumen für den virtuellen Wiederherstellungsprozess von 5A und 6 darstellt.
9A stellt eine Ausführungsform von Daten dar, die von einem Wiederherstellungsdatenvolumen gelesen werden.
9B stellt eine Ausführungsform von Daten dar, die in einem privaten Zieldatenvolumen gespeichert sind.
10 veranschaulicht eine Datenverarbeitungsumgebung, in der Komponenten der Figuren implementiert werden können.

AUSFÜHRLICHE BESCHREIBUNG
Eine Verwaltung einer Wiederherstellung eines Datenspeicher-Datenvolumens gemäß der vorliegenden Beschreibung stellt eine erhebliche Verbesserung einer Computertechnologie bereit. In einem Aspekt der Verwaltung einer Wiederherstellung eines Datenspeichers gemäß der vorliegenden Beschreibung enthält eine Wiederherstellung eines Datenspeicher-Datenvolumens ein(e) virtuelle(s) Wiederherstellung oder Restore, die/das Metadaten, die den Datenvolumen zugehörig sind, so konfiguriert, dass sie ein Zielarbeitsdatenvolumen einem Wiederherstellungsdatenvolumen zuordnen. Auf diese Weise kann die virtuelle Wiederherstellung ohne Kopieren oder sonstiges Übertragen von Daten von einem Wiederherstellungsdatenvolumen zu dem Zielarbeitsdatenvolumen abgeschlossen werden. Das Konfigurieren der Metadaten kann in einigen Fällen in einem Bruchteil einer Sekunde durchgeführt werden, wohingegen ein Kopieren von Gigabytes von Daten in vielen Fällen eine Stunde oder länger dauern kann. Infolgedessen kann die virtuelle Wiederherstellung im Vergleich mit verschiedenen bekannten Wiederherstellungsverfahren erheblich schneller mit erheblich weniger Rechen- oder Personal-Ressourcen abgeschlossen werden. Darüber hinaus kann die virtuelle Wiederherstellung ohne Modifizieren des Wiederherstellungsdatenvolumens selbst in jeglicher Weise und damit völlig ohne Laden des Wiederherstellungsdatenvolumens abgeschlossen werden. Infolgedessen kann das Wiederherstellungsdatenvolumen unveränderlich bleiben, um verschiedene Aufbewahrungsrichtlinien oder gesetzliche Anforderungen, dass das Wiederherstellungsdatenvolumen unverändert bleibt, zu erfüllen. Noch weiter ermöglicht die virtuelle Wiederherstellung, dass die häufig mit einem Kopieren oder Versetzen von Daten verbundenen Kosten vermieden werden, solange die Daten nicht tatsächlich für andere Zwecke als eine Wiederherstellung benötigt werden.
Es versteht sich hierin, dass ein Zugriff auf die Daten eines Wiederherstellungsdatenvolumens häufig weder sofort noch gar langfristig benötigt wird. Infolgedessen kann eine virtuelle Wiederherstellung, wie sie hierin beschrieben wird, häufig sofortige oder gar langfristige Bedürfnisse in Verbindung mit einer Datenvolumenwiederherstellung erfüllen, bei der ein Bedarf an einem tatsächlichen Zugriff auf die Daten des Wiederherstellungsdatenvolumens nicht entsteht oder noch nicht entstanden ist. In solchen Fällen, in denen ein Bedarf an einem Zugriff auf die Daten eines Wiederherstellungsdatenvolumens zu einem Zeitpunkt ersichtlich wird, nachdem die virtuelle Wiederherstellung des Datenvolumens abgeschlossen worden ist, stellt die Datenwiederherstellungsverwaltung gemäß der vorliegenden Beschreibung jedoch auch einen zweiten Wiederherstellungsprozess bereit, das heißt, einen physischen Restore- oder Wiederherstellungsprozess, der einen einfachen Zugang auf die Daten eines Wiederherstellungsdatenvolumens bereitstellt, das den virtuellen Wiederherstellungsprozess bereits abgeschlossen hat.
Bei einer Ausführungsform enthält der physische Wiederherstellungsprozess ein Kopieren von Daten von dem Wiederherstellungsdatenvolumen auf das Zieldatenvolumen, das in dieser Phase als privates Datenvolumen statt als Arbeitsdatenvolumen bezeichnet werden kann. Auf diese Weise wird jegliches Laden des Wiederherstellungsdatenvolumens zum Kopieren von Daten von dem Wiederherstellungsdatenvolumen auf das private Zieldatenvolumen verzögert, bis tatsächlich ein Bedarf an den Daten entsteht, um faktisch eine Datenübertragung „nach Bedarf“ bereitzustellen, wodurch eine Datenübertragung während des virtuellen Wiederherstellungsprozesses unnötig wird. Wie oben angemerkt, erleichtert ein Beseitigen einer Datenübertragung für die virtuelle Wiederherstellung einen schnellen Abschluss des virtuellen Wiederherstellungsprozesses. Dementsprechend wird eine zeitaufwendige und Ressourcen-intensive Datenübertragung verzögert, bis tatsächlich ein Bedarf an den Daten entsteht, und die physische Wiederherstellung wird dann implementiert.
In einem weiteren Aspekt eines physischen Wiederherstellungsprozesses gemäß der vorliegenden Beschreibung werden, wenn die Daten in Verbindung mit dem physischen Wiederherstellungsprozess von dem Wiederherstellungsdatenvolumen auf das private Zieldatenvolumen kopiert werden, die kopierten Daten in dem privaten Zieldatenvolumen neu benannt, um anzugeben, dass die kopierten Daten nun zu der VOLSER des privaten Zieldatenvolumens statt zu der VOLSER des Wiederherstellungsdatenvolumens gehören, von dem sie gelesen wurden. Dieses Neubenennen der Daten wird folglich ebenso bis nach dem virtuellen Wiederherstellungsprozess verzögert und wird verzögert, bis die physische Wiederherstellung implementiert wird, wenn ein Bedarf an einem Zugreifen auf die Daten entstanden ist. Auf diese Weise handelt es sich bei einem Neubenennen der kopierten Daten faktisch um ein Neubenennen von Daten des physischen Wiederherstellungsprozesses „nach Bedarf“, wodurch jeglicher Bedarf an einem Neubenennen von Daten während des virtuellen Wiederherstellungsprozesses unnötig wird. Auch hier kann die physische Wiederherstellung abgeschlossen werden, ohne das Wiederherstellungsdatenvolumen in jeglicher Weise zu modifizieren. Infolgedessen kann das Wiederherstellungsdatenvolumen unveränderlich bleiben, um verschiedene Aufbewahrungsrichtlinien oder gesetzliche Anforderungen, dass das Wiederherstellungsdatenvolumen unverändert bleibt, zu erfüllen.
In einem weiteren Aspekt einer Verwaltung einer Wiederherstellung eines Datenspeicher-Datenvolumens gemäß der vorliegenden Beschreibung kann der virtuelle Wiederherstellungsprozess verwendet werden, um Datenvolumen von einer weiteren Quelle, die ein(e) andere(s) oder konfligierende(s) Schema oder Konvention zur Datenvolumen-Folgenummerierung aufweist, schnell und effizient zu importieren. Bei einer Ausführungsform können die zu importierenden Datenvolumen neuen VOLSERs zugeordnet oder neu zugeordnet werden, die zum Beispiel der bestehenden Konvention des Ziel-Datenspeichersystems für Datenvolumen-Folgenummern entsprechen. Auf diese Weise können die zu importierenden Datenvolumen neuen VOLSERs zugeordnet oder neu zugeordnet werden, die nicht mit bestehenden aktiven VOLSERs übereinstimmen oder die in anderer Weise mit bestehenden VOLSERs des Host oder VTS zum Beispiel eines Ziel-Datenspeichersystems in Konflikt stehen. Darüber hinaus können die Datenvolumen, die importiert werden, VOLSERs zugeordnet oder neu zugeordnet werden, die bestehenden Konventionen für einen Datenvolumen-Folgenummernbereich entsprechen und sie dadurch aufrechterhalten.
Es versteht sich, dass die in einen Ziel-VTS zu importierenden Datenvolumen abhängig von der jeweiligen Anwendung zum Beispiel Hunderte, Tausende, Millionen oder mehr betragen können. Der virtuelle Wiederherstellungsprozess der veranschaulichten Ausführungsform ermöglicht, dass große Anzahlen von Datenvolumen schnell in einen Ziel-VTS importiert werden, ohne jegliche der Datenvolumen, die mit dem virtuellen Wiederherstellungsprozess importiert werden, zu laden oder auf andere Weise auf diese zuzugreifen. Infolgedessen können die Datenvolumen, die importiert werden, gehärtet werden, um die Gültigkeit ihres Inhalts aufrechtzuerhalten, da jedes importierte Datenvolumen unveränderlich bleiben kann und nur bei Bedarf als Teil einer zukünftigen Ladeanforderung einer künftigen physischen Wiederherstellung neu benannt wird. Aus juristischen Gründen kann zum Beispiel der Status der Daten zum Importzeitpunkt erfordern, dass sie unveränderlich bleiben, um einen konsistenten Punkt einer Arbeitsprozesserfassung aufrechtzuerhalten. Der virtuelle Wiederherstellungsprozess der veranschaulichten Ausführungsform ermöglicht einen Import von Datenvolumen ohne einen Konflikt von Datenvolumen-Folgenummern (VOLSER), ohne auf jede Instanz zugreifen zu müssen und ohne die Quellinstanz modifizieren zu müssen. Falls ein Bedarf entsteht, auf Daten eines importierten Datenvolumens zurückzugreifen, kann eine physische Wiederherstellung des importierten Datenvolumens nach Bedarf durchgeführt werden, wie oben beschrieben.
1 veranschaulicht eine Ausführungsform einer Datenspeicherumgebung, die ein oder mehrere Host-Systeme und/oder Speichersteuereinheiten 100 aufweist, die Daten für ein Objekt oder ein Datenvolumen in Form eines Freigabedatenvolumens oder einer Anhängung an ein Objekt über ein erstes Netzwerk 102 für einen Speicher-Server 104 bereitstellen. Ein „Objekt“, wie der Begriff hierin verwendet wird, kann ein Datenvolumen, einen Datensatz, eine Datenbank, ein logisches Laufwerk, ein Dateisystem oder eine beliebige sonstige Gruppierung von Daten aufweisen. Der Speicher-Server 104 kann Objekte wie zum Beispiel Sicherungsdatenvolumen oder Banddatenvolumen zum Sichern über ein zweites Netzwerk 108 (das sich in Bezug auf den Speicher-Server 104 vor Ort befinden oder entfernt angeordnet sein kann) in einem oder mehreren Cloud-Speichern 106, in einem Bandarchiv 110 zum Speichern auf physischen Bandkassetten und/oder in einem Primärspeicher 112 des Speicher-Servers 104 erzeugen. Des Weiteren können die Versionssicherungsobjekte dauerhaft oder vorübergehend in dem Primärspeicher 112 gespeichert werden sowie zu einem Cloud- oder Bandspeicher übertragen werden. Der Speicher-Server 104 kann Versionsobjekte 300 von Sicherungsobjekten für verschiedene Versionen erzeugen, die eine eindeutige Folgenummer wie zum Beispiel eine VOLSER aufweisen, und enthält Standardbandmarken und Datenblöcke.
Der Speicher-Server 104 enthält einen Prozessor 114 und einen Speicher 116, der Programme enthält, die durch den Prozessor 114 ausgeführt werden, um Versionsobjekte 300 eines Objekts in einem Format wie zum Beispiel einem Bandformat zum Speichern in einem Bandarchiv 110, einem Cloud-Speicher 106 und/oder einem Primärspeicher 112 zu erstellen. Der Speicher 116 enthält ein Betriebssystem 118 zum Verwalten von Vorgängen des Speicher-Servers 104 und einen Versions-Manager 120 zum Erstellen und Verwalten von Objektversionen 300 wie zum Beispiel Banddatenvolumen zum Speichern in dem Bandarchiv 110, dem entfernt angeordneten Speicher 106 und/oder dem Primärspeicher 112. Ein Wiederherstellungs-Manager 123 verwaltet eine Wiederherstellung eines Datenvolumens in einem virtuellen Wiederherstellungsprozess und in einem physischen Wiederherstellungsprozess nach Bedarf, wie im Folgenden ausführlicher beschrieben wird.
Unter Bezugnahme auf 1A enthält ein Host 100 einen Prozessor 114h ( 1A) und einen Speicher 116h, der Programme enthält, die durch den Prozessor 114h ausgeführt werden, um Daten für ein Objekt oder ein Datenvolumen für den Speicher-Server 104 bereitzustellen. Der Speicher 116h enthält ein Betriebssystem 118h zum Verwalten von Vorgängen des Host 100 und einen Versions-Manager 120h, um Daten für ein Objekt oder ein Datenvolumen für den Speicher-Server 104 bereitzustellen. Darüber hinaus gibt der Versions-Manager 120h Befehle an den Speicher-Server 104 für die Verwaltung von Objektversionen 300 wie zum Beispiel Banddatenvolumen aus, die in dem Bandarchiv 110, dem entfernt angeordneten Speicher 106 und/oder dem Primärspeicher 112 gespeichert sind. Der Versions-Manager 120h verwaltet Metadaten, die verschiedene Eigenschaften der Objekte kennzeichnen, die in dem oder durch den Speicher-Server 104 in Form eines Katalogs 121h gespeichert sind. Ein Wiederherstellungs-Manager 123h gibt Befehle an den Speicher-Server 104 für die Wiederherstellung von Objektversionen 300 wie zum Beispiel Banddatenvolumen aus, die in dem Bandarchiv 110, dem entfernt angeordneten Speicher 106 und/oder dem Primärspeicher 112 gespeichert sind.
Unter erneuter Bezugnahme auf 1 kann der Speicher-Server 104 (1) eine Folgenummer aus einem Arbeits-Pool 122 wie zum Beispiel eine Datenvolumen-Folgenummer (VOLSER) zum Verwenden für eine Objektversion 300 zum Erstellen und Speichern in dem Bandarchiv 110, dem entfernt angeordneten Speicher 106 und/oder dem Primärspeicher 112 beziehen. Alle Versionen eines Objekts/Datenvolumens würden dieselbe Folgenummer oder VOLSER verwenden. Eine Banddatenvolumen-Folgenummer oder VOLSER wird verwendet, um ein Banddatenvolumen eindeutig zu kennzeichnen. Bei einem Bandspeicher wird die VOLSER in dem Bandkennsatz angegeben, bei dem es sich um den ersten auf dem Band enthaltenen Satz von Informationen handelt. Zusätzlich zu dem Bandkennsatz kennzeichnen auch sonstige intern in dem Banddatenvolumen gespeicherte Metadaten die VOLSER des Datenvolumens.
Der Versions-Manager 120 kann des Weiteren Versionsmetadaten 400 erzeugen, die Metadaten über die Versionsobjekte 300 aufweisen, die dazu verwendet werden können, an den Daten für ein Versionsobjekt 300 aus Versionsobjekten 300 einer höheren Versionsnummer ein Restore durchzuführen. Darüber hinaus verarbeitet der Versions-Manager 120 Befehle von dem Host 100 für die Verwaltung von Objektversionen 300 wie zum Beispiel Banddatenvolumen, die in dem Bandarchiv 110, dem entfernt angeordneten Speicher 106 und/oder dem Primärspeicher 112 gespeichert sind. Der Versions-Manager 120 des Speicher-Servers 104 verwaltet darüber hinaus Metadaten, die verschiedene Eigenschaften der Objekte kennzeichnen, die in dem oder durch den Speicher-Server 104 in Form eines Katalogs 121b gespeichert sind.
Die Folgenummer oder VOLSER, die aus dem Arbeits-Pool 122 bezogen wird, kann einem Richtlinien-Pool 200 zugewiesen werden, wobei unterschiedliche Richtlinien-Pools 200 unterschiedliche Datenaufbewahrungsrichtlinien vorhalten. Beim Erstellen einer Instanz einer Objektversion 300_i zum Schreiben in den Speicher wie zum Beispiel 106, 112 oder 110 kann der Versions-Manager 120 eine Angabe der Objektversion 300_i zu einer Exportwarteschlange 124 zum Exportieren der Objektversion 300_i an den Speicher 112, 110, 106 hinzufügen.
Bei einer Ausführungsform kann der Speicher-Server 104 einen virtuellen Band-Server zum Verwalten der Erstellung von Versionen von Objekten zum Auslagern in den Speicher 110, 112 wie zum Beispiel den virtuellen Band-Server TS7700 von International Business Machines Corporations (IBM) aufweisen. Ein virtueller Server emuliert ein Bandarchiv mit Bandlaufwerken gegenüber den verbundenen Hosts/Speichersteuereinheiten 100. Der Speicher-Server 104 kann eine Archivierung von Objekten zur Speicherung in einem preisgünstigeren physischen Bandarchiv 110, Cloud-Speicher 106 und/oder Primärspeicher 112 bereitstellen.
Die Programmkomponenten in dem Speicher 116 einschließlich 118, 120, 123 werden in 1 als Programmcode dargestellt, der in den Speicher 116 geladen und durch den Prozessor 114 ausgeführt wird. In ähnlicher Weise werden die Programmkomponenten in dem Speicher 116h einschließlich 118h, 120h, 123h in 1A als Programmcode dargestellt, der in den Speicher 116h geladen und durch den Prozessor 114h ausgeführt wird. Alternativ können einige oder sämtliche der Funktionen der Komponenten in Hardware-Einheiten wie zum Beispiel in anwendungsspezifischen integrierten Schaltungen (Application Specific Integrated Circuits, ASICs), einem feldprogrammierbaren Gate-Array (FPGA) implementiert oder durch getrennte dedizierte Prozessoren ausgeführt werden.
Der Speicher 116, 116h kann eine oder mehrere flüchtige oder nichtflüchtige Speichereinheiten wie zum Beispiel einen dynamischen Direktzugriffsspeicher (Dynamic Random Access Memory, DRAM), einen Phasenwechselspeicher (phase change memory, PCM), einen magnetoresistiven Direktzugriffsspeicher (Magnetoresistive random-access memory, MRAM), einen Spin-Übertragungsmoment(Spin Transfer Torque, STT)-MRAM, SRAM-Speichereinheiten, einen DRAM, einen ferroelektrischen Direktzugriffsspeicher (ferroelectric random-access memory, FeTRAM), einen nichtflüchtigen Speicher auf Grundlage von Nanodrähten und nichtflüchtige Direct-In-Line-Speichermodule (Direct In-Line Memory Modules, DIMMs), einen NAND-Speicher, z.B. einen Flash-Speicher, einen Halbleiterlaufwerk(Solid State Drive, SSD)-Speicher, einen nichtflüchtigen RAM usw. aufweisen.
Der Versions-Manager 120 kann Objektversionen 300 über ein Netzwerk zu dem Bandarchiv 110, dem entfernt angeordneten Speicher 106 und/oder dem Primärspeicher 112 exportieren. 1 stellt zum Beispiel den Speicher-Server 104 über ein zweites Netzwerk 108 mit dem entfernt angeordneten Cloud-Speicher 106 verbunden dar. Bei einer alternativen Ausführungsform kann der Cloud-Speicher 106 lokal wie zum Beispiel am selben Ort wie der Speicher-Server 104 angeordnet sein. Der Cloud-Speicher 106 kann ein Cloud-Speichersystem aufweisen, das durch einen Cloud-Speicherdienstanbieter bereitgestellt wird. Zu Beispielen für Anbieter von Diensten von Cloud-Speichern 106 zählen DropBox^®, Google^® Drive, Amazon Cloud Drive^®, Amazon^® S3, IBM^® Cloud Object Storage System™ usw. (Dropbox ist eine eingetragene Marke von Dropbox, Inc., Google ist eine eingetragene Marke von Google, Inc., Amazon und Amazon Cloud Drive sind Marken von Amazon Technologies, Inc.; und IBM und Cloud Object Storage System sind Marken von IBM weltweit).
Der Versions-Manager 120 kann den Primärspeicher 112 als virtuellen Band-Cache verwenden, um Objektversionen 300 zu speichern, die erstellt werden und bevor sie zum Migrieren in den Speicher 106, 110, 112 zu der Exportwarteschlange 124 hinzugefügt werden. Bei weiteren Ausführungsformen kann der Primärspeicher 112 dazu verwendet werden, die Objektversionen 300 zu speichern, wenn kein verfügbarer Speicher 106, 110, 112 vorhanden ist.
Der Primärspeicher 112 kann verschiedene Typen oder Klassen von Speichereinheiten aufweisen, zum Beispiel Magnet-Festplattenlaufwerke, eine Halbleiterspeichereinheit (SSD), die aus Halbleiterelektronik besteht, einen EEPROM (Electrically Erasable Programmable Read-Only Memory, elektrisch löschbaren, programmierbaren Festwertspeicher), einen Flash-Speicher, ein Flash-Laufwerk, ein Direktzugriffsspeicher(RAM)-Laufwerk, einen Speicherklassenspeicher (storage-class memory, SCM) usw., einen Phasenwechselspeicher (PCM), einen resistiven Direktzugriffsspeicher (resistive random access memory, RRAM), einen Spin-Übertragungsmomentspeicher (STM-RAM), einen RAM mit leitfähiger Überbrückung (conductive bridging RAM, CBRAM), ein Magnet-Festplattenlaufwerk, eine optische Platte, ein Band usw. Datenvolumen in dem Primärspeicher 112 können des Weiteren aus einem Array von Einheiten konfiguriert sein, zum Beispiel als Bündel unabhängiger Platten (Just a Bunch of Disks, JBOD), Direktzugriffsspeichereinheit (Direct Access Storage Device, DASD), redundantes Array von unabhängigen Platten (Redundant Array of Independent Disks, RAID), Virtualisierungseinheit usw. Des Weiteren kann der Speicher 112 heterogene Speichereinheiten von verschiedenen Anbietern und verschiedene Typen von Speichereinheiten aufweisen, zum Beispiel einen ersten Typ von Speichereinheiten, z.B. Festplatten-Laufwerke, die eine geringere Datenübertragungsgeschwindigkeit als ein zweiter Typ von Speichereinheiten, z.B. SSDs, aufweisen. Der Cloud-Speicher 106 und das Bandarchiv 110 können im Vergleich mit dem Primärspeicher 112 als Sekundärspeicher betrachtet werden.
Das erste Netzwerk 102, das durch eine(n) Host/Speichersteuereinheit 100 verwendet wird, um Datenvolumendaten mit dem Speicher-Server 104 auszutauschen, kann ein Speichernetzwerk wie zum Beispiel ein oder mehrere miteinander verbundene lokale Netzwerke (Local Area Networks, LAN), Speicherbereichs-Netzwerke (Storage Area Networks, SAN), ein Weitverkehrs-Netzwerk (Wide Area Network, WAN), ein Peer-to-Peer-Netzwerk, ein drahtloses Netzwerk usw. aufweisen. Das zweite Netzwerk 108 kann ein Netzwerk aufweisen, das für einen entfernt angeordneten Speicher wie zum Beispiel einen Cloud-Speicher 106 zugänglich ist, wie etwa das Internet, ein Weitverkehrs-Netzwerk (WAN). Bei alternativen Ausführungsformen kann es sich bei dem ersten 102 und dem zweiten 108 Netzwerk um dasselbe Netzwerk handeln, und bei einem oder mehreren des Primärspeichers 112 und des Bandarchivs 110 kann es sich außerdem um einen entfernt angeordneten Speicher handeln, der über ein Netzwerk zugänglich ist.
2 veranschaulicht eine Ausführungsform einer Instanz 200i eines Richtlinien-Pools 200, dem eine Objektfolgenummer, z.B. eine VOLSER, für ein Objekt oder ein Datenvolumen zum Schreiben zugewiesen wird, und die eine Pool-Kennung 202, die den Pool kennzeichnet, die zugewiesenen Objektfolgenummern (VOLSERs) 204, die dem Pool zugewiesen sind, die Objektversionen 206, die in dem Pool für die Objektfolgenummern 204 enthalten sind, und eine oder mehrere Aufbewahrungsrichtlinien 208 enthält, um festzulegen, wie lange Objektversionen in einem Richtlinien-Pool 200 aufzubewahren sind.
Zu Beispielen für Aufbewahrungsrichtlinien zählen:

- eine Höchstanzahl von aufzubewahrenden vorherigen Versionen einschließlich Versionsmetadaten 400_i und Daten über ein Versionsobjekt 300_i für eine Version.
- eine Höchstanzahl von Tagen zum Aufbewahren von Informationen über eine vorherige Version einschließlich Versionsmetadaten 400_i und Daten über ein Versionsobjekt 300_i für ein Objekt.
- eine Höchstanzahl von vorherigen Versionen, für die Daten über ein Versionsobjekt 300_i aufbewahrt werden.
- ein Aufbewahren jeder k-ten Version eines Objekts, so dass Daten für ein Versionsobjekt 300_i aufbewahrt werden, wenn eine Versionsnummer des Versionsobjekts 300_i ein Mehrfaches von k plus 1 ist, z.B. die Versionsnummer des Objekts = 1+x*k ist, wobei x eine Ganzzahl größer als null ist.

3 veranschaulicht eine Instanz 300_i eines Versionsobjekts, das aus Objekt- oder Datenvolumendaten erstellt wird, die von den Hosts/ Speichersteuereinheiten 100 gesendet werden, und die enthält: eine Objektfolgenummer, z.B. eine VOLSER, die dem Objekt/Datenvolumen zugewiesen ist, für das/den Versionen erstellt werden; einen erstellten Zeitstempel 304, wann die Objektversion erstellt wurde; eine Versionsnummer 306 des Objekts; eine oder mehrere Instanzen von Objektversionsdaten 308₁...308_n für jede Version von Objektdaten für Versionen V₁ bis V_n von dem Host/der Speichersteuereinheit 100, die in dem Versionsobjekt 300_i enthalten sind, einschließlich kürzlich angehängter Daten; und Host-Abschlussmetadaten 312, die durch den Host/die Speichersteuereinheit 100, der/die die Objektversion erstellt hat, die an den Speicher-Server 104 gesendet worden ist, an das Ende einer Objektversion angefügt werden. Die Host-Abschlussmetadaten 312 können Informationen über die Struktur und das Format des Objekts und über den Host/die Speichersteuereinheit 100 enthalten, der/die die Daten in dem Objekt erzeugt hat.
4 veranschaulicht eine Instanz 400_i von Versionsmetadaten 400, die Metadaten über ein Versionsobjekt 300_i aufweisen, die getrennt von dem Versionsobjekt 300_i gehalten und aufbewahrt werden können, wenn das Versionsobjekt 300_i für eine vorherige Version gelöscht wird, um Platz zu sparen. Die Instanz der Versionsmetadaten 400_i kann eine zugewiesene Objektfolgenummer, z.B. eine VOLSER, 402; einen Richtlinien-Pool 404, in dem das Objekt und die Folgenummer 402 einander zugewiesen sind; eine Versionsnummer 406 des Versionsobjekts; einen erstellten Zeitstempel 408, wann das Versionsobjekt 300_i erstellt wurde; einen Versionsort 410, der ein oder mehrere Versionsobjekte 300_j einer höheren Version angibt, die die Daten für die Versionsnummer 406 enthalten; eine Objektgröße 412 des Objekts 300_i, die durch die Versionsmetadaten 400_i dargestellt wird; einen End-Offset 414, der angibt, wo das Versionsobjekt endet, wenn die Daten für das Versionsobjekt in einem nachfolgenden Versionsobjekt 300_j enthalten sind, bei dem die angehängten Daten für die Versionsnummer 406 enden; und Host-Abschlussmetadaten 416, die Informationen aufweisen, die durch den Host/die Speichersteuereinheit 100, der/die die Objektdaten bereitstellt, hinzugefügt worden sind und die sich an einem Ende des Versionsobjekts 300_i befinden. Die Host-Abschlussmetadaten 312 werden in den Versionsmetadaten 400_i als 416 gespeichert, da die Host-Abschlussmetadaten 312 für die Versionsnummer 406 überschrieben werden können, wenn neue Daten und Änderungen angehängt werden. Dies ermöglicht, dass an dem Versionsobjekt 300_i ein Restore mit seinen ursprünglichen Host-Abschlussmetadaten 312 durchgeführt wird.
Die Versionsmetadaten 400_i erhalten jegliche sonstigen Informationen aufrecht, die benötigt werden, um den Beginn und das Ende einer Version von Daten zu erkennen.
Der Versions-Manager 120 verwaltet die Versionsmetadaten 400, bis eine Aufbewahrungsrichtlinie ein Ende eines Versionsaufbewahrungs-Zeitraums bis zum Ablaufen und Löschen der Versionsmetadaten 400 sowie der Versionsobjekte 300 mit den eigentlichen Daten für die Objekte festlegt. Die Versionsmetadaten 400 können dazu verwendet werden, für ein Restore jegliche der in den Versionsmetadaten 400 gekennzeichneten Versionen aus einem Objekt 300 einer aktuellen Version oder einer höheren Version zu erkennen und darauf zuzugreifen. Wenn eine bestimmte Version eines Datenvolumens durch einen Benutzer zum Löschen markiert worden ist, kann auf diese Weise trotzdem für ein Restore zu einem privaten Datenvolumen durch einen physischen Wiederherstellungsprozess, wie hierin beschriebenen, auf die Daten dieser Datenvolumenversion zugegriffen werden, solange der Aufbewahrungszeitraum, der durch die dieser Version des gelöschten Datenvolumens zugewiesenen Aufbewahrungsrichtlinie definiert ist, nicht abgelaufen ist. Wenn die Versionsmetadaten 400, die diese Datenvolumenversion und das Versionsobjekt 300 mit den eigentlichen Daten für das Objekt kennzeichnen, noch vorhanden sind, kann dementsprechend auf die Daten des gelöschten Datenvolumens für ein Restore zu einem neuen Datenvolumen durch den physischen Wiederherstellungsprozess zugegriffen werden. Nachdem die Versionsmetadaten 400, die diese Datenvolumenversion und das Versionsobjekt 300 mit den eigentlichen Daten für das Objekt kennzeichnen, gemäß der geltenden Aufbewahrungsrichtlinie verworfen worden sind, kann das gelöschte Datenvolumen jedoch nicht wiederhergestellt werden.
Wenngleich hierin eine Datenvolumen-Wiederherstellungsverwaltung in Verbindung mit Datenvolumen beschrieben wird, die als Objekte 300 mit zugehörigen Metadaten 400 gespeichert sind, die eine verbesserte Effizienz bei der Belegung von Speicherplatz bereitstellen, versteht es sich, dass eine Datenvolumen-Wiederherstellungsverwaltung gemäß der vorliegenden Beschreibung in Datenspeichersystemen genutzt werden kann, die sonstige Daten- und Metadaten-Speichertechniken nutzen. Beispielsweise kann eine Datenvolumen-Wiederherstellungsverwaltung gemäß der vorliegenden Beschreibung in Datenspeichersystemen genutzt werden, in denen jede Version eines Datenvolumens als Ganzes als getrennte Einheit gespeichert und aufbewahrt wird, bis sie durch den Ablauf eines Richtlinienaufbewahrungs-Zeitraums verworfen wird.
Wie oben dargelegt, stellt eine Datenvolumen-Wiederherstellungsverwaltung gemäß der vorliegenden Beschreibung einen virtuellen Wiederherstellungsprozess bereit, der ein Restore eines Datenvolumens bereitstellt, ohne dass ein Laden oder jegliche Modifizierung des Wiederherstellungsdatenvolumens erforderlich ist. Darüber hinaus stellt ein physischer Wiederherstellungsprozess ein Neubezeichnen von Daten, die auf das private Zieldatenvolumen kopiert werden, nach Bedarf bereit, bis tatsächlich auf die Daten des Wiederherstellungsdatenvolumens zugegriffen wird.
5A stellt eine Ausführungsform eines virtuellen Wiederherstellungsprozesses für ein Wiederherstellungsdatenvolumen VoIR dar, das in diesem Beispiel auf einem Zielarbeitsdatenvolumen VolP virtuell wiederhergestellt wird. Der virtuelle Wiederherstellungsprozess von 5A wird hierin auch als virtueller Restore-Prozess bezeichnet. 6A stellt eine ausführlichere Ausführungsform des in 5A dargestellten virtuellen Wiederherstellungsprozesses dar. Wie in Verbindung mit 5A und 6A ausführlicher erläutert, enthält der virtuelle Wiederherstellungsprozess von 5A einen Zuordnungsprozess 504 (5A), der das Zielarbeitsdatenvolumen VolP dem Wiederherstellungsdatenvolumen VoIR zuordnet. In einem Aspekt der Datenvolumenwiederherstellung gemäß der vorliegenden Beschreibung kann bei Abschluss der in 5A dargestellten virtuellen Wiederherstellung die Wiederherstellung des Datenvolumens VoIR als abgeschlossen betrachtet werden, solange der Host 100 nicht auf die Daten des Wiederherstellungsdatenvolumens VoIR zugreifen muss.
Im Vergleich stellt 5B ein Beispiel für einen physischen Wiederherstellungsprozess gemäß der vorliegenden Beschreibung in dem Fall dar, dass der Host 100 zu anderen Zwecken als zur Wiederherstellung tatsächlich auf die Daten des Wiederherstellungsdatenvolumens VoIR zugreifen muss. Der physische Wiederherstellungsprozess von 5B wird hierin auch als physischer Restore-Prozess bezeichnet. Wie im Folgenden ausführlicher erläutert wird, wird als Reaktion auf eine Anforderung von auf dem Wiederherstellungsdatenvolumen VoIR gespeicherten Benutzerdaten durch einen Host 100 das physische Restore (5B) des Wiederherstellungsdatenvolumens VoIR mithilfe des Zielarbeitsdatenvolumens VolP durchgeführt, das durch den virtuellen Wiederherstellungsprozess von 5A dem Wiederherstellungsdatenvolumen VoIR zugeordnet worden ist. Das physische Restore enthält ein Kopieren von Daten von dem Wiederherstellungsdatenvolumen VoIR, dem das Zielarbeitsdatenvolumen VolP durch das virtuelle Restore von 5A zugeordnet worden ist, auf das private Zieldatenvolumen VolP nach Bedarf (wie durch einen Pfeil 514 dargestellt) und enthält darüber hinaus ein Modifizieren von Daten-Headern nach Bedarf (wie durch einen Pfeil 518 dargestellt), um kopierte Daten als VolP-Daten statt als VoIR-Daten neu zu benennen. Auf diese Weise wird ein Zugreifen und Kopieren von Daten von dem Wiederherstellungsdatenvolumen VoIR nach Bedarf verzögert, das heißt, bis ein Zugriff auf die Daten durch den Host angefordert wird. Des Weiteren handelt es sich bei dem Neubenennen von Daten ebenfalls um einen Prozess nach Bedarf, in dem eine Header-Modifizierung ebenfalls verzögert wird, bis ein Zugriff auf die Daten durch den Host angefordert wird. Zusätzlich zu dem Bandkennsatz kennzeichnen sonstige intern in dem Banddatenvolumen gespeicherte Metadaten die VOLSER des Datenvolumens. Um Daten von einem Banddatenvolumen aufgrund einer VOLSER-Änderung neu zu benennen, werden daher sämtliche Dateinamen und Metadaten intern innerhalb von Dateien, die auf die VOLSER verweisen, als Teil des Neubenennungsprozesses ebenfalls aktualisiert. Infolgedessen werden jegliche bekannte Metadaten, die von dem Wiederherstellungsdatenvolumen VoIR zur Speicherung in dem privaten Zieldatenvolumen VolP in dem Datenvolumen gelesen werden, das direkt auf die Quelldatenvolumen-Folgenummer (VOLSER) verweist, zur Speicherung in dem Zieldatenvolumen als Teil des physischen Restore aktualisiert.
Bei einer Ausführungsform wird der Zuordnungsprozess 504 des virtuellen Wiederherstellungsprozesses von 5A durch Konfigurieren von Metadaten erreicht, die durch den Host verwaltet werden und dem privaten Zieldatenvolumen VolP zugehörig sind, so dass ein Host 100 das private Zieldatenvolumen VolP so behandelt, als wäre es das Wiederherstellungsdatenvolumen VoIR. Darüber hinaus konfiguriert der VTS des Speichersystems Metadaten, die durch den VTS verwaltet werden und dem Zielarbeitsdatenvolumen VolP zugehörig sind, so, dass sie auf das Wiederherstellungsdatenvolumen VoIR verweisen, falls der Host 100 künftig tatsächlich auf Daten innerhalb des Wiederherstellungsdatenvolumens VoIR zugreifen muss, nachdem der virtuelle Wiederherstellungsprozess von 5A abgeschlossen ist.
Gemäß einem Aspekt der Datenvolumenwiederherstellung gemäß der vorliegenden Beschreibung versteht es sich, dass es, solange der Host 100 nicht auf Daten innerhalb des Wiederherstellungsdatenvolumens VoIR zugreifen muss, der in 5A dargestellte virtuelle Wiederherstellungsprozess unnötig macht, tatsächlich Daten von dem Wiederherstellungsdatenvolumen VoIR auf das Arbeitsdatenvolumen VolP zu übertragen, bis der Host 100 zu Anwendungszwecken statt nur zu Wiederherstellungszwecken tatsächlich auf die Daten des Wiederherstellungsdatenvolumens R zugreifen muss. Daher werden das Zielarbeitsdatenvolumen VolP und das Wiederherstellungsdatenvolumen VoIR in 5A als ungeladen dargestellt, da für den virtuellen Wiederherstellungsprozess von 5A keine Übertragung der eigentlichen Daten benötigt wird. Da der virtuelle Wiederherstellungsprozess von 5A auf ein Konfigurieren von Metadaten, die dem Zielarbeitsdatenvolumen VolP zugehörig sind, statt auf ein Kopieren von Daten von dem Wiederherstellungsdatenvolumen VoIR auf das Zielarbeitsdatenvolumen VolP abzielt, kann der virtuelle Wiederherstellungsprozess von 5A im Vergleich mit einer Übertragung der eigentlichen Daten von dem Datenvolumen VoIR auf das Datenvolumen VolP schnell abgeschlossen werden.
Im Vergleich sind zuvor bekannte Wiederherstellungsverfahren vorhanden, die erfordern, dass das wiederherzustellende Datenvolumen physisch kopiert oder in ein Arbeitsdatenvolumen versetzt wird, bevor es als ,wiederhergestellt' betrachtet wird. Die Daten versetzen (oder kopieren) zu müssen, hat mehrere Nachteile: Die Daten zu versetzen (oder zu kopieren), kann zeitaufwendig sein, da Banddatenvolumen recht groß sein können (typischerweise mit einer Größe von 4 GB oder mehr). Wenn es sich bei diesen Daten um Archivierungsdaten handelt, auf die außer in extremen Situationen möglicherweise nie zugegriffen wird, wird darüber hinaus Zeit in Anspruch genommen, um die Daten zu kopieren und sie in der neuen VOLSER zu speichern. Außerdem überwacht ein Benutzer typischerweise den Prozess, um sicherzustellen, dass er abgeschlossen wird, so dass, wenn die Verarbeitung eines einzelnen, großen Datenvolumens eine Stunde dauert, jemand dies bis zum Abschluss überwacht. Daten zu versetzen (kopieren), erfordert darüber hinaus System-Ressourcen wie zum Beispiel Speicher- und CPU-Auslastung sowie Plattennutzung. Es erfordert darüber hinaus die Nutzung einer Bandeinheit, wenn es durch einen VTS oder durch ein physisches Bandarchiv implementiert wird. Diese Bandeinheiten wären mit dieser Arbeit statt mit wichtigerer, produktiver Arbeit beschäftigt. Wenn sich die Daten nur auf einem System befinden, das beim Lesen zusätzliche Kosten verursacht (z.B. ein Cloud-Speichersystem), kann es kostspielig sein, diese Daten lesen zu müssen.
Noch weiter kann die Archivinstanz unter bestimmten Umständen als rechtlich geschützt und so betrachtet werden, dass eine Modifizierung oder ein Austausch rechtlich nicht zulässig ist und sie als „schreibgeschützt“ behandelt wird. Zu sonstigen Beispielen für Umstände, die bisher bekannte Wiederherstellungsverfahren verhindern können, zählen Datenvolumen mit einer strengen Aufbewahrungs- oder Medienrichtlinie wie zum Beispiel WORM (Write Once, Read Many).
Im Vergleich stellt eine virtuelle Wiederherstellung gemäß der vorliegenden Beschreibung Benutzern eine Möglichkeit bereit, an einer älteren Version eines Datenvolumens ein Restore zu einem Arbeitsdatenvolumen ohne jegliche physische Datenversetzung durchzuführen. Statt die eigentlichen Daten zu versetzen, müssen nur die Metadaten geändert werden, die das neue Arbeitsdatenvolumen der alten Version eines Datenvolumens zuordnen. Die Metadaten für das Datenvolumen zu modifizieren, dauert typischerweise nur Sekundenbruchteile und erfordert möglicherweise nur eine vernachlässigbare Menge an Ressourcen im Vergleich zu denen, die typischerweise zum Kopieren der eigentlichen Daten großer Datenvolumen verwendet werden. Darüber hinaus können durch eine virtuelle Wiederherstellung gemäß der vorliegenden Beschreibung zusätzliche Kosten vermieden werden, wenn das Wiederherstellungsdatenvolumen in einem System wie zum Beispiel einem Cloud-System gespeichert wird, das Gebühren für den Lesevorgang erhebt. Da eine physische Wiederherstellung, bei der Daten physisch kopiert und Datenvolumen-Header-Daten modifiziert werden, verzögert werden kann, bis der Host die Daten tatsächlich benötigt, und somit verzögert werden kann, bis der Host das Datenvolumen lädt, können Cloud-Gebühren für das Lesen der Daten in dem Wiederherstellungsprozess vollständig vermieden werden, wenn der Host die Daten niemals tatsächlich lesen muss.
Blöcke 602 bis 622 von 6A stellen ein ausführlicheres Beispiel für den virtuellen Wiederherstellungsprozess von 5A aus der Sicht eines Host 100 dar. Blöcke 630 bis 650 von 6B stellen ein ausführlicheres Beispiel für den physischen Wiederherstellungsprozess von 5B aus der Sicht eines Host 100 dar.
In dem Beispiel von 6A initiiert der Wiederherstellungs-Manager 123h des Host 100 eine virtuelle Wiederherstellung (5A) durch Ausgeben (Block 602, 6A) eines Befehls (wie durch den mit „Befehl“ bezeichneten Pfeil 604 dargestellt) an ein Bandarchiv des VTS-Speichersystems, in dem der Befehl ein Restore von Datenvolumen anfordert. Bei einer Ausführungsform gibt der Befehl an, wie viele Datenvolumen der Host 100 wiederherstellen muss und von welcher Arbeitskategorie die Zieldatenvolumen verwendet werden können. Ein solcher Befehl oder eine solche Anforderung kann manuell oder automatisch durch eine geeignete Schnittstelle wie zum Beispiel eine Verwaltungsschnittstelle ausgegeben werden. Bei einer Ausführungsform kann die Anforderung in einem Format vorliegen wie zum Beispiel
LIBRARY REQUEST, library-name, RECOVER, NUM, N, C
wobei der Name des Befehls „LIBRARY REQUEST“ ist und der Parameter „library-name“ das Zielarchiv kennzeichnet, an das der Befehl gerichtet ist, der Parameter „RECOVER“ die zu ergreifende Aktion kennzeichnet, die Parameter „NUM, N“ kennzeichnen, wie viele Datenvolumen wiederherzustellen sind, und der Parameter „C“ die Arbeitskategorie kennzeichnet, von der die Zielarbeitsdatenvolumen verwendet werden können. Folglich fordert die Anforderung
LIBRARY REQUEST, library-name, RECOVER, NUM, 1, 0002
eine Wiederherstellung eines einzelnen logischen Datenvolumens mithilfe der Arbeitskategorie 0002 als Zielkategorie an. Es versteht sich, dass abhängig von der jeweiligen Anwendung sonstige Befehls- oder Anforderungsformate, -namen und -parameter verwendet werden können.
Bei der veranschaulichten Ausführungsform stellen Blöcke 702 bis 726 von 6A ein Beispiel für den virtuellen Wiederherstellungsprozess von 5A aus der Sicht eines Bandarchivs eines Speicher-Servers 104 wie etwa eines VTS (eines virtuellen Band-Servers) 104 dar, und Blöcke 738 bis 760 von 6B stellen ein Beispiel für den physischen Wiederherstellungsprozess von 5B aus der Sicht des Bandarchivs des VTS-Speicher-Servers 104 des Speichersystems dar. In dem Beispiel von 6A empfängt (Block 702, 6A) der Wiederherstellungs-Manager 123 des VTS 104 als Reaktion auf den Befehl 604 von Block 602 (6A), der eine Initiierung des virtuellen Wiederherstellungsprozesses für die angegebene Anzahl von Datenvolumen, die aus der angegebenen Arbeitskategorie zu beziehen sind, anfordert, den Befehl und wählt (Block 702, 6A) das/die jeweilige(n) Datenvolumen aus der angegebenen Arbeitskategorie aus und platziert sie in einer speziellen Rückstellungskategorie.
7A stellt in Tabellenform Metadaten dar, die durch das Bandarchiv des VTS 104 der Speichereinheit in einer geeigneten Datenbank verwaltet werden, die hierin als Bandarchivkatalog bezeichnet wird. Das Beispiel von 7A stellt drei Einträge für drei Datenvolumen, Datenvolumen-Folge-Nr. L00000, Version V1, Datenvolumen-Folge-Nr. L00000, Version V2 und Arbeitsdatenvolumen S99999 dar, das als in der Arbeitskategorie 0002 befindlich kategorisiert ist. Wenngleich der VTS-Katalog der Einfachheit halber so dargestellt ist, dass er drei Einträge aufweist, versteht es sich, dass ein VTS-Bandarchivkatalog abhängig von der jeweiligen Anwendung Tausende oder mehr Einträge aufweisen kann.
Als Reaktion auf den Befehl
LIBRARY REQUEST, library-name, RECOVER, NUM, 1, 0002
von dem Host kann der Wiederherstellungs-Manager 123 des VTS 104 zum Beispiel das Arbeitsdatenvolumen S99999 (7A) der allgemeinen Arbeitskategorie 0002 für den in 5A dargestellten virtuellen Wiederherstellungsprozess auswählen (Block 702, 6A) . In dem Fall wählt der VTS 104 das Arbeitsdatenvolumen S99999 aus der allgemeinen Arbeitskategorie 0002 aus und platziert (Block 710, 6A) das Datenvolumen vorübergehend in einer speziellen Rückstellungskategorie wie zum Beispiel einer Kategorie Y000, wie in 7B dargestellt. Darüber hinaus gibt der Wiederherstellungs-Manager 123 des VTS 104 eine durch den Pfeil 712 dargestellte Reaktion an den Host aus, die den Wiederherstellungs-Manager 123h des Host 100 darüber informiert, dass das Arbeitsdatenvolumen mit der Datenvolumen-Folge-Nr. S99999 als Reaktion auf die durch den Host ausgegebene Anforderung aus der angegebenen Arbeitskategorie 0002 bezogen worden ist.
Nachdem der Wiederherstellungs-Manager 123h des Host 100 die Angabe des angeforderten Arbeitsdatenvolumens als die Datenvolumen-Folge-Nr. S99999 aufweisend empfangen hat (Block 606, 6A), gibt (Block 610, 6A) er einen weiteren Befehl, wie durch den Pfeil 612 dargestellt, an den VTS 104 aus, der anfordert, dass das Zielarbeitsdatenvolumen mit der Datenvolumen-Folge-Nr. S99999 in einer privaten Kategorie platziert wird, um sicherzustellen, dass es nicht für einen weiteren Zweck durch sonstige Hosts oder sonstige Host-Prozesse verwendet wird. Wie im Folgenden erläutert wird, wird das Arbeitsdatenvolumen mit der Datenvolumen-Folge-Nr. S99999 als Zielarbeitsdatenvolumen, wie durch das Datenvolumen VolP (5A) dargestellt, für den in 5A dargestellten virtuellen Wiederherstellungsprozess verwendet. Als Reaktion auf den Befehl 612 platziert (Block 718, 6A) der Wiederherstellungs-Manager 123 des VTS 104 das Arbeitsdatenvolumen mit der Datenvolumen-Folge-Nr. S99999 in einer privaten Kategorie wie zum Beispiel der Kategorie C000, wie in 7C angegeben.
Nachdem er das Arbeitsdatenvolumen mit der Datenvolumen-Folge-Nr. S99999 für seine eigene private Verwendung reserviert hat, gibt (Block 614, 6A) der Wiederherstellungs-Manager 123h des Host 100 einen Befehl, wie durch den Pfeil 616 dargestellt, zum Zuweisen einer oder mehrerer Aufbewahrungsrichtlinien zu dem Arbeitsdatenvolumen mit der Datenvolumen-Folge-Nr. S99999 an den VTS 104 aus. Diese Richtlinien definieren, wie lange ein Datenvolumen zum Beispiel aufzubewahren ist, bevor er verworfen werden darf.
Beispielsweise kann der Host 100 einen bekannten Befehl wie zum Beispiel den bestehenden Befehl MVS LIBRARY LMPOLICY verwenden, um das „n“ (jetzt private) angeforderte Datenvolumen, die bei der Wiederherstellung verwendet werden, Richtlinien zuzuweisen (Block 614, 6A). In diesem Beispiel wird der Befehl LIBRARY LMPOLICY mit den folgenden Parametern verwendet, um dem Arbeitsdatenvolumen S99999 Aufbewahrungsrichtlinien zuzuweisen:

LIBRARY LMPOLICY, S99999, SG=SGRECOVER, MC=MCRECOVER, SC=SCRECOVER, DC=DCRECOVER.

Bei den in dem Bandarchiv des VTS 104 erstellten Richtlinien könnte es sich um bestehende Richtlinien handeln, die für ihre sonstigen Daten verwendet werden, oder es könnte sich um neue Richtlinien zum Zweck der Wiederherstellung handeln.
Als Reaktion auf den Empfang des Richtlinienzuweisungsbefehls 616 weist (Block 718) der VTS 104 die durch den Befehl 616 angegebene(n) Richtlinie oder Richtlinien dem Arbeitsdatenvolumen mit der Datenvolumen-Folge-Nr. S99999 zu. Die Zuweisung von Richtlinien zu dem Arbeitsdatenvolumen mit der Datenvolumen-Folge-Nr. S99999 wird in 7D so dargestellt, dass das Arbeitsdatenvolumen mit der Datenvolumen-Folge-Nr. S99999 der Kategorie C000 zugewiesen wird. Auf diese Weise sind Richtlinienaktionen den angegebenen Richtliniennamen in dem Bandarchiv des VTS zugehörig (Block 718, 6A).
Nachdem er das Arbeitsdatenvolumen mit der Datenvolumen-Folge-Nr. S99999 für seine eigene private Verwendung reserviert hat und diesem Arbeitsdatenvolumen die entsprechende Aufbewahrungsrichtlinie zugewiesen hat, gibt (Block 618, 6A) der Wiederherstellungs-Manager 123h des Host 100 einen Wiederherstellungsbefehl an den VTS 104 aus, wie durch den Pfeil 620 dargestellt. Der Wiederherstellungsbefehl, der hierin als MVS LIBRARY RECOVER bezeichnet wird, gibt das zum Wiederherstellen ausgewählte Datenvolumen und das als Zielarbeitsdatenvolumen ausgewählte Datenvolumen an. Für den Befehl MVS LIBRARY RECOVER können beispielsweise Parameter wie folgt angegeben werden:

LIBRARY REQUEST, library-name, RECOVER, S99999, L00000, V2.

Auf diese Weise gibt der Wiederherstellungsbefehl 620 in diesem Beispiel das private Arbeitsdatenvolumen S99999, das in diesem Beispiel in dem dritten Eintrag des VTS-Katalogs (7D) dargestellt wird, als Zielarbeitsdatenvolumen an. Dementsprechend ist das private Arbeitsdatenvolumen S99999 in diesem Beispiel durch den Wiederherstellungsbefehl 620 als Zielarbeitsdatenvolumen VolP in dem virtuellen Wiederherstellungsprozess von 5A ausgewählt worden.
Der Wiederherstellungsbefehl 620 in diesem Beispiel gibt darüber hinaus das Wiederherstellungsdatenvolumen als Datenvolumen mit der Folge-Nr. L00000, Version V2 an, das in der Datenvolumenkategorie C000 kategorisiert ist, wie durch den zweiten Eintrag des VTS-Bandarchivkatalogs von 7D dargestellt. Dementsprechend ist das Wiederherstellungsdatenvolumen L00000, Version V2, in diesem Beispiel als Wiederherstellungsdatenvolumen VoIR in dem virtuellen Wiederherstellungsprozess von 5A ausgewählt worden.
Bei einigen Ausführungsformen kann der virtuelle Wiederherstellungsprozess von 5A durch einen Benutzer durch eine geeignete Benutzeroberfläche initiiert werden. Nach der Initiierung kann der Host 100 bei einer Ausführungsform die Befehle von 6A automatisch ausgeben. Bei sonstigen Ausführungsformen können einer oder mehrere der in Verbindung mit 6A beschriebenen Befehle durch einen Benutzer manuell von dem Host 100 durch eine geeignete Benutzeroberfläche für den Host ausgegeben werden.
Als Reaktion auf den Wiederherstellungsbefehl 620, der durch den Host 100 ausgegeben wird, der das Wiederherstellungsdatenvolumen VoIR und das Zielarbeitsdatenvolumen VolP für den virtuellen Wiederherstellungsprozess (5A) angibt, implementiert (Block 720, 6A) der Wiederherstellungs-Manager 123 des VTS 104 den in 5A dargestellten virtuellen Wiederherstellungsprozess, um das Datenvolumen VoIR mithilfe des Zielarbeitsdatenvolumens VolP virtuell wiederherzustellen. Bei einer Ausführungsform des virtuellen Wiederherstellungsprozesses ändert (Block 722, 6A) der VTS 104 den Status des Wiederherstellungsdatenvolumens VoIR (in diesem Beispiel Datenvolumen L00000, V2) in den Rückstellungsstatus, wie in 7D für den VTS-Bandarchivkatalog angegeben, von dem vorherigen Aufbewahrungsstatus, wie in 7C für den VTS-Bandarchivkatalog angegeben.
In diesem Beispiel ist das Wiederherstellungsdatenvolumen VoIR in dem Rückstellungsstatus als schreibgeschützt markiert (Block 722, 6A), um sicherzustellen, dass jegliche vorherige Eigenschaften erhalten bleiben und dass das Wiederherstellungsdatenvolumen VoIR durch den Wiederherstellungsprozess nicht modifiziert wird, das heißt, dass das Wiederherstellungsdatenvolumen VoIR unveränderlich ist. Das Zielarbeitsdatenvolumen VolP (in diesem Beispiel das Datenvolumen S99999) kann abhängig von Kundenvorgaben auch als unveränderlicher oder als Lese-/Schreib-Datenvolumen behandelt werden.
Auf diese Weise kann der Host 100 als Teil der virtuellen Wiederherstellung von 5A jegliches Laden sowohl des Wiederherstellungsdatenvolumens VoIR als auch des privaten Zielarbeitsdatenvolumens VolP für den virtuellen Wiederherstellungsprozess vollständig umgehen, wodurch das Band- oder sonstige Speicherlaufwerke des Speicher-Servers für eine sonstige Nutzung während des virtuellen Wiederherstellungsprozesses frei bleiben. Solange der Host 100 nicht auf einen tatsächlichen Bedarf zum Zugreifen auf die Daten des Wiederherstellungsdatenvolumens VoIR trifft, können sowohl das Wiederherstellungsdatenvolumen VoIR als auch das Zielarbeitsdatenvolumen VolP ungeladen bleiben. Falls jedoch der Bedarf zum Zugreifen auf die Daten des Wiederherstellungsdatenvolumens VoIR entstehen sollte, kann die physische Wiederherstellung von 5B implementiert werden, wie im Folgenden beschrieben wird.
In einem weiteren Aspekt des virtuellen Wiederherstellungsprozesses und als weitere Reaktion auf den Empfang des Wiederherstellungsbefehls 620 (Block 722, 6A) verknüpft (Block 726, 6A) der Wiederherstellungs-Manager 123 des VTS 104 das Wiederherstellungsdatenvolumen VoIR (in diesem Beispiel Datenvolumen L00000, V2) mit dem Zielarbeitsdatenvolumen VolP (in diesem Beispiel Datenvolumen S99999, Version V1) für den virtuellen Wiederherstellungsprozess. Bei einer Ausführungsform enthält das Verknüpfen des Wiederherstellungsdatenvolumens VoIR und des Zielarbeitsdatenvolumens VolP durch den VTS 104 ein Zuordnen des Zielarbeitsdatenvolumens VolP zu dem Wiederherstellungsdatenvolumen VoIR, wie durch den mit „Zuordnen“ bezeichneten Pfeil 504 in 5A dargestellt. Bei der veranschaulichten Ausführungsform kann das Zuordnen durch Ändern von Metadaten für das Zielarbeitsdatenvolumen VolP (in diesem Beispiel S99999) erreicht werden, um auf die Daten zu verweisen, die auf dem Wiederherstellungsdatenvolumen VoIR (in diesem Beispiel L00000, V2) gespeichert sind. Beispielsweise können Metadaten in Form eines Bandarchiv-Katalogeintrags des VTS 104 konfiguriert werden, wie in dem Zuordnungskatalogeintrag dargestellt, der durch die Tabelle von 8A dargestellt wird, um das Zielarbeitsdatenvolumen VolP dem Wiederherstellungsdatenvolumen VoIR zuzuordnen, so dass die Metadaten, die durch den VTS-Zuordnungskatalogeintrag von 8A dargestellt werden und dem Zielarbeitsdatenvolumen VolP zugehörig sind, auf das Wiederherstellungsdatenvolumen VoIR verweisen.
Wie in Verbindung mit einer physischen Wiederherstellung wie zum Beispiel der in 5B dargestellten ausführlicher erläutert, kann das Zuordnen des Zielarbeitsdatenvolumens VolP zu dem Wiederherstellungsdatenvolumen VoIR, wie in 5A und 8A dargestellt, bei einer künftigen physischen Wiederherstellung genutzt werden, um die Daten des Wiederherstellungsdatenvolumens VolP zu suchen und zu lesen, falls der Host 100 auf die Daten des Wiederherstellungsdatenvolumens VoIR zugreifen muss, nachdem die virtuelle Wiederherstellung abgeschlossen ist. Für die virtuelle Wiederherstellung der veranschaulichten Ausführungsform ist es selbst jedoch nicht erforderlich, dass das Wiederherstellungsdatenvolumen VoIR oder das Zielarbeitsdatenvolumen VolP geladen werden und von diesen gelesen oder auf diese geschrieben wird. Stattdessen wird das Zuordnen (5A), wie es durch den Pfeil 504 in 5A und den VTS-Katalogeintrag von 8A dargestellt wird, durch Konfigurieren von Metadaten, die den Datenvolumen VoIR und VolP zugehörig sind, erreicht, ohne eines der Datenvolumen laden zu müssen. Auf diese Weise kann eine virtuelle Wiederherstellung erreicht werden, ohne von jeglichen Backend-Speichereinheiten wie zum Beispiel einem physischen Bandlaufwerk oder der Cloud zu lesen. Darüber hinaus müssen keine Header-Informationen innerhalb der auf einem Datenvolumen gespeicherten Daten modifiziert werden, um die virtuelle Wiederherstellung abzuschließen.
Im Vergleich erfordert die Wiederherstellung bei verschiedenen bekannten Wiederherstellungsverfahren, dass das Wiederherstellungsdatenvolumen von einer externen Speichereinheit gelesen wird, die gelesenen Daten modifiziert werden, um eine andere VOLSER anzugeben, und zurück auf die Speichereinheit geschrieben werden. Im Gegensatz dazu können, wie oben angemerkt, bei der virtuellen Wiederherstellung von 5A, 6A und 8A die auf dem Wiederherstellungsdatenvolumen VoIR (in diesem Beispiel L00000 V2) gespeicherten Daten ohne Zugriff bleiben und können daher während der gesamten virtuellen Wiederherstellung ungeladen, ungelesen und nichtgeschrieben bleiben.
Nachdem der Host 100 den Wiederherstellungsbefehl an den VTS 104 ausgegeben hat (Block 618, 6A), wie durch den Pfeil 620 dargestellt, der das zum Wiederherstellen ausgewählte Datenvolumen VoIR und das als Zielarbeitsdatenvolumen ausgewählte Datenvolumen VolP angibt, verknüpft (Block 622, 6A) der Wiederherstellungs-Manager 123h des Host 100 darüber hinaus das Wiederherstellungsdatenvolumen VoIR (in diesem Beispiel Datenvolumen L00000, v2) mit dem Zielarbeitsdatenvolumen VolP (in diesem Beispiel Datenvolumen S99999, Version V1) für den virtuellen Wiederherstellungsprozess. Bei einer Ausführungsform enthält das Verknüpfen des Wiederherstellungsdatenvolumens VoIR und des Zielarbeitsdatenvolumens VolP durch den Host 100 ein Zuordnen des Zielarbeitsdatenvolumens VolP zu dem Wiederherstellungsdatenvolumen VoIR. Das Zuordnen des Zielarbeitsdatenvolumens VolP zu dem Wiederherstellungsdatenvolumen VoIR durch den Host 100 ist ebenfalls ein Bestandteil des Zuordnens, das durch den Pfeil 504, der mit „Zuordnen“ bezeichnet ist, in 5A dargestellt wird.
Bei der veranschaulichten Ausführungsform kann das Zuordnen durch den Host 100 durch Ändern von Metadaten für das Zielarbeitsdatenvolumen VolP (in diesem Beispiel S99999) erreicht werden, um auf das Zielarbeitsdatenvolumen zu verweisen, als ob es das Wiederherstellungsdatenvolumen VoIR (in diesem Beispiel L00000) wäre. Metadaten in Form eines Zuordnungskatalogeintrags des Host 100 können zum Beispiel konfiguriert werden, wie in dem Host-Katalogeintrag dargestellt, der durch die Tabelle von 8B dargestellt wird, um auf das Zielarbeitsdatenvolumen VolP zu verweisen, als ob es bereits die Daten enthielte, die aktuell in dem Wiederherstellungsdatenvolumen VoIR gespeichert sind. Bei einer Ausführungsform werden Verweise auf die VOLSER des Wiederherstellungsdatenvolumens VoIR (in diesem Fall Datenvolumen L00000) gegen die VOLSER des Zielarbeitsdatenvolumens VolP (in diesem Beispiel S99999) ausgetauscht. Falls der Host zum Beispiel die Datensätze suchen müsste, die aktuell innerhalb des Wiederherstellungsdatenvolumens VoIR gespeichert sind, werden folglich Verweise auf das Wiederherstellungsdatenvolumen VoIR gegen Verweise auf das Zielarbeitsdatenvolumen VolP ausgetauscht, wie in 8B dargestellt. Wenngleich das Zuordnen von Metadaten bei der veranschaulichten Ausführungsform als Katalogeintrag beschrieben wird, versteht es sich, dass ein solches Zuordnen von Metadaten abhängig von der jeweiligen Anwendung in sonstigen Formen wie zum Beispiel in Datenstrukturen innerhalb von Anwendungen erfolgen kann.
Wie in Verbindung mit einer physischen Wiederherstellung wie zum Beispiel der in 5B dargestellten ausführlicher erläutert, kann das Zuordnen des Zielarbeitsdatenvolumens VolP zu dem Wiederherstellungsdatenvolumen VoIR, wie in 5A, 8A und 8B dargestellt, bei einer künftigen physischen Wiederherstellung genutzt werden, so dass der Host 100 das Zielarbeitsdatenvolumen VolP lädt, falls der Host 100 auf die Daten des Wiederherstellungsdatenvolumens VoIR zugreifen muss, nachdem die virtuelle Wiederherstellung abgeschlossen ist. Wie oben angemerkt, ist es für die virtuelle Wiederherstellung der veranschaulichten Ausführungsform selbst jedoch nicht erforderlich, dass das Wiederherstellungsdatenvolumen VoIR oder das Zielarbeitsdatenvolumen VolP geladen werden oder von diesen gelesen oder auf diese geschrieben wird. Stattdessen wird das Zuordnen (5A), wie es durch den Pfeil 504 in 5A und durch den VTS-Katalogeintrag von 8A und den Host-Zuordnungskatalogeintrag von 8B dargestellt wird, jeweils dadurch erreicht, dass der VTS 104 und der Host 100 Metadaten konfigurieren, die den Datenvolumen VoIR und VolP zugehörig sind, ohne eines der Datenvolumen laden zu müssen. Auf diese Weise kann eine virtuelle Wiederherstellung erreicht werden, ohne von jeglichen Backend-Speichereinheiten wie zum Beispiel einem physischen Bandlaufwerk oder der Cloud zu lesen. Darüber hinaus müssen keine Header-Informationen innerhalb der auf einem Datenvolumen gespeicherten Daten modifiziert werden, um die virtuelle Wiederherstellung abzuschließen.
Im Vergleich erfordert die Wiederherstellung bei verschiedenen bekannten Wiederherstellungsverfahren, dass das Wiederherstellungsdatenvolumen von einer externen Speichereinheit gelesen wird, die gelesenen Daten modifiziert werden, um eine andere VOLSER anzugeben, und zurück auf die Speichereinheit geschrieben werden. Im Gegensatz dazu können, wie oben angemerkt, bei der virtuellen Wiederherstellung von 5A, 6A, 8A und 8B die auf dem Wiederherstellungsdatenvolumen VoIR (in diesem Beispiel L00000 V2) gespeicherten Daten ohne Zugriff bleiben und können daher während der gesamten virtuellen Wiederherstellung ungelesen und ungeschrieben (unveränderlich) bleiben.
Wie oben angemerkt, stellt 5B ein Beispiel für einen physischen Wiederherstellungsprozess gemäß der vorliegenden Beschreibung in dem Fall dar, dass der Host 100 zu anderen Zwecken als zur Wiederherstellung tatsächlich auf die Daten des Wiederherstellungsdatenvolumens VoIR zugreifen muss. 6B stellt ein ausführlicheres Beispiel für den physischen Wiederherstellungsprozess von 5A dar. Falls der Host 100 ermittelt (Block 630, 6B), dass er tatsächlich auf die Daten des Wiederherstellungsdatenvolumens VoIR zugreifen muss, das durch den virtuellen Wiederherstellungsprozess, wie oben beschrieben, dem Zielarbeitsdatenvolumen VoIR zugeordnet worden ist (8B), als wäre er in dem Zieldatenvolumen VolP enthalten, gibt (Block 634, 6B) der Wiederherstellungs-Manager 123h des Host 100 bei dieser Ausführungsform einen Befehl zum Laden des Zielarbeitsdatenvolumens VolP, das durch den Host 100 dem Wiederherstellungsvolumen-VolR zugeordnet worden ist, an den VTS 104 aus. An dieser Stelle wird das Zielarbeitsdatenvolumen VolP als privates Zieldatenvolumen VolP statt als Arbeitsdatenvolumen bezeichnet. Auf diese Weise behandelt der Host 100 das private Zieldatenvolumen VolP (in diesem Beispiel S99999), als wäre es das Wiederherstellungsdatenvolumen VoIR (in diesem Beispiel L00000, V2), wie oben beschrieben. Der Befehl an den VTS 104 zum Laden des privaten Zieldatenvolumens VolP wird in 6B durch den mit „Befehl“ bezeichneten Pfeil 636 dargestellt und initiiert den physischen Wiederherstellungsprozess von 5B mithilfe des privaten Zieldatenvolumens VolP für das Wiederherstellungsdatenvolumen VoIR.
Als Reaktion auf den Befehl 636 des Host 100 zum Laden des privaten Zieldatenvolumens VolP lädt (Block 738, 6B) der Wiederherstellungs-Manager 123 des VTS 104 das private Zieldatenvolumen VolP (in diesem Beispiel S99999), lädt (Block 738, 6B) jedoch auch das Wiederherstellungsdatenvolumen VoIR (in diesem Beispiel L00000, V2), dem das Zielarbeitsdatenvolumen VolP in dem oben beschriebenen Wiederherstellungsprozess durch den VTS 104 zugeordnet wurde. In diesem Beispiel ist das Zielarbeitsdatenvolumen VolP durch den VTS 104 zugeordnet worden, der Metadaten konfiguriert, die dem privaten Zieldatenvolumen VolP zugehörig sind, um auf das Wiederherstellungsdatenvolumen VoIR zu verweisen. Der VTS 104 aktualisiert darüber hinaus den VTS-Bandarchivkatalog, um den „Lade“-Status des privaten Zieldatenvolumens VolP anzugeben, wie in 7E dargestellt.
Mithilfe des Zuordnens des privaten Zieldatenvolumens VolP (in diesem Beispiel S99999) zu dem Wiederherstellungsdatenvolumen VoIR (in diesem Beispiel L00000, V2) wird durch den Wiederherstellungs-Manager 123 auf die Daten des geladenen Wiederherstellungsdatenvolumens VoIR zugegriffen und werden diese durch ihn auf das private Zieldatenvolumen VolP kopiert (Block 742), wie durch den Pfeil 514 (5B) dargestellt, der mit „Daten kopieren“ bezeichnet ist. 9A stellt in schematischer Form ein Beispiel für Daten dar, die von dem geladenen Wiederherstellungsdatenvolumen VoIR gelesen werden, die einen Header-Abschnitt 902 mit Metadaten enthalten, der die Quelle der Daten als das Wiederherstellungsdatenvolumen VoIR kennzeichnet. Der Header-Abschnitt 902 kann abhängig von der jeweiligen Anwendung sonstige Metadaten enthalten, die sonstige Eigenschaften der Daten beschreiben, die von dem Wiederherstellungsdatenvolumen VoIR gelesen werden.
Die übrigen Daten, die von dem Wiederherstellungsdatenvolumen VoIR (in diesem Fall L00000, V2) gelesen werden, werden in 9A als Nicht-Header-Daten 904 bezeichnet und enthalten die auf dem Wiederherstellungsdatenvolumen VoIR gespeicherten Benutzerdaten und können abhängig von der jeweiligen Anwendung sonstige Typen von Daten enthalten. Auf die Nicht-Header-Daten 904 wird zugegriffen, und sie werden von dem geladenen Wiederherstellungsdatenvolumen VoIR auf das private Zieldatenvolumen VolP (in diesem Beispiel S99999) kopiert (Block 742, 6B), wie in 9B angegeben und wie durch den Pfeil 514 (5B) dargestellt, der mit „Daten kopieren“ bezeichnet ist.
Während die Nicht-Header-Daten 904 auf das private Zieldatenvolumen VolP (in diesem Beispiel S99999) kopiert werden, werden die Header-Daten 902, die von dem Wiederherstellungsdatenvolumen VoIR gelesen werden, gegen einen Austausch-Header 906 (9B) ausgetauscht (Block 746, 6B), der mit den Daten 904 auf dem privaten Zieldatenvolumen VolP gespeichert wird, wie in 9B dargestellt und wie durch den Pfeil 518 (5B) dargestellt, der in 5B mit „Header modifizieren“ bezeichnet ist. Auf diese Weise werden die Daten, die von dem Wiederherstellungsdatenvolumen VoIR gelesen werden, neu benannt, wenn sie auf dem privaten Zieldatenvolumen VolP gespeichert werden, um als Quelle der Daten bei nachfolgenden Lesevorgängen dieser Daten von dem Datenvolumen VolP das private Zieldatenvolumen VolP (in diesem Beispiel S99999) anzugeben. Auf das wiederhergestellte Datenvolumen kann nun bei allen Verwendungen als Datenvolumen mit der Folge-Nr. S99999 zugegriffen werden.
Darüber hinaus wird ein Zugreifen und Kopieren von Daten von dem Wiederherstellungsdatenvolumen VoIR verzögert, bis ein Zugriff auf die Daten durch den Host angefordert wird. Des Weiteren handelt es sich bei dem Neubenennen der Datenquelle ebenfalls um einen Prozess nach Bedarf, in dem eine Modifizierung des Headers für den Kopiervorgang, der auf das private Zieldatenvolumen VolP abzielt, ebenso verzögert wird, bis ein Zugriff auf die Daten des Wiederherstellungsdatenvolumens VoIR durch den Host 100 durch Anfordern eines Ladens des privaten Zieldatenvolumen VolP angefordert wird. Bei dieser Ausführungsform kann das Wiederherstellungsdatenvolumen VoIR im Laufe der physischen Wiederherstellung wie auch der virtuellen Wiederherstellung unveränderlich, das heißt, ungeändert (Block 748, 6B) bleiben, wie oben beschrieben. Auf diese Weise kann das Wiederherstellungsdatenvolumen VoIR weiterhin als Quelle verwendet werden, wenn künftige Lesevorgänge von der/dem externen Speichereinheit, Cloud oder Band benötigt werden.
Bei Abschluss (Block 752, 6B) des Kopierens und des Neubenennens von Daten von dem Wiederherstellungsdatenvolumen VoIR auf das Zieldatenvolumen VolP meldet (Block 754, 6B) der Wiederherstellungs-Manager 123 des VTS 104 dem Host 100, dass die physische Wiederherstellung des Wiederherstellungsdatenvolumens VoIR auf dem Zieldatenvolumen VolP (in diesem Fall S99999) abgeschlossen ist, wie durch den Pfeil 756 (6B) dargestellt, der mit „Melden“ bezeichnet ist. Der Abschluss des Kopierens und des Neubenennens von Daten kann als „Laden abgeschlossen“ bezeichnet werden. Darüber hinaus aktualisiert der VTS 104 den VTS-Bandarchivkatalog, um den Aktiv-Status des Zieldatenvolumens VolP anzugeben, wie in 7F dargestellt.
Als Reaktion verifiziert (Block 644, 6B) der Wiederherstellungs-Manager 123h des Host 100 bei dieser Ausführungsform die Daten des Zieldatenvolumens VolP und gibt einen Befehl an den VTS 104 aus, wie durch den Pfeil 650 dargestellt, der mit „Befehl“ bezeichnet ist, um den Rückstellungsstatus auf dem Wiederherstellungsdatenvolumen VoIR aufzuheben (Block 648, 6B). Als Reaktion aktualisiert der VTS 104 den Status des Wiederherstellungsdatenvolumens VoIR in dem VTS-Bandarchivkatalog, um den „Rückstellungs“-Status aufzuheben und den „Aufbewahrungs“-Status wiederherzustellen, wie in 7G dargestellt.
Bei der veranschaulichten Ausführungsform muss, nachdem die virtuelle Wiederherstellung der Daten von dem Wiederherstellungsdatenvolumen VoIR (in diesem Beispiel L00000 V2) auf dem privaten Zieldatenvolumen VolP (in diesem Beispiel S99999, V1) abgeschlossen ist, der Host keine Zuordnung des privaten Datenvolumens VolP zu dem Wiederherstellungsdatenvolumen VoIR verfolgen. Soweit dem Host bekannt ist, sind die Daten in S99999 vollständig wiederhergestellt. Wenn der Host die Daten zu diesem Zeitpunkt lesen will, führt er einfach ein normales Archivladen (bei der veranschaulichten Ausführungsform als „LUM“ bezeichnet) des privaten Zieldatenvolumens VolP durch, um die Wiederherstellungsdaten zu lesen, wie bei einem beliebigen sonstigen Datenvolumen. Wenn die physische Wiederherstellung noch nicht stattgefunden hat, geht der VTS 104, der die Zuordnungsinformationen verwaltet, zum Kopieren der Daten und zum Modifizieren der Header für die physische Wiederherstellung von dem Wiederherstellungsdatenvolumen VoIR zu dem privaten Zieldatenvolumen VolP über, wie in Verbindung mit 5B beschrieben.
In einem weiteren Aspekt einer Verwaltung einer Wiederherstellung eines Datenspeicher-Datenvolumens gemäß der vorliegenden Beschreibung kann der virtuelle Wiederherstellungsprozess von 5A und 6A verwendet werden, um Datenvolumen von einer weiteren Quelle, die ein(e) andere(s) oder konfligierende(s) Schema oder Konvention zur Datenvolumen-Folgenummerierung aufweist, schnell und effizient zu importieren. Bei einer Ausführungsform kann jedes der zu importierenden Datenvolumen wie zum Beispiel ein Datenvolumen VoIR (5A) einem neuen privaten Zieldatenvolumen VolP zugeordnet oder neu zugeordnet werden (wie durch den Pfeil 504, 6A dargestellt), wobei jedes solche Datenvolumen VolP eine VOLSER aufweist, die zum Beispiel der bestehenden Konvention des Host 100 oder des Speicher-Servers 104 des Ziel-Datenspeichersystems für Datenvolumen-Folgenummern entspricht. Auf diese Weise können die zu importierenden Datenvolumen VoIR (5A) jeweils neuen VOLSERs zugeordnet oder neu zugeordnet werden, die nicht mit bestehenden aktiven VOLSERs übereinstimmen oder die in anderer Weise mit bestehenden VOLSERs des Host oder Speicher-Servers zum Beispiel eines Ziel-Datenspeichersystems in Konflikt stehen. Darüber hinaus können die Datenvolumen VoIR, die importiert werden, VOLSERs von privaten Zieldatenvolumen VolP zugeordnet oder neu zugeordnet werden, die bestehenden Konventionen für einen Datenvolumen-Folgenummernbereich entsprechen und diese dadurch einhalten.
Es versteht sich, dass die in einen Ziel-VTS zu importierenden Datenvolumen abhängig von der jeweiligen Anwendung zum Beispiel Hunderte, Tausende, Millionen oder mehr betragen können. Der virtuelle Wiederherstellungsprozess der veranschaulichten Ausführungsform ermöglicht, dass große Anzahlen von Datenvolumen leicht in einen Ziel-VTS importiert werden, ohne jegliche der Datenvolumen, die mithilfe des virtuellen Wiederherstellungsprozesses importiert werden, zu laden oder auf andere Weise auf diese zuzugreifen. Infolgedessen können die Datenvolumen, die importiert werden, gehärtet werden, um die Gültigkeit ihres Inhalts aufrechtzuerhalten, da jedes importierte Datenvolumen unveränderlich bleiben kann und nur bei Bedarf als Teil einer zukünftigen Wiederaufrufanforderung einer künftigen physischen Wiederherstellung neu benannt werden kann. Aus juristischen Gründen kann zum Beispiel der Status der Daten zum Importzeitpunkt erfordern, dass sie unveränderlich bleiben, um einen konsistenten Punkt einer Arbeitsprozesserfassung aufrechtzuerhalten. Ein virtueller Wiederherstellungsprozess der veranschaulichten Ausführungsform ermöglicht einen Import von Datenvolumen ohne einen Konflikt von Datenvolumen-Folgenummern (VOLSER), ohne auf jede Instanz zugreifen zu müssen und ohne die Quellinstanz modifizieren zu müssen. Falls ein Bedarf entsteht, auf Daten eines importierten Datenvolumens zuzugreifen, kann eine physische Wiederherstellung des importierten Datenvolumens nach Bedarf durchgeführt werden, wie oben in Verbindung mit 5B und 6B beschrieben.
In einem noch weiteren Aspekt kann eine Wiederherstellung eines Speicherdatenvolumens gemäß der vorliegenden Beschreibung rekursiv angewendet werden, um ein Datenvolumen so häufig wie nötig wiederherzustellen, da das Wiederherstellungsdatenvolumen durch den Wiederherstellungsprozess der veranschaulichten Ausführungsform unveränderlich und folglich unverändert bleiben kann. Falls, nachdem an dem Wiederherstellungsdatenvolumen VoIR ein Restore zu dem privaten Zieldatenvolumen VolP durchgeführt worden ist, wie oben beschrieben, das VolP gelöscht wird und der Host anschließend erneut eine Wiederherstellung des Datenvolumens VolP oder des Wiederherstellungsdatenvolumens VoIR anfordert, kann der oben erörterte virtuelle Wiederherstellungsprozess daher wiederholt werden, wobei das Wiederherstellungsdatenvolumen VoIR auf einem neuen Zielarbeitsdatenvolumen wie zum Beispiel dem Zieldatenvolumen VoIP1 wiederhergestellt wird. Das neue Zieldatenvolumen VoIP1 kann bei einer virtuellen Wiederherstellung direkt dem Wiederherstellungsdatenvolumen VoIR statt dem gelöschten Datenvolumen VolP zugeordnet werden, da das Wiederherstellungsdatenvolumen VoIR in diesem Beispiel unveränderlich ist und folglich zum Zeitpunkt der zweiten virtuellen Wiederherstellung die Wiederherstellungsdaten noch enthält. Bei Bedarf kann anschließend eine physische Wiederherstellung durchgeführt werden, die Daten von dem Wiederherstellungsdatenvolumen VoIR auf das neue Zieldatenvolumen VoIP1 überträgt und neu benennt, wie oben in Verbindung mit dem ersten Zieldatenvolumen VolP beschrieben.
Falls das Zieldatenvolumen VoIP1 dann gelöscht wird und der Host anschließend erneut eine Wiederherstellung des Datenvolumens VoIP1 oder des Wiederherstellungsdatenvolumens VoIR anfordert, kann der oben in Verbindung mit den Zieldatenvolumen VolP und VoIP1 erörterte virtuelle Wiederherstellungsprozess noch einmal wiederholt werden, wobei das Wiederherstellungsdatenvolumen VoIR auf einem noch weiteren neuen Zielarbeitsdatenvolumen wie zum Beispiel dem Zieldatenvolumen VoIP2 wiederhergestellt wird. Auf diese Weise kann das neue Zieldatenvolumen VoIP2 bei einer virtuellen Wiederherstellung direkt dem Wiederherstellungsdatenvolumen VoIR statt dem gelöschten Datenvolumen VoIP1 zugeordnet werden, da das Wiederherstellungsdatenvolumen VoIR in diesem Beispiel unveränderlich ist und folglich bei der dritten virtuellen Wiederherstellung die Wiederherstellungsdaten noch enthält. Bei Bedarf kann eine physische Wiederherstellung durchgeführt werden, welche die Daten von dem Wiederherstellungsdatenvolumen VoIR auf das jüngste neue Zieldatenvolumen VoIP2 überträgt und neu benennt, wie oben in Verbindung mit den früheren Zieldatenvolumen VolP und VoIP1 beschrieben. Auf diese Weise ermöglicht die Datenvolumen-Wiederherstellungsverwaltung gemäß der vorliegenden Beschreibung, dass ein Datenvolumen unbegrenzt wiederhergestellt wird und unbegrenzt unveränderlich bleibt.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt handeln. Das Computerprogrammprodukt kann (ein) durch einen Computer lesbare(s) Speichermedium (oder-medien) enthalten, auf dem/denen durch einen Computer lesbare Programmanweisungen gespeichert sind, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine materielle Einheit handeln, die Anweisungen zur Verwendung durch eine Einheit zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die Folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Festwertspeicher (ROM), ein löschbarer programmierbarer Festwertspeicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatten-Festwertspeicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination von diesen. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. durch ein Glasfaserkabel geleitete Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerk-Schnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Vorgängen der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Java, Smalltalk, C++ o.ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). Bei einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, feldprogrammierbare Gate-Arrays (FPGA) oder programmierbare Logik-Arrays (PLA) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsdaten der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Ablaufpläne und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaubildern mittels durch einen Computer lesbare Programmanweisungen implementiert werden können.
Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer sonstigen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen Mittel zum Implementieren der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaubilder angegebenen Funktion/Schritts implementieren.
Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken des Ablaufplans und/oder des Blockschaubildes festgelegten Funktionen/Schritte implementieren.
Der Ablaufplan und die Blockschaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in dem Ablaufplan oder den Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zum Implementieren der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander dargestellte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können bisweilen je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist darüber hinaus zu beachten, dass jeder Block der Blockschaubilder und/oder des Ablaufplans sowie Kombinationen aus Blöcken in den Blockschaubildern und/oder dem Ablaufplan durch spezielle auf Hardware beruhende Systeme implementiert werden können, die die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
Die Datenverarbeitungs-Komponenten der Figuren können in einem oder mehreren Computersystemen wie zum Beispiel dem in 10 dargestellten Computersystem 1002 implementiert sein. Das Computersystem/der Server 1002 kann im allgemeinen Zusammenhang von Anweisungen beschrieben werden, die durch ein Computersystem ausgeführt werden können, wie zum Beispiel Programmmodule, die durch ein Computersystem ausgeführt werden. Im Allgemeinen können Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen usw. enthalten, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen implementieren. Das Computersystem/der Server 1002 kann in verteilten Cloud-Computing-Umgebungen angewendet werden, in denen Aufgaben durch entfernt angeordnete Verarbeitungseinheiten durchgeführt werden, die durch ein Datenübertragungsnetzwerk miteinander verbunden sind. Bei einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl in lokalen als auch in entfernt angeordneten Computersystem-Speichermedien befinden, darunter in Speichereinheiten.
Wie in 10 gezeigt, wird das Computersystem/der Server 1002 in Form einer Universal-Datenverarbeitungseinheit dargestellt. Zu den Komponenten des Computersystems/Servers 1002 können ein oder mehrere Prozessoren oder Verarbeitungseinheiten 1004, ein Systemspeicher 1006 und ein Bus 1008 zählen, der verschiedene Systemkomponenten wie etwa den Systemspeicher 1006 mit dem Prozessor 1004 verbindet, ohne auf diese beschränkt zu sein. Der Bus 1008 stellt einen oder mehrere von mehreren beliebigen Typen von Busstrukturen dar, darunter einen Speicherbus oder eine Speichersteuereinheit, einen Peripheriebus, einen Accelerated Graphics Port und einen Prozessor- oder einen lokalen Bus unter Verwendung einer beliebigen von einer Vielfalt von Busarchitekturen. Beispielsweise, und ohne einschränkend zu wirken, enthalten solche Architekturen einen Industry-Standard-Architecture(ISA)-Bus, einen Micro-Channel-Architecture(MCA)-Bus, einen Enhanced-ISA(EISA)-Bus, einen lokalen Video-Electronics-Standards-Association(VESA)-Bus und einen Peripheral-Component-Interconnects(PCI)-Bus.
Das Computersystem/der Server 1002 enthält üblicherweise eine Vielfalt von durch ein Computersystem lesbaren Medien. Bei solchen Medien kann es sich um beliebige verfügbare Medien handeln, auf die durch das Computersystem/den Server 1002 zugegriffen werden kann, und sie enthalten sowohl flüchtige als auch nichtflüchtige Medien sowie austauschbare und nichtaustauschbare Medien.
Der Systemspeicher 1006 kann durch ein Computersystem lesbare Medien in Form eines flüchtigen Speichers wie zum Beispiel eines Direktzugriffsspeichers (random access memory, RAM) 1010 und/oder eines Cache-Speichers 1012 enthalten. Das Computersystem/der Server 1002 kann des Weiteren sonstige austauschbare/nicht austauschbare, flüchtige/nichtflüchtige Computersystem-Speichermedien enthalten. Lediglich als Beispiel kann ein Speichersystem 1013 zum Lesen von einem nicht austauschbaren, nichtflüchtigen (nicht dargestellten und üblicherweise als „Festplatte“ bezeichneten) Magnetmedium und zum Schreiben darauf bereitgestellt werden. Wenngleich es nicht dargestellt wird, kann ein Magnetplattenlaufwerk zum Lesen von einer austauschbaren, nichtflüchtigen Magnetplatte (z.B. einer „Diskette“) und zum Schreiben darauf und ein optisches Plattenlaufwerk zum Lesen von einer austauschbaren, nichtflüchtigen optischen Platte wie zum Beispiel einer CD-ROM, DVD-ROM oder sonstigen optischen Medien und zum Schreiben darauf bereitgestellt werden. In solchen Fällen kann jedes durch eine oder mehrere Datenmedien-Schnittstellen mit dem Bus 1008 verbunden sein. Wie im Folgenden näher dargestellt und beschrieben wird, kann der Speicher 1006 zumindest ein Programmprodukt enthalten, das einen Satz (z.B. zumindest eins) von Programmmodulen aufweist, die dazu konfiguriert sind, die Funktionen von Ausführungsformen der Erfindung auszuführen.
Ein Programm/Dienstprogramm 1014, das einen Satz (zumindest eins) von Programmmodulen 1016 aufweist, kann als Beispiel und ohne Einschränkung in dem Speicher 1006 gespeichert werden, wie auch ein Betriebssystem, ein oder mehrere Anwendungsprogramme, sonstige Programmmodule und Programmdaten. Von dem Betriebssystem, dem einen oder den mehreren Anwendungsprogrammen, den sonstigen Programmmodulen und Programmdaten und einigen Kombinationen von diesen kann jedes eine Implementierung einer Netzwerkumgebung enthalten. Die Komponenten des Computers 1002 können als Programmmodule 1016 implementiert sein, die im Allgemeinen die Funktionen und/oder Methoden von Ausführungsformen der Erfindung ausführen, wie sie hierin beschrieben wird. Die Systeme von 1 können in einem oder mehreren Computersystemen 1002 implementiert sein, wobei die Computersysteme Daten über ein Netzwerk austauschen können, wenn sie in mehreren Computersystemen 1002 implementiert sind.
Das Computersystem/der Server 1002 kann außerdem mit einer oder mehreren externen Einheiten 1018 wie zum Beispiel einer Tastatur, einer Zeigeeinheit, einer Anzeige 1020 usw.; einer oder mehreren Einheiten, die einem Benutzer ermöglichen, mit dem Computersystem/dem Server 1002 zu interagieren; und/oder beliebigen Einheiten (z.B. einer Netzwerkkarte, einem Modem usw.) Daten austauschen, die dem Computersystem/Server 1002 ermöglichen, Daten mit einer oder mehreren sonstigen Datenverarbeitungseinheiten auszutauschen. Eine solche Datenübertragung kann über Eingabe-/Ausgabe(E/A)-Schnittstellen 1022 durchgeführt werden. Weiterhin kann das Computersystem/der Server 1002 mit einem oder mehreren Netzwerken wie zum Beispiel einem lokalen Netzwerk (local area network, LAN), einem allgemeinen Weitverkehrsnetzwerk (wide area network, WAN) und/oder einem öffentlichen Netzwerk (z.B. dem Internet) über einen Netzwerkadapter 1024 Daten austauschen. Wie dargestellt, tauscht der Netzwerkadapter 1024 Daten mit den sonstigen Komponenten des Computersystems/Servers 1002 über den Bus 1008 aus. Es versteht sich, wenngleich dies nicht dargestellt wird, dass sonstige Hardware- und/oder Software-Komponenten zusammen mit dem Computersystem/Server 1002 verwendet werden könnten. Zu Beispielen zählen, ohne auf diese beschränkt zu sein: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, externe Plattenlaufwerk-Arrays, RAID-Systeme, Bandlaufwerke und Datenarchivierungs-Speichersysteme usw.
Die Begriffe „eine Ausführungsform“, „Ausführungsform“, „Ausführungsformen“, „die Ausführungsform“, die Ausführungsformen", „eine oder mehrere Ausführungsformen“, „einige Ausführungsformen“ und „eine Ausführungsform“ bedeuten „eine oder mehrere (jedoch nicht alle) Ausführungsformen der vorliegenden Erfindung(en)“, es sei denn, dies ist ausdrücklich abweichend angegeben.
Die Begriffe „enthält/enthalten“, „umfasst/umfassen“, „weist auf/weisen auf“ und Varianten davon bedeuten „enthält/enthalten, ist/sind jedoch nicht beschränkt auf“, es sei denn, dies ist ausdrücklich abweichend angegeben.
Das Aufzählen von Elementen bedeutet nicht, dass eines oder alle dieser Elemente sich gegenseitig ausschließen, es sei denn, dies ist ausdrücklich abweichend angegeben.
Die Begriffe „ein“, „eine“ und „der“, „die“, „das“ bedeuten „ein(e) oder mehrere“, es sei denn, dies ist ausdrücklich abweichend angegeben.
Einheiten, die Daten miteinander austauschen, müssen nicht in ununterbrochenem Datenaustausch miteinander stehen, es sei denn, dies ist ausdrücklich abweichend angegeben. Darüber hinaus können Einheiten, die Daten miteinander austauschen, direkt oder indirekt Daten über eine oder mehrere Vermittlungseinheiten austauschen.
Eine Beschreibung einer Ausführungsform mit mehreren Komponenten, die Daten miteinander austauschen, bedeutet nicht, dass alle diese Komponenten erforderlich sind. Vielmehr wird eine Vielfalt optionaler Komponenten beschrieben, um die große Vielfalt möglicher Ausführungsformen der vorliegenden Erfindung zu veranschaulichen.
Wenn hierin eine einzelne Einheit oder ein einzelner Gegenstand beschrieben wird, ist leicht ersichtlich, dass mehr als ein(e) Einheit/Gegenstand (unabhängig davon, ob sie zusammenarbeiten) anstelle einer/eines einzelnen Einheit/Gegenstandes verwendet werden kann. In ähnlicher Weise ist, wenn mehr als eine Einheit oder ein Gegenstand hierin beschrieben wird (unabhängig davon, ob sie zusammenarbeiten), leicht ersichtlich, dass ein(e) einzelne(r) Einheit/Gegenstand anstelle der/des mehr als einen Einheit oder Gegenstandes verwendet werden kann oder dass eine andere Anzahl von Einheiten/Gegenständen anstelle der dargestellten Anzahl von Einheiten oder Programmen verwendet werden kann. Die Funktionalität und/oder die Merkmale einer Einheit können alternativ durch eine oder mehrere sonstige Einheiten verkörpert werden, die nicht ausdrücklich als eine solche Funktionalität/Merkmale aufweisend beschrieben werden. Folglich brauchen sonstige Ausführungsformen der vorliegenden Erfindung die Einheit selbst nicht zu enthalten.
Die vorstehende Beschreibung verschiedener Ausführungsformen der Erfindung ist zum Zwecke der Veranschaulichung und Beschreibung vorgelegt worden. Sie ist nicht als erschöpfend oder die Erfindung auf exakt die beschriebene Form beschränkend gemeint. Vor dem Hintergrund der obigen Lehre sind zahlreiche Modifizierungen und Varianten möglich. Der Umfang der Erfindung soll nicht durch diese ausführliche Beschreibung, sondern vielmehr durch die hierzu beigefügten Ansprüche eingeschränkt werden. Die obige Beschreibung und die obigen Beispiele und Daten stellen eine vollständige Beschreibung der Herstellung und des Einsatzes des Aufbaus der Erfindung bereit. Da viele Ausführungsformen der Erfindung erstellt werden können, ohne vom Wesensgehalt und Umfang der Erfindung abzuweichen, befindet sich die Erfindung in den hierin nachstehend beigefügten Ansprüchen.

Claims

Computerprogrammprodukt zum Durchführen eines Restore an einem Datenvolumen für Daten, das in einem Speicher gespeichert ist, wobei das Computerprogrammprodukt ein durch einen Computer lesbares Speichermedium aufweist, das Programmanweisungen aufweist, die durch einen Prozessor ausführbar sind, um Vorgänge zu bewirken, wobei die Vorgänge aufweisen: Durchführen eines ersten virtuellen Restore an einem ersten Datenvolumen für Daten, das in dem Speicher gespeichert ist, mithilfe eines zweiten Datenvolumens, das ein Konfigurieren von Metadaten aufweist, die dem zweiten Datenvolumen zugehörig sind, um das zweite Datenvolumen dem ersten Datenvolumen als virtuelles Restore des ersten Datenvolumens zuzuordnen; und als Reaktion auf eine Anforderung von Daten, die auf dem ersten Datenvolumen gespeichert sind, durch einen Host, Durchführen eines physischen Restore von Daten des ersten Datenvolumens mithilfe des zweiten Datenvolumens, das ein Übertragen von Daten auf das zweite Datenvolumen von dem ersten Datenvolumen aufweist, dem das zweite Datenvolumen durch das virtuelle Restore zugeordnet worden ist, und Neubenennen von übertragenen Daten in Daten des zweiten Datenvolumens anstelle von Daten des ersten Datenvolumens, so dass ein Zugreifen auf Daten des ersten Datenvolumens verzögert wird, bis ein Zugriff auf die Daten durch den Host angefordert wird, und wobei eine Modifizierung von Daten auf dem ersten Datenvolumen in Verbindung mit einem Restore des ersten Datenvolumens während eines virtuellen und physischen Restore des ersten Datenvolumens vermieden wird.
Computerprogrammprodukt nach Anspruch 1, wobei das Übertragen von Daten auf das zweite Datenvolumen von dem ersten Datenvolumen als Reaktion auf ein Empfangen einer Anforderung durch den Host, das zweite Datenvolumen in ein Speicherlaufwerk zu laden, und als Reaktion auf die Anforderung aufweist: Laden des zweiten Datenvolumens in ein Speicherlaufwerk; Laden des ersten Datenvolumens in ein Speicherlaufwerk; und Kopieren von Daten des ersten Datenvolumens, das durch die Metadaten für das zweite Datenvolumen dem zweiten Datenvolumen zugeordnet worden ist, so, dass das Kopieren von Daten von dem ersten Datenvolumen in Verbindung mit dem Restore des ersten Datenvolumens mithilfe des zweiten Datenvolumens bis zu dem physischen Restore des zweiten Datenvolumens verzögert wird.
Computerprogrammprodukt nach Anspruch 2, wobei das Neubenennen von übertragenen Daten in Daten des zweiten Datenvolumens anstelle von Daten des ersten Datenvolumens ein Modifizieren von Header-Daten aufweist, die von dem ersten Datenvolumen gelesen werden, während Daten auf dem zweiten Datenvolumen gespeichert werden, um Daten, die von dem ersten Datenvolumen kopiert werden, als Daten für das zweite Datenvolumen statt für das erste Datenvolumen zu kennzeichnen, und so, dass ein Modifizieren von Header-Daten, die von dem ersten Datenvolumen gelesen werden, verzögert wird, bis ein Zugriff auf die Daten durch den Host angefordert wird.
Computerprogrammprodukt nach Anspruch 3, wobei das erste Datenvolumen eine erste Datenvolumen-Folgenummer aufweist und das zweite Datenvolumen eine zweite Folgenummer aufweist, die sich von der ersten Datenvolumen-Folgenummer unterscheidet, und wobei das Modifizieren von Header-Daten zum Speichern auf dem zweiten Datenvolumen während des physischen Restore des ersten Datenvolumens ein Austauschen der ersten Folgenummer des ersten Datenvolumens in Header-Daten gegen die zweite Datenvolumen-Folgenummer des zweiten Datenvolumens aufweist, während Header-Daten und Benutzerdaten von dem ersten Datenvolumen gelesen werden und gelesene Daten auf das zweite Datenvolumen kopiert werden.
Computerprogrammprodukt nach Anspruch 2, wobei die Vorgänge des Weiteren ein Kategorisieren des ersten Datenvolumens vor dem Laden des ersten Datenvolumens als schreibgeschütztes Datenvolumen aufweist, um eine Modifizierung des ersten Datenvolumens durch das Restore des ersten Datenvolumens sowohl während des virtuellen Restore als auch während des physischen Restore des ersten Datenvolumens zu verhindern.
Computerprogrammprodukt nach Anspruch 1, wobei vor einer Initiierung des virtuellen Restore des ersten Datenvolumens das erste Datenvolumen in eine Aufbewahrungskategorie kategorisiert wird, in der Datenvolumen über einen Zeitraum hinweg aufbewahrt werden, nachdem sie zur Löschung vorgesehen sind, das virtuelle Restore des ersten Datenvolumens von Daten, das in einem Speicher gespeichert ist, des Weiteren ein Neukategorisieren des ersten Datenvolumens in einer Rückstellungskategorie, in der eine Modifizierung von Datenvolumen verhindert wird, und des Weiteren als Reaktion auf einen Abschluss des Übertragens von Daten von dem ersten Datenvolumen auf das zweite Datenvolumen während des physischen Restore des ersten Datenvolumens ein Neukategorisieren des ersten Datenvolumens von der Rückstellungskategorie zurück in die Aufbewahrungskategorie aufweist, und wobei eine Modifizierung des ersten Datenvolumens durch das Restore des ersten Datenvolumens sowohl während des virtuellen Restore als auch während des physischen Restore des ersten Datenvolumens vermieden wird.
Computerprogrammprodukt nach Anspruch 1, wobei die Vorgänge des Weiteren ein Zuweisen zumindest einer Richtlinie zu dem zweiten Datenvolumen aufweisen, wobei die Richtlinie Parameter für einen Zeitraum, wie lange ein Datenvolumen zu behalten ist, und/oder für eine zulässige Anzahl von Versionen des Datenvolumens definiert.
Computerprogrammprodukt nach Anspruch 1, wobei die Vorgänge des Weiteren ein Importieren eines dritten Datenvolumens in den Speicher aufweist, das ein Durchführen eines virtuellen Restore des dritten Datenvolumens mithilfe eines vierten Datenvolumens aufweist, das eine Datenvolumen-Folgenummer aufweist, die einer Konvention zur Datenvolumen-Folgenummerierung des Speichers entspricht, wobei das virtuelle Restore des dritten Datenvolumens ein Konfigurieren von Metadaten aufweist, die dem vierten Datenvolumen zugehörig sind, um das vierte Datenvolumen dem dritten Datenvolumen als virtuelles Restore des dritten Datenvolumens zuzuordnen.
Computerprogrammprodukt nach Anspruch 1, wobei die Vorgänge des Weiteren aufweisen: Löschen des zweiten Datenvolumens; und Durchführen eines zweiten virtuellen Restore des ersten Datenvolumens mithilfe eines dritten Datenvolumens, das ein Konfigurieren von Metadaten aufweist, die dem dritten Datenvolumen zugehörig sind, um das dritte Datenvolumen dem ersten Datenvolumen als zweites virtuelles Restore des ersten Datenvolumens zuzuordnen, wobei das erste Datenvolumen im Verlauf des ersten und des zweiten virtuellen Restore des ersten Datenvolumens unveränderlich bleibt.
Computerprogrammprodukt nach Anspruch 1, wobei das erste Datenvolumen in einem Sekundärspeicher gespeichert wird, der mit einem Speicher-Server verbunden ist, der einen Primärspeicher aufweist, und wobei das erste Datenvolumen während des gesamten virtuellen Restore des ersten Datenvolumens in dem Sekundärspeicher ungeladen bleibt.
System zur Verwendung mit einem Host und zum Durchführen eines Restore an Datenvolumen von Daten, das aufweist: einen Speicher mit einer Mehrzahl von Datenvolumen von Daten; einen Prozessor; und ein durch einen Computer lesbares Speichermedium, das Programmanweisungen aufweist, die, wenn sie durch den Prozessor ausgeführt werden, Vorgänge bewirken, wobei die Vorgänge aufweisen: Durchführen eines ersten virtuellen Restore an einem ersten Datenvolumen für Daten, das in dem Speicher gespeichert ist, mithilfe eines zweiten Datenvolumens, das ein Konfigurieren von Metadaten aufweist, die dem zweiten Datenvolumen zugehörig sind, um das zweite Datenvolumen dem ersten Datenvolumen als virtuelles Restore des ersten Datenvolumens zuzuordnen; und als Reaktion auf eine Anforderung von Daten, die auf dem ersten Datenvolumen gespeichert sind, durch einen Host, Durchführen eines physischen Restore von Daten des ersten Datenvolumens mithilfe des zweiten Datenvolumens, das ein Übertragen von Daten auf das zweite Datenvolumen von dem ersten Datenvolumen aufweist, dem das zweite Datenvolumen durch das virtuelle Restore zugeordnet worden ist, und Neubenennen von übertragenen Daten in Daten des zweiten Datenvolumens anstelle von Daten des ersten Datenvolumens, so dass ein Zugreifen auf Daten des ersten Datenvolumens verzögert wird, bis ein Zugriff auf die Daten durch den Host angefordert wird, und wobei eine Modifizierung von Daten auf dem ersten Datenvolumen in Verbindung mit einem Restore des ersten Datenvolumens während eines virtuellen und physischen Restore des ersten Datenvolumens vermieden wird.
System nach Anspruch 11, wobei der Speicher ein Speicherlaufwerk aufweist und wobei das Übertragen von Daten auf das zweite Datenvolumen von dem ersten Datenvolumen als Reaktion auf ein Empfangen einer Anforderung durch den Host, das zweite Datenvolumen in ein Speicherlaufwerk zu laden, und als Reaktion auf die Anforderung aufweist: Laden des zweiten Datenvolumens in ein Speicherlaufwerk; Laden des ersten Datenvolumens in ein Speicherlaufwerk; und Kopieren von Daten des ersten Datenvolumens, das durch die Metadaten für das zweite Datenvolumen dem zweiten Datenvolumen zugeordnet worden ist, so, dass das Kopieren von Daten von dem ersten Datenvolumen in Verbindung mit dem Restore des ersten Datenvolumens mithilfe des zweiten Datenvolumens bis zu dem physischen Restore des zweiten Datenvolumens verzögert wird.
System nach Anspruch 12, wobei das Neubenennen von übertragenen Daten in Daten des zweiten Datenvolumens anstelle von Daten des ersten Datenvolumens ein Modifizieren von Header-Daten aufweist, die von dem ersten Datenvolumen gelesen werden, während Daten auf dem zweiten Datenvolumen gespeichert werden, um Daten, die von dem ersten Datenvolumen kopiert werden, als Daten für das zweite Datenvolumen statt für das erste Datenvolumen zu kennzeichnen, und so, dass ein Modifizieren von Header-Daten, die von dem ersten Datenvolumen gelesen werden, verzögert wird, bis ein Zugriff auf die Daten durch den Host angefordert wird.
System nach Anspruch 13, wobei das erste Datenvolumen eine erste Datenvolumen-Folgenummer aufweist und das zweite Datenvolumen eine zweite Folgenummer aufweist, die sich von der ersten Datenvolumen-Folgenummer unterscheidet, und wobei das Modifizieren von Header-Daten zum Speichern auf dem zweiten Datenvolumen während des physischen Restore des ersten Datenvolumens ein Austauschen der ersten Folgenummer des ersten Datenvolumens in Header-Daten gegen die zweite Datenvolumen-Folgenummer des zweiten Datenvolumens aufweist, während Header-Daten und Benutzerdaten von dem ersten Datenvolumen gelesen werden und gelesene Daten auf das zweite Datenvolumen kopiert werden.
System nach Anspruch 12, wobei die Vorgänge des Weiteren ein Kategorisieren des ersten Datenvolumens vor dem Laden des ersten Datenvolumens als schreibgeschützte Datenvolumen aufweist, um eine Modifizierung des ersten Datenvolumens durch das Restore des ersten Datenvolumens sowohl während des virtuellen Restore als auch während des physischen Restore des ersten Datenvolumens zu verhindern.
System nach Anspruch 11, wobei vor einer Initiierung des virtuellen Restore des ersten Datenvolumens das erste Datenvolumen in eine Aufbewahrungskategorie kategorisiert wird, in der Datenvolumen über einen Zeitraum hinweg aufbewahrt werden, nachdem sie zur Löschung vorgesehen sind, das virtuelle Restore des ersten Datenvolumens von Daten, das in einem Speicher gespeichert ist, des Weiteren ein Neukategorisieren des ersten Datenvolumens in einer Rückstellungskategorie, in der eine Modifizierung von Datenvolumen verhindert wird, und des Weiteren als Reaktion auf einen Abschluss des Übertragens von Daten von dem ersten Datenvolumen auf das zweite Datenvolumen während des physischen Restore des ersten Datenvolumens ein Neukategorisieren des ersten Datenvolumens von der Rückstellungskategorie zurück in die Aufbewahrungskategorie aufweist, und wobei eine Modifizierung des ersten Datenvolumens durch das Restore des ersten Datenvolumens sowohl während des virtuellen Restore als auch während des physischen Restore des ersten Datenvolumens vermieden wird.
System nach Anspruch 11, wobei die Vorgänge des Weiteren ein Zuweisen zumindest einer Richtlinie zu dem zweiten Datenvolumen aufweisen, wobei die Richtlinie Parameter für einen Zeitraum, wie lange ein Datenvolumen zu behalten ist, und/oder für eine zulässige Anzahl von Versionen des Datenvolumens definiert.
System nach Anspruch 11, wobei die Vorgänge des Weiteren ein Importieren eines dritten Datenvolumens in den Speicher aufweist, das ein Durchführen eines virtuellen Restore des dritten Datenvolumens mithilfe eines vierten Datenvolumens aufweist, das eine Datenvolumen-Folgenummer aufweist, die einer Konvention zur Datenvolumen-Folgenummerierung des Speichers entspricht, wobei das virtuelle Restore des dritten Datenvolumens ein Konfigurieren von Metadaten aufweist, die dem vierten Datenvolumen zugehörig sind, um das vierte Datenvolumen dem dritten Datenvolumen als virtuelles Restore des dritten Datenvolumens zuzuordnen.
System nach Anspruch 11, wobei die Vorgänge des Weiteren aufweisen: Löschen des zweiten Datenvolumens; und Durchführen eines zweiten virtuellen Restore des ersten Datenvolumens mithilfe eines dritten Datenvolumens, das ein Konfigurieren von Metadaten aufweist, die dem dritten Datenvolumen zugehörig sind, um das dritte Datenvolumen dem ersten Datenvolumen als zweites virtuelles Restore des ersten Datenvolumens zuzuordnen, wobei das erste Datenvolumen im Verlauf des ersten und des zweiten virtuellen Restore des ersten Datenvolumens unveränderlich bleibt.
System nach Anspruch 11, wobei der Speicher einen Speicher-Server aufweist, der einen Primärspeicher und einen Sekundärspeicher aufweist, und wobei das erste Datenvolumen in dem Sekundärspeicher gespeichert wird, und wobei das erste Datenvolumen während des gesamten virtuellen Restore des ersten Datenvolumens in dem Sekundärspeicher ungeladen bleibt.
Verfahren, das aufweist: Durchführen eines ersten virtuellen Restore an einem ersten Datenvolumen für Daten, das in einem Speicher gespeichert ist, mithilfe eines zweiten Datenvolumens, das ein Konfigurieren von Metadaten aufweist, die dem zweiten Datenvolumen zugehörig sind, um das zweite Datenvolumen dem ersten Datenvolumen als virtuelles Restore des ersten Datenvolumens zuzuordnen; und als Reaktion auf eine Anforderung von Daten, die auf dem ersten Datenvolumen gespeichert sind, durch einen Host, Durchführen eines physischen Restore von Daten des ersten Datenvolumens mithilfe des zweiten Datenvolumens, das ein Übertragen von Daten auf das zweite Datenvolumen von dem ersten Datenvolumen aufweist, dem das zweite Datenvolumen durch das virtuelle Restore zugeordnet worden ist, und Neubenennen von übertragenen Daten in Daten des zweiten Datenvolumens anstelle von Daten des ersten Datenvolumens, so dass ein Zugreifen auf Daten des ersten Datenvolumens verzögert wird, bis ein Zugriff auf die Daten durch den Host angefordert wird, und wobei eine Modifizierung von Daten auf dem ersten Datenvolumen in Verbindung mit einem Restore des ersten Datenvolumens während eines virtuellen und physischen Restore des ersten Datenvolumens vermieden wird.
Verfahren nach Anspruch 21, wobei das Übertragen von Daten auf das zweite Datenvolumen von dem ersten Datenvolumen als Reaktion auf ein Empfangen einer Anforderung durch den Host, das zweite Datenvolumen in ein Speicherlaufwerk zu laden, und als Reaktion auf die Anforderung aufweist: Laden des zweiten Datenvolumens in ein Speicherlaufwerk; Laden des ersten Datenvolumens in ein Speicherlaufwerk; und Kopieren von Daten des ersten Datenvolumens, das durch die Metadaten für das zweite Datenvolumen dem zweiten Datenvolumen zugeordnet worden ist, so, dass das Kopieren von Daten von dem ersten Datenvolumen in Verbindung mit dem Restore des ersten Datenvolumens mithilfe des zweiten Datenvolumens bis zu dem physischen Restore des zweiten Datenvolumens verzögert wird, wobei das erste Datenvolumen in einem Sekundärspeicher gespeichert wird, der mit einem Speicher-Server verbunden ist, der einen Primärspeicher aufweist, und wobei das erste Datenvolumen während des gesamten virtuellen Restore des ersten Datenvolumens in dem Sekundärspeicher ungeladen bleibt; wobei das Neubenennen von übertragenen Daten in Daten des zweiten Datenvolumens anstelle von Daten des ersten Datenvolumens ein Modifizieren von Header-Daten aufweist, die von dem ersten Datenvolumen gelesen werden, während Daten auf dem zweiten Datenvolumen gespeichert werden, um Daten, die von dem ersten Datenvolumen kopiert werden, als Daten für das zweite Datenvolumen statt für das erste Datenvolumen zu kennzeichnen, und so, dass ein Modifizieren von Header-Daten, die von dem ersten Datenvolumen gelesen werden, verzögert wird, bis ein Zugriff auf die Daten durch den Host angefordert wird; und wobei das erste Datenvolumen eine erste Datenvolumen-Folgenummer aufweist und das zweite Datenvolumen eine zweite Folgenummer aufweist, die sich von der ersten Datenvolumen-Folgenummer unterscheidet, und wobei das Modifizieren von Header-Daten zum Speichern auf dem zweiten Datenvolumen während des physischen Restore des ersten Datenvolumens ein Austauschen der ersten Folgenummer des ersten Datenvolumens in Header-Daten gegen die zweite Datenvolumen-Folgenummer des zweiten Datenvolumens aufweist, während Header-Daten und Benutzerdaten von dem ersten Datenvolumen gelesen werden und gelesene Daten auf das zweite Datenvolumen kopiert werden.
Verfahren nach Anspruch 22, das des Weiteren ein Kategorisieren des ersten Datenvolumens vor dem Laden des ersten Datenvolumens als schreibgeschütztes Datenvolumen aufweist, um eine Modifizierung des ersten Datenvolumens durch das Restore des ersten Datenvolumens sowohl während des virtuellen Restore als auch während des physischen Restore des ersten Datenvolumens zu verhindern; wobei vor einer Initiierung des virtuellen Restore des ersten Datenvolumens das erste Datenvolumen in eine Aufbewahrungskategorie kategorisiert wird, in der Datenvolumen über einen Zeitraum hinweg aufbewahrt werden, nachdem sie zur Löschung vorgesehen sind, das virtuelle Restore des ersten Datenvolumens von Daten, das in einem Speicher gespeichert ist, des Weiteren ein Neukategorisieren des ersten Datenvolumens in einer Rückstellungskategorie, in der eine Modifizierung von Datenvolumen verhindert wird, und des Weiteren als Reaktion auf einen Abschluss des Übertragens von Daten von dem ersten Datenvolumen auf das zweite Datenvolumen während des physischen Restore des ersten Datenvolumens ein Neukategorisieren des ersten Datenvolumens von der Rückstellungskategorie zurück in die Aufbewahrungskategorie aufweist, und wobei eine Modifizierung des ersten Datenvolumens durch das Restore des ersten Datenvolumens sowohl während des virtuellen Restore als auch während des physischen Restore des ersten Datenvolumens vermieden wird; und wobei das Verfahren des Weiteren ein Zuweisen zumindest einer Richtlinie zu dem zweiten Datenvolumen aufweist, wobei die Richtlinie Parameter für einen Zeitraum, wie lange ein Datenvolumen zu behalten ist, und/oder für eine zulässige Anzahl von Versionen des Datenvolumens definiert.
Verfahren nach Anspruch 21, das des Weiteren ein Importieren eines dritten Datenvolumens in den Speicher aufweist, das ein Durchführen eines virtuellen Restore des dritten Datenvolumens mithilfe eines vierten Datenvolumens aufweist, das eine Datenvolumen-Folgenummer aufweist, die einer Konvention zur Datenvolumen-Folgenummerierung des Speichers entspricht, wobei das virtuelle Restore des dritten Datenvolumens ein Konfigurieren von Metadaten aufweist, die dem vierten Datenvolumen zugehörig sind, um das vierte Datenvolumen dem dritten Datenvolumen als virtuelles Restore des dritten Datenvolumens zuzuordnen.
Verfahren nach Anspruch 21, das des Weiteren aufweist: Löschen des zweiten Datenvolumens; und Durchführen eines zweiten virtuellen Restore des ersten Datenvolumens mithilfe eines dritten Datenvolumens, das ein Konfigurieren von Metadaten aufweist, die dem dritten Datenvolumen zugehörig sind, um das dritte Datenvolumen dem ersten Datenvolumen als zweites virtuelles Restore des ersten Datenvolumens zuzuordnen, wobei das erste Datenvolumen im Verlauf des ersten und des zweiten virtuellen Restore des ersten Datenvolumens unveränderlich bleibt.