Im Rahmen eines Kunden Projektes konnte ich in dieser Woche eines der neuen Features der NetWorker Version 8.2.1 am produktiven System zum Einsatz bringen und ich kann nur sagen, darauf haben wir schon LANGE gewartet.

Worum geht es?

Bis zur Version 8.2.0 war eine NetWorker-Server-Migration (Umtausch der Hardware) offiziell nur unter der Beibehaltung des Server-Namens möglich. Diese Einschränkung ist nun durch das neue Kommando nsrclientfix  Geschichte.

Worin bestand das Problem wenn der Server-Name verändert wurde?

Wenn der NetWorker-Server auf einen anderen Maschinen-Namen migriert wurde, verlor der 'neue' NetWorker-Server seine Beziehungen zu den Index- und Bootstrap-Sicherungen. Diese stehen schließlich als Sicherungen des 'alten' Server-Namens in der Mediendatenbank. Das ist für den alltäglichen Betrieb zunächst mal kein Problem. Möchte man aber einen 'alten' Index wiederherstellen, um nicht mehr browse-bare Dateien im Index wieder sichtbar zu machen, sieht die Sache leider ganz anders aus. War also die Browse-Zeit einer Sicherungen abgelaufen, blieb nur das Einscannen der betreffenden Sicherungs-SaveSets. Leider ist dies aber nur für 'normale' Filesystem-Sicherungen möglich. Indexeinträge für NDMP-Sicherungen können nicht mit Hilfe des scanner Kommandos wiederhergestellt werden.  Indexeinträge von NDMP-Sicherungen konnten somit nachträglich weder mit den Kommandos nsrck, noch mit dem scanner Kommando wiederhergestellt werden. Es gibt zwar auch für dieses Problem eine Lösung (scanner | uasm mit anschließendem nsrck -L 6), diese ist allerdings etwas zeitaufwendig und mühsam.

Die Lösung des Problems!

Durch das neue Kommando nsrclientfix kann man jetzt (V8.2.1) nach einer erfolgten Server-Migration die Client-Zugehörigkeit der 'alten' Index-Sicherungen dem 'neuen' NetWorker-Server übergeben. Nach einem erfolgreichen Einsatz des Kommandos findet man die 'alten' Index-Sicherungen in der Mediendatenbank unter dem Clientnamen des neuen NetWorker-Servers wieder. Anschließend steht einem "nsrck -L 7" aller Clients (inklusive NDMP-Clients) nichts mehr im Wege. Somit können ab sofort auch die Browse-Zeiten der NDMP-Sicherungen auf einen erträglichen Zeitraum reduziert werden. Übergroße NDMP-Client-Indices sollten somit der Vergangenheit angehören.

Möchten sie mehr zu dem Thema NetWorker-Server-Migration wissen, dann besuchen sie einfach unseren NetWorker Admin 3 Workshop oder kontaktieren sie mich direkt.

Die ersten beiden Migrationen einer FlexFrame 4 SAP (FF4SAP) Sicherungsumgebung konnten von uns noch vor Weihnachten erfolgreich umgesetzt werden.

Hintergrund:

Kunden, die bisher eine auf Fujitsu-NetWorker und der Fujitsu-eigenen Sicherungslösung NSRORA-NDMP basierte NetApp-Snapshot-Sicherung einsetzen, haben seit der Abkündigung der Fujitsu-NetWorker OEM-Version das Problem, dass der Support für diese elegante und hochperformante Backup-Lösung abläuft, bzw. abgelaufen ist.

Die auf NetApp-Snapshots basierende Sicherungslösung ermöglichte es, Oracle-Datenbanken in wenigen Minuten zu sichern und im allgemeinen auch in wenigen Minuten wiederherzustellen! Wenn benötigt können NDMP basierte Band-Sicherungen dieser Snapshots erstellt werden. Des weiteren sorgte NSRORA-NDMP mit Hilfe des Dämonen AMON für die Überwachung, die Sicherung und das Löschen der archivierten Oracle-Logs. Ein besonderes Highlight von NSRORA-NDMP bestand in der Möglichkeit einer vollautomatisierten Wiederherstellung einer Datenbank.

