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!