Wie Sie Ihre alten Tapes zu einer neuen Backup-Lösung migrieren - Commvault, Tivoli Storage Manager

Mittwoch, 8. Februar 2017 von Michael Nuncic

Die Grundlagen der Bandmigration und die Fragen, die dabei entstehen

Tape als Archiv- und Datenspeichermedium gibt es schon seit 60 Jahren und es ist in Firmen aller Größen immer noch weit verbreitet. Die Vorteile: Langlebigkeit und niedrige Kosten. Im Vergleich zu anderen Medien ist das auch die Kehrseite. Im Laufe der Jahre haben viele Benutzer viele verschiedene Band-Formate sowie verschiedene Tape Backup-Lösungen wie Commvault, IBM Tivoli Storage Manager (TSM), NetBackup oder andere angesammelt. In vielen - wenn nicht in den meisten - Fällen stehen Unternehmen vor dem Problem, dass sie aufgrund von regulatorischen oder Compliance-Gründen Zugang zu vielen alten Legacy-Bändern verschiedener Anbieter haben müssen.

Unternehmen, die eine Menge dieser Legacy-Bänder lagern, müssen die Funktionalität der Bänder sowie die notwendige Hardware- und Backup-Software aufrechterhalten. (Zusätzlich müssen sie Lizenzen für alle Backup-Lösungen bezahlen, die sie noch funktionsfähig halten). Aus diesem Grund versuchen viele Unternehmen, ihre verschiedenen Backup-Lösungen zu einem einzigen Anbieter zu konsolidieren. Zusätzlich sollte das verwendete Tape- (Media-) Format gleich sein. Dieser Job ist eine von drei verschiedenen Aufgaben im Zusammenhang mit "Migration" und ist nicht so einfach, wie man zunächst denken könnte. Bevor ein Administrator anfangen kann, muss er vorausplanen und prüfen: Haben die Bänder dasselbe Format? Haben alle von ihnen die gleiche Backup-Lösung? Sind die Bänder und die Hardware noch funktionsfähig?

Nimmt man an, dass alle Bänder das gleiche Format (LTO2, DST etc.) und die gleiche Funktionalität haben, sind mehrere Probleme nicht vorhanden und Sie können weiter voranschreiten. Andernfalls müssen die Bänder überprüft oder gar repariert werden, um auf die Altdaten zugreifen zu können. Normalerweise sollte das Unternehmen die notwendige Hardware noch zur Verfügung haben, um die verschiedenen Bänder auslesen zu können.

Eine Frage bleibt aber noch: Wenn die Bandsicherungslösung zu einem anderen - in diesem Fall von Commvault zu einem anderen oder von einem anderen Produkt nach Commvault - gewechselt wird, werden die Daten wieder auf Band gespeichert oder sollten diese auf (preisgünstige) Festplatten gespeichert und geändert werden? In dem Fall, dass das End-Medium weiterhin Tape ist, sollte die Entscheidung getroffen werden, in welchem Format die Daten schließlich gespeichert werden sollen? In diesem Fall ist es sinnvoll, die gängigste und neueste Bandversion die es auf dem Markt gibt zu nehmen: Zurzeit ist das LTO7. Das Szenario wäre so: Holen Sie sich alle Tape-Backup-Daten von den alten Bändern, konsolidieren Sie die Sicherungsdaten und migrieren Sie die Sicherungsdaten vom alten Backupprodukt nach Commvault oder von Commvault zum neuen Produkt. Und schließlich speichern Sie das "neue" Legacy-Backup wieder auf Band - im neuen Tape-Format. Wenn ein solches Projekt schließlich fertig geworden ist, ist das Endergebnis eine einzigartige bandbasierte Backup-Lösung und Bänder die alle in einem einzigen Format vorliegen. In diesem Fall können Legacy-Backup-Anwendungen, die dann nicht mehr benötigt werden und im Einsatz sind, für immer „in Rente gehen“. Durch die Abschaltung dieser veralteten Lösungen können die Infrastrukturkosten gesenkt und auf deren Wartung komplett verzichtet werden.