All diese lieb gewonnen Vorteile werden durch unsere Sicherungslösung SB-INT-O ebenfalls erfüllt. Zusätzlich erhält der Administrator jedoch noch weitere durchaus erwähnenswerte Vorteile. Hier eine stichwortartige Auflistung:

• Integration der NetApp eigenen SnapVault Sicherungstechnik. Hierdurch wird eine weitere Sicherungseinheit ermöglicht, die folgende Vorteile liefert.

  • Backup To Disk To Tape. Nur die seit dem letzten Backup veränderten Blöcke werden vom primären Storage-System auf ein sekundäres (Nearstore) Storage-System kopiert. Erst dort wird bei Bedarf ein vollständiges (Tape-)Backup durchgeführt. Dies entlastet das primäre System vom NDMP-Backup. 

  • Das SnapVault-Backup kann auf dem sekundären System,  auf preiswerterem Platten, länger für Wiederherstellungszwecke vorgehalten werden. 

  • Auf dem sekundären Storage kann auf Basis der Backup-Snapshots und der NetApp-FlexClone Technik schnell und automatisiert eine Test- oder Recover-Datenbank erstellt werden. 

  • Schnelles Wiederherstellen einer Datenbank auf Basis der SnapVault Snapshots. Auch die auf dem sekundären Storage vorliegenden Snapshots werden von dem vollautomatisierten Datenbank-Recover für Wiederherstellungen berücksichtigt. Hierdurch wird ein Recover der nicht mehr auf die Snapshots des primären Storage-Systems zurückgreifen kann wesentlich beschleunigt. Denn statt die ganze Datenbank von Band wieder einspielen zu müssen, genügt es die seit dem gewünschten Zeitpunkt veränderten Blöcke vom sekundären auf den primären Storage zu übertragen. Auch diese Art der Wiederherstellung wird natürlich vollautomatisiert von SB-Int-O durchgeführt.

• Schnelleres Recover der archivierten Oracle-Logs.
  Das Backup der archivierten Logs wird über einen sekundären Speicherbereich organisiert. Auf diesem, im Normalfall auf günstigeren Nearstore-Platten basiertem Storage, können die Logs länger für Recovery-Zwecke vorgehalten werden. Sie stehen somit sofort für die Wiederherstellung der Datenbank zur Verfügung. Der voll-automatisierte Wiederherstellungsvorgang von SB-INT-O mountet diesen Bereich wenn nötig in den Archivelog-Bereich der Datenbank. Man benötigt somit in den meisten Fällen weder ein NetWorker-Recover noch einen Kopiervorgang für die Bereitstellung der notwendigen Logs.

• Erhöhte Sicherheitsunterstützung!
  Musste für NSRORA-NDMP jede Datenbankmaschine ssh-Rechte als Benutzer "root" erhalten, genügt es für SB-Int-O definierte NetApp-Benutzer einzurichten, die lediglich die benötigten Kommandos mittels NetApp-API verwenden können. Diese Art der Komunikation ist somit wesentlich sicherer und zudem weniger fehleranfällig.

• Unterstützung von DMZ und V-Filer Umgebungen.
  In einer auf V-Filern basierten DMZ-Umgebung wird keine NDMP-Sicherung unterstützt. SB-Int-O ermöglicht es auch in dieser Umgebung über den Einsatz von SnapVault und einen Nearstore-Filer eine Bandsicherung zu erstellen.

• WWW basiertes zusätzliches Überwachungs- und Konfigurations-Interface.
  Für viele Kunden von SB-Int das Highlight der Lösung! Ermöglicht es doch

  • den Datenbank-Administratoren:

    • jederzeit einen schnellen Blick auf alle zur Verfügung stehenden Sicherungsstände

    • die Möglichkeit, schnell mal eine Snapshot-Sicherung ihrer Datenbank zu starten

    • zu kontrollieren, welche archivierten Logs der jeweiligen Datenbank noch zur Verfügung stehen.

    und das alles ohne das diese hierfür NetWorker Rechte benötigen.

  • den NetWorker Administratoren:

    • einen schnellen Überblick über den Erfolg oder Misserfolg aller Datenbanksicherungen.

    • den Zugriff auf alle SB-Int Konfigurationen.

    • die Überwachung aller Snapshots auf den primären und sekundären Storage-Systemen.

    • den leichten Zugriff auf alle Sicherungsprotokolle.

  Das WWW-GUI besitzt eine eigene Benutzer Verwaltung, in der jedem Benutzer eigene Rechte bis hinunter zur Datebank-Ebene zugewiesen werden können.

  Wie Sie lesen konnten gibt es für die "alte" Sicherungslösung NSRORA-NDMP nicht nur einen adäquaten Ersatz, sondern Sie erhalten mit unserer Backup-Lösung SB-Int-O eine im allgemeinen nochmals schnellere Recover-Lösung, sowie weitere vielfältige Möglichkeiten.

  Für Fragen oder einen persönlichen Vorführungstermin wenden Sie sich bitte an

  Uwe W. Schäfer

Im letzten Herbst habe ich bereits eine Lösung für das Problem, "werden alle NetApp Volumes auch vom NetWorker gesichert" vorgestellt. Die Überwachung der gesicherten NetApp Volumes wurde anhand von einem Python Script mit unserer eignenen NetApp API durchgeführt und läuft seit dem sehr erfolgreich bei unseren Kunden. Jetzt kam eine neue Herausforderung hinzu!

Ein weiterer Kunde sichert die NetApp Volumes nicht als komplette Volumes, sondern unterteilt diese in mehrere Sicherungen, von NetApp-Qtrees bzw zum Teil auch in Sicherungen von Unterverzeichnissen mehrere Stufen unterhalb des Volume Namens. Natürlich sollte sicher gestellt sein, dass alle Unterverzeichnisse eines Volumes gesichert werden. Es kommt aber leider immer mal wieder vor, dass andere Abteilungen, neue parallele Verzeichnisse zu den bestehenden aufbauen ohne an die Datensicherung zu denken. Dies passiert zum einen, weil mehrere Abteilungen über verschieden Standorte verteilt an der Administration des Storage beteilgt sind. So kann zum Beispiel die Windows-Abteilung in Ihrem Volume selbstverständlich neue Freigaben generieren und hierfür auch neue Verzeichnisse anlegen.

Hier ein kleines Beispiel um das Thema etwas griffiger zu gestalten:

Das Volume /vol/sv_filer3_bauplaene enthält zurzeit 5 TB zu sichernde Daten. Diese Daten verteilen sich in folgende Verzeichisse:
        /vol/sv_filer3_bauplaene/MUC
        /vol/sv_filer3_bauplaene/FRA
        /vol/sv_filer3_bauplaene/HAM
        /vol/sv_filer3_bauplaene/KOB
        /vol/sv_filer3_bauplaene/DUS
        /vol/sv_filer3_bauplaene/KOL
        /vol/sv_filer3_bauplaene/BRE
        /vol/sv_filer3_bauplaene/PDB
        /vol/sv_filer3_bauplaene/KA

Alle Verzeichnisse sind in 3 NetWorker Client Ressourcen eingetragen. Der Vorteil hierbei liegt auf der Hand: Die Vollsicherung des Volumes kann an 3 unterschiedlichen Tagen stattfinden und bei auftretenden Problemen kann gezielt ein SaveSet der Sicherung nachgefahren werden.
       
Die Windows Abteilung generiert das neue Verzeichis "/vol/sv_filer3_bauplaene/STG" vergisst aber leider dies den NetWorker Administratoren mitzuteilen. Nach "n" Wochen möchte ein Entwickler einen 3 Wochen alten Plan aus der Unterverzeichnis "STG" wiederhergestellt haben. Dumm gelaufen.