Wie funktioniert eine Commavault-Backup-Migration?

Die Migration von Daten aus einer vorhandenen Commvault-Sicherungslösung auf ein anderes System geschieht normalerweise auf traditionelle Weise: Sie müssen auf das Commvault-System zugreifen und eine vollständige Sicherung erstellen und alle Daten, die in der verwalteten Bandbibliothek gespeichert sind, abrufen. Wenn Sie alle Daten und Archive auf unterschiedlichen Speicherplätzen (normalerweise auf Festplatten aus Ihrem lokalen SAN / NAS) wiederhergestellt haben, müssen Sie das neue Backup-System (Hardware und Backup-Software) von Grund auf neu anlegen, die Archivstruktur erstellen und die Daten in das neue Backup-System importieren. Zusätzlich müssen alle benötigten Mandanten, Richtlinien und Zeitpläne sowie Bandvorräte und Kataloge generiert werden. Wenn Sie in Erwägung ziehen, zu einem neuen System zu wechseln, bieten einige Hardware- und Back-up-Lösungsanbieter spezielle Migrationsdienste an, die in einigen Fällen zu einem erheblichen Teil der gesamten Migrationskosten führen können.

Die häufigste Lösung für eine Migration Ihrer Backups von Commvault - sei es eines der älteren Softwarepakete oder das neue Simpana-Release - besteht darin, Ihre vorhandenen CommVault-Dateien zu verwenden, um Ihre Daten auf einem neuen Storage wiederherzustellen und mit TSM, NetBackup oder NetWorker erneut zu sichern. Auch wenn es einige Softwarelösungen auf dem Markt gibt, die die Commvault-Einstellungen und -Strukturen sowie die Backup-Daten selbst zu TSM, NetWorker oder NetBackup "übersetzen" sollen, ist dies eine zeitaufwendige und teure Angelegenheit. Und wenn der Prozess bei der Verwendung eines dieser Software-Tools scheitert, ist es möglich, wertvolle Daten oder Commvault-Einstellungen zu beschädigen oder gar zu verlieren. Darüber hinaus verwendet Commvault wie alle anderen Backup-Software-Lösungen spezielle Datenformate, die die im Backup gespeicherten Daten komprimieren. Wenn die Datenstruktur zerstört wird, ist es eine schwierige Aufgabe, die Backupstruktur sowie die Daten wiederherzustellen. Diese Aufgabe gleicht dann dem Finden einer Nadel in einem Heuhaufen.

Die Migration von Daten aus einem anderen Produkt wie einer aktuellen Tivoli TSM-, NetBackup- oder NetWorker-Sicherungslösung zu einer Commvault-Backuplösung ist ein wenig einfacher: Mit seinem External Data Connector ermöglicht Commvault zukünftigen oder neuen Clients der aktuellen Simpana-Backup-Software, nicht nur die in einem Backup gespeicherten Daten zu importieren, sondern auch Details über die aktuelle TSM-, NetBackup- oder NetWorker-Speicherstruktur wie Client-Informationen, Job-Informationen und das Magnetband-Inventar. Mit diesen Informationen können IT-Profis dann die alten Clients in Simpana-Clients übersetzen, die Client-Hardware bereitstellen und die definierten Richtlinien aus dem alten TSM-, NetBackup- oder NetWorker-System vererben. Aber in einem unwahrscheinlichen Fall, dass eine Migration aufgrund von Hardware- oder Softwarefehlern nicht funktioniert, können Probleme auftreten, die selbst der talentierteste IT-Administrator nicht selbst lösen kann. Eine abgebrochene Bandbibliothek-Verknüpfung oder kaputte Bandkatalogdateien machen es sogar für Experten schwer, die ursprüngliche Struktur des gesamten Sicherungssystems und der angeschlossenen Bandbibliothek wiederherzustellen. Wenn eine Migration von TSM, NetBackup oder NetWorker Backup zu Commvault mittendrin stoppt, geraten Sie in große Schwierigkeiten. Nur Datenrettungsexperten wie Kroll Ontrack können dann in den meisten Fällen Daten, die während des ausgefallenen Prozesses verloren gehen, wiederherstellen und die Migration erfolgreich abschließen.

Schlussfolgerung:

Wie Sie sehen können, gibt es kein "typisches" Commvault-Migrationsprojekt. Und es ist höchstwahrscheinlich eine zeitraubende und kostspielige Aufgabe. Dabei sollte die Entscheidung für ein solches Projekt auf der Annahme beruhen, dass die Altdaten auch zukünftig auf Bändern gespeichert werden müssen. In einigen Fällen ist es durch regulatorische oder gesetzliche Anforderungen erforderlich, aber in vielen Fällen ist eine voll funktionsfähige Band-Backup-Lösung zusammen mit der benötigten Hardware nicht nötig! Auf diesen Punkt kommen wir noch einmal im zweiten Teil dieses Artikels zurück.

Wie funktioniert typischerweise eine Tivoli Storage Manager (TSM) Backup-Migration?

Um die Migration von TSM zu einem anderen Bandsicherungsprodukt so reibungslos wie möglich zu gestalten, müssen Sie mehrere Aspekte berücksichtigen: Zuerst müssen Sie Ihre spezifischen Daten aus Ihrem aktuellen Backup auf einen anderen Speicherplatz „entpacken“, um Zugriff darauf zu erhalten. Dazu verwenden Sie die von TSM bereitgestellten Werkzeuge. Wenn Sie nur die ursprünglichen Daten benötigen, extrahieren und exportieren Sie diese einfach aus TSM. Wenn Sie die gesamte Bibliothek und die Metadaten mit den gespeicherten Daten in das neue System importieren wollen, werden Sie schwerwiegende Probleme haben, da es keine Produkte auf dem Markt gibt, die die TSM-Metadaten in ein neues System kopieren. Hoffentlich sind Ihre Bänder nicht beschädigt oder enthalten beschädigte Daten, wenn die einzige Sicherung auf diesem Band gespeichert ist. Und das ist nur die üblichenDinge, die Sie normalerweise beachten müssen. Aber in einigen Migrationsprojekten muss noch weit mehr mögliche Probleme berücksichtigen:

Eine schwierige Aufgabe ist eine Migration von TSM zu NetWorker. Das liegt daran, dass mehrere Vorsichtsmaßnahmen zu berücksichtigen sind: Da TSM die größere Lösung ist und Daten auf andere Weise sichert, gibt es keine interne oder externe Software, die Ihnen bei der Migration helfen kann. Sie müssen eine Sicherungskopie oder ein Backup erstellen und die Daten mit der Wiederherstellungsfunktion extrahieren. Außerdem müssen Sie den Inhalt in die NetWorker Lösung importieren. Darüber hinaus müssen Sie die NetWorker-Softwarearchitektur für Ihre speziellen Umgebungs- und Sicherungsaufgaben von Grund auf neu erstellen, da TSM Daten von ihren Knoten in die Speichergruppen sichert und dann die Daten auf das Band migriert, während NetWorker die Daten nur in den Knoten speichert. Außerdem kann NetWorker Daten auch direkt auf Band speichern, während TSM auch seine Daten zuerst auf dem Server-Speicher speichert und später dann in die Bandbibliothek überträgt. Dies alles muss berücksichtigt werden, wenn Sie das neue NetWorker Architekturdesign einrichten, Richtlinien festlegen und Backup-Jobs planen, was auch keine leichte, sondern eine zeitaufwändige Aufgabe ist.