Um genau dieses Problem nicht entstehen zu lassen, haben wir unser kleines Überwachungstool so erweitert, dass jetzt auch beliebig tiefe Unterverzeichnisstrukturen analysiert werden. Im obigen Fall würde nach dem Generieren des Verzeichnisses am folgenden Morgen eine Mail an den Backup-Administrator gesendet, in der er mitgeteilt bekommt, dass das Verzeichnis "STG" nicht in der Sicherung enthalten ist.

Das Tool ermittelt zunächst für den angegebenen Filer alle im NetWorker enthaltenen SaveSets und generiert daraus eine Liste der Verzeichisse und Volumes, die untersucht werden müssen. Hierauf wird am Filer eine Auflistung der Verzeichnisse und Volumes angefordert. Die gesammelten Daten werden im Anschluß gegen die bereits bekannte "Whitelist" verglichen und alle nicht bekannten Volumes und "parallel Verzeichnisse" werden den NetWorker Administratoren gemailt.

Hier ein Beispiel für den Aufruf eines Überwachungslaufs:

================================================================================
        not saved Volumes und Subdirectorys for NetApp Filer: nafiler3
        check WIKI entry: http://ciwi/s_t_wiki/index.php5/Check_Volume_Backup
================================================================================

db_oaiacc
db_oaidev

/vol/sv_filer3_bauplaene/STG

Die beiden Volumes "db_oaiacc" und "db_oaidev" gehören in die WhiteListe der SaveSets. "/vol/sv_filer3_bauplaene/STG" sollte in die NetWorker Konfiguration aufgenommen werden.

Der Kunde wollte seine NetApp NDMP Sicherungen von einem "alten" NetWorker Server auf einen neuen bereits aktiven NetWorker Server migrieren. Folglich sollten alle Bänder (600 an der Anzahl) im neuen NetWorker Server bekannt gemacht werden.

Da es ja keine Fleißaufgabe werden sollte und sich kein vernünftiger Mensch freiwillig vor den Bildschirm setzt um 600 Bänder für das Einlesen der Bänder zu wechseln, sollte das ganze per Skript gelöst werden. An sich ja alles nicht so schwierig, aber der Teufel lag mal wieder im Detail!

Hier die Idee:

1. Export der Medien
2. Import der Medien
3. Sortieren der Barcodes nach dem Sicherungsdatum
   • mminfo -av -ot -p <pool> -r barcode
4. Entfernen der recyclebaren Medien
5. Scanner Script dass Band für Band abarbeitet

•  Laden des Mediums
•         disablen des Laufwerks
•         scanner -m <device>
•  Eine Schleife über alle restlichen Bänder
  •      Warten bis der scanner sagt, er will das nächste Band
  •      Enablen des Laufwerks
  •      umount des Bandes
  •      Mount des nächsten Bandes
  •      disabeln des Bandes
  •      Scanner mitteilen, das nächste Band ist bereit

Soweit die Idee, nur leider spielte das Scanner Kommando nicht mit :-(

• Ein "Scanner -z" hat für NDMP leider einen bereits bekannten BUG.

• Die Abfrage nach dem nächsten Band läßt sich  nicht automatisieren.

Nachdem auch kein Googlen und Trussen weiterhilft, konnte eine Anfrage an die FTS-Entwicklung doch noch Abhilfe schaffen! FTS kannte das Problem bereits und hatte für einen ähnlichen Fall einen Scanner entwickelt, der eine Nachfrage nach dem nächsten Band mittels einer Datei ermöglicht. Mit diesem Spezial-Scanner konnte das oben skizierte Skript doch noch zum Einsatz kommen.

Jetzt fehlte nur noch der Aufbau der alten Index-Einträge sowie die Anpassung der Rention-Zeiten und die Migration war geschafft!