Die Migration von Backups aus einer anderen Backup-Lösung nach TSM ist auch keine leichte Aufgabe und kann Ihnen schlaflose Nächte bereiten. Die häufigste Lösung für die Migration Ihrer Backups von z.B. einem Commvault-Produkt - sei es eines der älteren Softwarepakete oder das neue Simpana-Release - ist es, Ihre vorhandenen Commvault-Dateien zu verwenden, um Ihre Daten an einem neuen Storage-Ort wiederherzustellen und mit TSM erneut zu sichern. Obwohl es einige Software-Lösungen auf dem Markt gibt, die zum Beispiel die Übersetzung von "Commvault-Metadaten" an TSM anbieten, ist dies eine zeitaufwendige und kostspielige Angelegenheit. Und wenn der Prozess bei der Verwendung eines dieser Software-Tools scheitert, ist es möglich, wertvolle Daten oder Commvault-Einstellungen zu beschädigen oder zu verlieren. Zusätzlich nutzt Commvault wie alle anderen Backup-Software-Lösungen spezielle Datenformate, die die Daten komprimieren. Wenn die Datenstruktur zerstört wird, ist es eine schwierige Aufgabe, die Sicherungsstruktur sowie die Daten wiederherzustellen. Es ist wie das Finden einer Nadel in einem Heuhaufen. Und wenn Sie während dieses Vorgangs einen Datenverlust erleiden, können Sie die Migration nach TSM von Anfang an neu starten.

In beiden Fällen - entweder beim Migrieren von oder nach TSM - müssen viele Überlegungen berücksichtigt werden, und die Mitarbeiter, die für dieses Projekt verantwortlich sind, müssen genau wissen, welche Produkte und welche Tricks und Workarounds für eine Migration im Detail benötigt werden. In den meisten Fällen werden Sie diese Art von Experten in Ihrem Unternehmen nicht finden.

Für ein solches Migrationsprojekt ist es ratsam, sich von den Experten von Kroll Ontrack beraten zu lassen. Für den Fall, dass Ihr Migrationsprojekt zeitkritisch ist, können die Experten von Kroll Ontrack Ihnen dabei behilflich sein, die Daten aus dem TSM herauszuholen, die Bandkatalog- und Bibliothekslisten zu durchsuchen und auszulesen, nur die wichtigen Daten zu extrahieren sowie andere Band- und Migrationsdienste durchzuführen.

Darüber hinaus, wenn aus irgendeinem Grund ein Migrationsprozess nicht ordnungsgemäß funktionierte, können Sie auch die Daten, die während des Prozesses verloren gegangen waren, wiederherstellen. Mit ihren standardisierten Verfahren und Erfahrungen machen die Experten von Kroll Ontrack ein solches Migrationsprojekt nicht nur störungsfrei, sondern auch zeit- und kosteneffektiv.

Wie wird man alte Legacy-Backup-Lösungen los, während man immer noch in der Lage ist auf die Daten zugreifen?

Wie Sie sehen können, ist ein Migrationsprojekt keine leichte Aufgabe. Warum ist es also notwendig, auf eine neuere Backup-Lösung zu wechseln oder zu konsolidieren? In vielen Fällen ist das nicht notwendig. Oft ist es für Unternehmen ausreichend, einen Überblick über den Inhalt der Bänder zu erhalten und dann eine Wiederherstellung nach Bedarf / Datenwiederherstellung durchzuführen, wenn Dateien wirklich benötigt werden, z.B. bei einer intenren Untersuchung oder ähnlichen Situationen. Vor allem, wenn Sie eine große Menge an Bändern in Ihren Archiven haben, aber nicht mehr die entsprechende Hardware, Backup-Software oder die Ausrüstung besitzen, Bänder und Backup-Lösungen alt werden und Treiber, Teile oder Updates schwer zu bekommen sind. In diesen Fällen ist es oft sinnvoller, "nur" vorzukatalogisieren, die vorhandenen Bänder zu indizieren und Dateien nur dann wiederherzustellen, wenn es notwendig ist. Hier macht es einfach keinen Sinn mehr, eine voll funktionsfähige Backup-Lösung am Laufen zu halten. Allerdings müssen die Katalogdateien sicher gespeichert werden und immer wieder mal überprüft werden, dass man auf sie zugreifen kann.

Tape Migration

Ontrack Datenrettungsblog

Das sagen unsere Kunden: