Ältere Meldungen zu den Patches werden nach unten verschoben.

Update 2012/06/22: HP hat für DP 6.21 am 07.06.2012 und 22.06.2012 neue Patches herausgegeben, das Patch Bundle DPXXXBDL_00621 ist aber Voraussetzung zur Installation der Patches. Wie immer gilt: Reihenfolge beachten und die Patch Beschreibung anschauen.

Update 2012/05/16: HP hat für DP 6.21 am 03.05.2012, 10.05.2012 und 16.05.2012 neue Patches herausgegeben, das Patch Bundle DPXXXBDL_00621 ist aber Voraussetzung zur Installation der Patches. Wie immer gilt: Reihenfolge beachten und die Patch Beschreibung anschauen.

Update 2012/03/22: HP hat das Patchbundle für DP 6.21 doch nicht in einer neuen Version herausgegeben, es wurde lediglich das Datum verändert, was schon einige Konfusion verursacht hat, Support konnte hier Aufklärung betreiben. Sorry für die nicht ganz vollständige Information vom letzten Update. Somit werden die bekannten Patches benötigt. Das Multipath Problem wird unter SSPNT620_008, für andere Themen gibt es auch Hotfixes und Site Specific Patches

Update 2012/02/24: Am 24.02.2012 hat HP das Patchbundle für DP 6.21 in einer neuen Version herausgegeben, die behobenen Probleme finden sich in der Patchbeschreibung.

In früheren Beitragen ist dokumentiert wie man einen Server mit der Enhanced Automated Disaster Recovery Option wiederherstellen kann. Dies betrifft auch generell den Cell Server, da dies der wichtigste Server bei einem Disaster ist. Auch für den Cell Server gibt es verschiedene Möglichkeiten ihn schnell wiederherstellen zu können. Die nachfolgenden Schritte gelten prinzipiell für Cell Server unter allen Betriebssystemen und stellen nur 1 Variante von verschiedenen Möglichkeiten dar.

Eine wichtige Information für die Wiederherstellung eines Cell Servers ist zu wissen auf welchem Band liegt die Sicherung der internen Datenbank. Mit 2 kleinen Einstellungen kann man sicherstellen dass diese Information zukünftig vorliegt und an einer zentralen Stelle abgelegt werden kann. Zunächst ist in der Datei rdmserver.ini der Parameter archiving=1 zu setzen. Dies veranlasst Data Protector die Information zur Sicherung der internen Datenbank zusätzlich abzulegen. Im 2. Schritt wird in der Datei global ein Verzeichnis für den Parameter RecoveryIndexDir=PathToBackupDir abgelegt. Nach dem Speichern der Datei global ist es notwendig die Data Protector Dienste neu zu starten. Mit der ersten Sicherung der IDB wird in dem gewählten Verzeichnis die Datei obrindex.dat abgelegt.

In dieser Datei befindet sich die Information welches Band bei der Sicherung verwendet wurde und ebenso eine erste Information zu dem Laufwerk was bei der Sicherung verwendet wurde.

Ein weiterer Schritt sollte die regelmäßige Sicherung von Informationen zu Laufwerken sein. Dies kann mit dem Befehl omnidownload durchgeführt werden. Die gewonnen Text Dateien können im Disaster Fall und dem Befehl omniupload zur Wiederherstellung der Laufwerksinformation genutzt werden. Hierfür kann auch “SaveDevices” (zu finden unter Downloads) genutzt werden was diesen Prozess automatisiert.

Tritt nun der Desaster Fall ein, so kann man prinzipiell folgende Schritte anwenden:

• Ersetzen der defekten Hardware
• Installation Betriebssystem
• Basis Installation Cell Server
• Anlegen der Laufwerke für den Restore der IDB
• Importieren des Bandes auf dem die Sicherung der IDB liegt
• Restore der IDB
• Restore aller anderen Einstellungen des Cell Servers über den normalen Filesystem Restore

Wie bereits oben beschrieben ist dies nur ein Verfahren für die Wiederherstellung des Cell Servers. Im Artikel EADR W2K und Recover Cell Server werden die anderen Möglichkeiten mit SRD / omniiso beschrieben.

Problem: Das Backup mancher virtueller Maschinen nutzt fälschlicherweise den Transportmodus NBD statt SAN. Dies passiert auch wenn explizit für diese virtuellen Maschinen oder den vApp Container der Transportmodus SAN eingestellt wurde. Es kann durchaus sein das andere virtuelle Maschinen auf der gleichen SAN Disk den richtig konfigurierten Transportmodus benutzen. Die Ursache des Problems ist in der Regel ein nicht freigegebener SAN lock durch VMware in einer vorhergehenden Sicherung, daher können nachfolgende Sicherungen nicht den eingestellten Transportmodus nutzen und stellen auf NBD um. Steht nur der Transportmodus NBD zur Verfügung und VMware gibt den lock nicht frei, dann schlägt die Sicherung der virtuellen Maschine komplett fehl.

Die entsprechende Meldung in Data Protector lautet: Virtual Machine ‘Server_a.demo.local': Backup disk scsi0:0 using transport method NBD

Lösung: Wenn keine Backups von virtuellen Maschinen laufen, sollte auf dem VE-Agent Server in z.B. c:\windows\temp\vmware-SYSTEM Verzeichnis nach Verzeichnissen gesucht werden die Namen von virtuellen Maschinen enthalten. Beim Auflisten des Inhalts sieht man die Lock Dateien. Es wird empfohlen die Verzeichnisse entsprechend zu löschen. Nach einem erneuten Start des Backups der virtuellen Maschinen wird der Transportmodus SAN erneut verwendet. Unter Umständen müssen vorher die Berechtigungen für das Verzeichnis angepasst werden.

omnib2dinfo: Mit den letzten Patches für DP 7.01 vom 09.04.2013 wurde die Syntax für den Befehl omnib2dinfo geändert. In vorherigen Versionen musste beim Aufrufen des Kommandos der Device Type und der Hostname mit angegeben werden, unabhängig davon ob es sich um den Software Store oder ein StoreOnce System handelt. Mit der neuen Version kann ein logischer Device Name angegeben werden. Zusätzlich ermöglicht die Änderung das Ausführen des Befehls auf dem Cell Server, statt auf einem Client mit installiertem Media Agent (Cell Server oder Client mit installiertem Media Agent).

Neue Syntax:

Alte Syntax:

Bei Verwendung des StoreOnce Software Store in Data Protector kann es während der Sicherung zu folgender Fehlermeldung kommen: There are no available connections on gateway. Grund hierfür sind “locked devices” in der Media Management Database, die zu spät oder erst nach Neustarten der Data Protector Dienste wieder freigegeben werden. Dieser Fehler tritt selten auf und kann mit dem Befehl omnidbutil -free_locked_devs behoben werden.

“Tape Persistence” bedeutet dass die Laufwerke einer Library mit einem symbolischen Namen versehen werden. Diese Namen bleiben auch bei Server Neustarts erhalten, egal in welcher Reihenfolge das Betriebssystem die Laufwerke erkennt. Ohne dieses Windows Feature kann es bei Reboots vorkommen dass sich die SCSI Adressen er Laufwerke verändern.

Für Data Protector ist das Verhalten von Windows normalerweise kein Problem, da über den Mechanismus “Automatically detect changed SCSI addresses” die neuen SCSI Adressen zuverlässig anhand der Seriennummern erkannt werden. Jedoch kann in Umgebungen mit mehreren an einen Server zugewiesenen Libraries (z.B. für virtuelle Libraries) das voreingestellte Verhalten von Windows dazu führen, dass die SCSI Adressen zwischen den Libraries nach einem Reboot vermischt werden. In der Regel benötigt dann der integrierte DP Mechanismus einige Zeit die neuen SCSI Adressen wieder ordnungsgemäß zu zuordnen und zeigt unter Umständen mehrere Fehler während der Sicherungen an. Mit “Tape Persistence” wird das Windows Verhalten geändert und beispielsweise aus einem Tape0 der symbolische Name Tape1236572535 generiert, der Name ist dabei nicht konfigurierbar. Mit diesem neuen Name für das Laufwerk werden Fehlermeldungen in Data Protector vermieden und die SCSI Adressen / Tape Namen bleiben eindeutig.

Zum Aktivieren von “Tape Persistence” in Windows den nachfolgenden Code kopieren in einen Editor einfügen und als .reg Datei speichern. Anschließend die Datei ausführen und den Server neu starten. Zusätzlich wird der Wechselmediendienst deaktiviert. Nicht vergessen die HP Tape Treiber zu installieren, die gibt’s im Download Bereich der HP Libraries für jede Library.

Update: Damit auch die Robotic auf “persistence” gestellt werden kann ist der Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MChgr\Persistence=00000001 notwendig. Hierbei wird beispielsweise aus einem Changer1:0:0:0 der symbolische Name Changer2147483646:0:0:0 generiert. Mit diesem Wert bleibt auch die Robotic nach Reboots eindeutig erhalten.

Schon mal das Problem gehabt wissen zu wollen was eigentlich alles in einem Backup gesichert wurde? Data Protector zeigt die gesicherten Dateien und Verzeichnisse ja erst mal nicht in der internen Datenbank unter Sessions an, erst über die Restore oder “Restore by query” Funktion kann man rudimentär sich die gesicherten Dateien und Verzeichnisse auflisten lassen.

Über einen einfachen Befehl kann man sich aber den Inhalt der Sicherung, also welche Dateien und Verzeichnisse gesichert wurden, auflisten lassen. Der Befehl fragt den Katalog der internen Datenbank für eine Session, für ein Objekt ab.

Der Befehl sieht beispielsweise so aus: omnidb -winfs server.demo.local:/F "server.demo.local [/F]" -session 2013/04/02-4 -catalog.

Der Output (gekürzt) sieht dann wie unten aufgeführt aus:

Update: Wenn die Sicherung nur ein Medium verwendet hat kann auch das Kommando omnimm -catalog < medium > zum Auflisten der gesicherten Dateien und Verzeichnisse genutzt werden. In der GUI kann dazu die Funktion “list from media” Im Restore Kontext verwendet werden.

Nach einem Upgrade auf Data Protector 7.01 kann es selten zu folgender Fehlermeldung beim Zugriff auf Changer oder Bandlaufwerke kommen: IPC Invalid Packet Size. Grund hierfür kann eine langsame Namensauflösung auf dem Media Agent sein, so dass der INET Timout eintritt bevor eine Antwort an den entsprechenden Prozess gesendet werden kann. Die bereits bekannte omnirc Variable OB2INETTIMEOUT kann in diesem Fall vom Wert 10 auf einen höheren Wert (z.B. 30) gesetzt werden. Der neue Wert – OB2INETTIMEOUT=30 muss auf dem betroffenen Media Agenten in der omnirc gespeichert werden.

Wenn man mit Data Protector 7.01 – aktuelle Patches und wahrscheinlich auch mit der nächsten Version von Data Protector einen Linux OES Server mit aktivierten NSS Volumes sichern möchte, so kann es sein dass die NSS Volumes nicht korrekt angezeigt werden und folgende Fehlermeldung erscheint: 12:1304 The mountpoint/file-system cannot be backed up. Dieses Problem wurde bereits mit DP 6.2 gemeldet – die Lösung kann hier nachgelesen werden: http://www.data-protector.org/wordpress/2011/11/nss-volumes-on-linux-oes-with-dp-6-20/

Bei Verwendung einer falschen Block Size auf einem Band Laufwerk kann es zur Fehlermeldung kommen: Cannot write to device ([87] The Parameter is incorrect.). Diese Meldung kann beispielsweise dann auftreten wenn eine SAS Library an dem Controller P212-ZM angeschlossen ist und man eine höhere Block Size für die Sicherung nutzen möchte. In diesem Fall hilft es den Controller mit Speicher zu erweitern und dann ist auch eine höhere Block Size wie 64K möglich.

Aber auch bei einer zu großen Block Size kann es Probleme geben. Im konkreten Fall konnte bei einem QLogic HBA (QMH2462) erfolgreich in der Vergangenheit ein Backup mit einer Block Size von 1024K durchgeführt werden – die Firmware auf dem HBA hatte den Stand 5.03.15. Nach einem Update der Windowstreiber und der Firmware auf Version 9.1.10.27 mit der Firmware 5.06.05 kam es dann zu dieser Fehlermeldung. Die Einstellung qlfc - tsize 1024 nach dem Update brachte keinen Erfolg. Offensichtlich hat Qlogic seit der Firmware Version 5.04.02 Änderungen an der Firmware hinsichtlich der Blockgrößen durchgeführt. Im diesem Fall bleibt nur das Zurückstellen der Block Size für die Laufwerke in der Sicherung auf den Wert 512K und entsprechendes Formatieren der Bänder mit der neuen Block Size. Danke an Volker für die Ausarbeitung.

Bei der Sicherung virtueller Maschinen mit der Virtual Environment Integration (VE) auf ein Catalyst Gateway (StoreOnce) kann es unter Data Protector 7.01 (aktuelle Patches) zu einem Abbruch bei der Sicherung kommen. Die Fehlermeldung sieht so aus:

[Major] From: BSM@server.demo.local "VE_Backup_VMware"  Time: 15/07/2013 10:03:03
[61:3003]      Lost connection to BMA named "StoreOnce_01_GW1 [GW 2296:4:26641437476]"  
        on host server.demo.local.
        Ipc subsystem reports: "IPC Read Error
        System error: [10054] Connection reset by peer

Abhilfe schafft der omnirc Parameter OB2D2D_BANDWIDTH_BUFF_SIZE=20 auf dem Media Agent. Der Parameter ist unter DP 7.01 auf den Standardwert 10 eingestellt, bei Verwendung von 20 für den Wert tritt das Problem nicht auf. Data Protector 8.00 ist hiervon nicht betroffen, da hier der Standardwert auf 20 eingestellt ist.

In der Menuleiste wurde eine weitere Kategorie hinzugefügt – FAQs. Hier werden Fragen und Antworten zu verschiedenen Themen, beispielsweise zu BRICK, erörtert.

Update: Am 24.10.2013 ist für Linux, HP-UX und Windows das Patch-Bundle 7.03 herausgegeben wurden. Das Bundle behebt diverse Probleme und erweitert auch den Support für Integrationen und bietet neue Funktionen. Wegen der vielen Änderungen empfiehlt es sich die komplette Beschreibung des Updates zu lesen. Alte Meldungen wurden entfernt.

Das Patch-Bundle ist wie üblich downloadbar, ein Passport Account wird benötigt.

- Windows – DPWINBDL_00703 – Patch Bundle

- Linux – DPLNXBDL_00703 – Patch Bundle

- HP-UX – DPUXBDL_00703 – Patch Bundle

Es wurde bereits mehrmals beobachtet und von anderen erzählt dass es mit DP 7.01 zu hängenden Sessions kommen kann oder die Sicherung nach 7200 Sekunden Timeout abbricht. Diese IPC Meldung (Beispiel – siehe unten), bei der keine Daten mehr vom Agenten an den Media Agenten oder Cell Server gesendet werden, ist generell ein Netzwerkthema. In der Regel sind Firewalls dafür verantwortlich die eine Verbindung einfach kappen wenn kein Traffic mehr gesendet wird, obwohl dies aus Sicherungssicht normal sein kann. Als Lösung zeigt sich hier die omnirc Datei, diese Werte sollte mindestens enthalten sein; ich empfehle auch mal den DPcfgCreator von Stephan Voss zu testen.

Update: Die Variablen OB2IPCKEEPALIVETIME und OB2IPCKEEPALIVEINTERVAL sind nur für Windows gültig, auf Linux und HP-UX wird das TCP Verhalten auf Betriebssystem-Ebene (Kernel Parameter) gesteuert und für Data Protector ist die Variable OB2IPCKEEPALIVE notwendig. Für weiterführende Informationen wird auf den Artikel http://h30499.www3.hp.com/t5/Data-Protector-Support-and-News/Data-Protector-Support-Tip-Linux-Only-Using-KeepAlive-to-resolve/td-p/6263015#.UuC5thQwc08 verwiesen. Danke an Alexander.

Die Migration der internen Datenbank auf eine neue Hardware oder ein neues Microsoft Windows Betriebssystem war in der Vergangenheit und vor Data Protector 8.XX keine große Schwierigkeit. Mit Einführung von PostgreSQL als neue interne Datenbank sind aber mehrere Schritte notwendig, um eine erfolgreiche Migration durchführen zu können. Nachfolgend eine Anleitung, die eine Migration auf neue Hardware, oder zum Beispiel den Umzug von Windows 2008 R2 auf Windows 2012 R2 ermöglichen. Damit der Umzug erfolgreich durchgeführt werden kann, sind einige Voraussetzungen zu erfüllen; des Weiteren ist die Migration an einige Bedingungen geknüpft. Für die Anleitung kann keine Garantie übernommen werden und es wird empfohlen die Migration mit einem HP Partner durchzuführen. Für den aufwendigen Artikel freue ich mich über Spenden.

Voraussetzungen und Bedingungen:

• Der Befehl omnidbcheck -extended liefert keine Fehler. Für Data Protector 8.10 ist unter Umständen der Hotfix QCCR2A50694 notwendig. Erfolgreicher omnidbcheck:
  

  C:\>omnidbcheck -extended
  Check Level             Mode                    Status
  ===========================================================
  Database connection     -connection             OK
  Schema consistency      -schema_consistency     OK
  Datafiles consistency   -verify_db_files        OK
  Database consistency    -database_consistency   OK
  Media consistency       -media_consistency      OK
  SIBF(readability)       -sibf                   OK
  DCBF(presence and size) -bf                     OK
  OMNIDC(consistency)     -dc                     OK
  DONE!

• Die alten “Detail Catalog Binary Files” (pre DP 8.XX) der internen Datenbank wurde vollständig migriert. Der Befehl (Beispiel) "C:\Program Files\Omniback\bin\perl.exe" omnimigrate.pl -report_old_catalog liefert folgendes Ergebnis:
  

  Old Detail Catalog Binary Files size:
  
  DCBF (   0 files):                    0 MB
  Old filename data files:              0 MB
  Total:                                0 MB
  

  Falls noch alte “Binary Files” angezeigt werden, so sind diese zunächst zu migrieren. Hierfür kann der Befehl (Beispiel) "C:\Program Files\Omniback\bin\perl.exe" omnimigrate.pl -start_catalog_migration genutzt werden. Falls für “DCBF” 0 Dateien angezeigt werden, aber immer noch “Old filename data files” vorhanden sind, so kann das auf Veränderungen an den alten DCBF Verzeichnissen vor oder nach der Migration hindeuten. In diesem speziellen Fall können die DCBF Dateien aus den alten db40 Verzeichnissen in die db80 Verzeichnisse verschoben werden. Ein anschließendes omnidbutil -remap_dcdir und omnidbutil -fixmpos müssen durchgeführt werden.

• Der alte Katalog und die alten “Binary Files” wurden nach der Migration gelöscht (Achtung: siehe Hinweis db40). Falls dieser Schritt noch nicht durchgeführt wurde oder Unsicherheit darüber besteht, so kann der Befehl (Beispiel) "C:\Program Files\Omniback\bin\perl.exe" omnimigrate.pl -remove_old_catalog zum Löschen verwendet werden. Bei einem erfolgreichen Löschen wird auch die Datei global angepasst und die Unterstützung für den alten Katalog entfernt (SupportOldDCBF=1).
• Es dürfen keine DCBF Verzeichnisse aus einer früheren (pre DP 8.XX) Data Protector Version existieren. Der Check kann über die GUI – Internal Database durchgeführt werden. Alternativ kann ein Export der IDB mit dem Befehl omnidbutil –writedb <Pathname> durchgeführt werden. Nach dem Export und dem Hinweis zu den zu kopierenden Verzeichnissen, darf kein db40 Pfad enthalten sein. Übrigens ist seit Version 8.XX ein Export der IDB auch auf eine verbundene Netzwerkfreigabe möglich. Kontrolle Export auf db40 Verzeichnisse:
  

  Please make a copy of the following Internal Database directories and then press Enter to bring the Internal Database back to a fully operational state:
  
          "C:/Program Files/OmniBack/server/db80/msg"
          "C:/Program Files/OmniBack/server/db80/meta"
          "C:/Program Files/OmniBack/server/db80/dcbf/dcbf3"
          "C:/Program Files/OmniBack/server/db80/dcbf/dcbf0"
          "C:/Program Files/OmniBack/server/db80/dcbf/dcbf2"
          "C:/Program Files/OmniBack/server/db80/dcbf/dcbf1"
          "C:/Program Files/OmniBack/server/db80/dcbf/dcbf4"
  

  Hinweis: im Beispiel wurde noch nicht die Trennung nach “Program Files” und “Programdata” durchgeführt, siehe hierzu auch Folgepunkte.

• Hinweis db40: Sollten noch DCBF Dateien im db40 Pfad existieren, so kann das verschiedene Ursachen haben. Eine Migration ist unbedingt vor dem Entfernen des alten Katalogs notwendig. Zur Prüfung ob noch “Binary Files” migriert werden müssen, speichert man select medium_name, dcbf_directory, dcbf_version from dp_dcbf_info i, dp_dcbf_directory d where i.dcbf_directory_seq_id = d.dp_numkey order by dcbf_version; in die Datei dcbf_version.sql und führt den Befehl omnidbutil –run_script dcbf_version.sql –detail aus. Die Ausgabe beinhaltet die Medium ID, das Verzeichnis und die DCBF Version. Medien mit -1 stammen noch von einer pre DP 8.XX Version und können einzeln mit dem Befehl omnimm -upgrade_dcbf <mediumID> migriert werden. Falls für die Anzeige der DCBF Verzeichnisse im DB40 Pfad (sofern noch vorhanden) ein Back-Slash statt Forward-Slash angezeigt wird, so ist die Datenbank zu exportieren (omnidbutil –writedb <Pathname>), die Datei dpidb.dat zu bearbeiten, und die betroffenen Verzeichnisse (siehe Ausgabe vorheriger Punkt) zu ändern (Back-Slash in Forward-Slash). Nun kann über den Befehl omnidbutil –readdb <Pathname> die IDB importiert werden. Über den Befehl omnidbutil -remove_dcdir <PathName> können nun die alten DCBF Verzeichnisse entfernt werden. Der relevante Teil der Datei dpidb.dat sollte so aussehen (Beispiel und ohne Trennung “Program Files” und “Programdata”):
  

  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1004	C:/Program Files/OmniBack/server/db80/dcbf/dcbf3	214748364800	3	2147483648	100000	44	6964137984
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1001	C:/Program Files/OmniBack/server/db80/dcbf/dcbf0	214748364800	0	2147483648	100000	48	9023758336
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1003	C:/Program Files/OmniBack/server/db80/dcbf/dcbf2	214748364800	2	2147483648	100000	39	6941310976
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1002	C:/Program Files/OmniBack/server/db80/dcbf/dcbf1	214748364800	1	2147483648	100000	40	6340190208
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1005	C:/Program Files/OmniBack/server/db80/dcbf/dcbf4	214748364800	4	2147483648	100000	63	7780794368
  

• Die Trennung von “Program Files” und “Programdata” sollte bereits in der Vergangenheit vollzogen wurden sein. Ist dies nicht der Fall und die Trennung der Verzeichnisse soll während der Migration auf der Ziel-Hardware/Ziel-Plattform durchgeführt werden, so sind besondere Schritte in der Migration notwendig. In dieser Anleitung wurde die Trennung noch nicht vollzogen; die zusätzlichen Schritte sind entsprechend dokumentiert.
• Die verwendeten Benutzernamen und Passwörter (Windows) zum Starten der Data Protector Dienste werden auf der Ziel-Hardware/Ziel-Plattform identisch weiterverwendet. Sollte jedoch für die neue Hardware/Plattform andere Benutzernamen und Passwörter verwendet werden, so kann die Anleitung „Data Protector 8.0 Windows – change user account for DP services“ (Link: http://www.data-protector.org/wordpress/2013/11/data-protector-8-0-windows-change-user-account-dp-services/) genutzt werden.
• Die Anleitung ist nicht für ein Upgrade von pre DP 8.XX Versionen gültig.
• Das Upgrade auf die aktuellste Data Protector 8.XX Version sollte bereits auf dem Quell-System erfolgen, dies erleichtert die anschliessende Migration. Dies sollte jedoch nur dann auf dem Quell-System durchgeführt werden, wenn die Trennung von “Program Files” und “Programdata” bereits erfolgt ist. Grund für diese Vorgehensweise ist ein Bug in der Installationsroutine beim Upgrade von DP 8.0X auf 8.10. Im konkreten Fall wird auf dem neuen Server/Betriebssystem die bestehende Version neu installiert und anschließend das Uprade auf dem Ziel-System durchgeführt.
• Der Servername und die IP Adresse ändern sich für den Cell Server auf dem Ziel-System nicht. Sollte dies notwendig sein, so sind weitere Schritte wie das Exportieren der Clients vor der Migration, das Importieren der Clients nach der Migration, das Ändern des Cell Server Namens, usw. durchzuführen (nicht Bestandteil dieser Anleitung).
• Der Servername darf nicht mit einer führenden Zahl, sondern muss mit einem Buchstaben beginnen. Grund hierfür ist eine Limitierung im enthaltenen Anwendungsserver (JBOSS/Tomcat).
• Die interne Datenbank wurde bisher nicht komplett wiederhergestellt und es existieren nicht mehrere DB80 Verzeichnisse (Restore Versionen).
• Alle verwendeten Namen sind beispielhaft anzusehen.
• Nach erfolgter Migration ist eine sofortige Sicherung des Servers und der internen Datenbank durchzuführen. Ein Restore der IDB auf einen Stand vor der Migration ist unter Umständen und insbesondere beim Verändern der Zielverzeichnisse nicht möglich, bzw. nur beim manuellen Bearbeiten der exportierten Datenbank realisierbar.
• Die Anleitung gilt nicht für MoM Umgebungen.

Durchführung der Migration:

• Sicherung der internen Datenbank für einen schnellen Import im Falle eines Fehlers. Hierfür wird eine Jukebox mit mehreren Slots und einem Laufwerk angelegt. Die Bänder werden formatiert und anschliessend eine Sicherung der IDB durchgeführt. Nach der Sicherung wurden die Jukebox Dateien (im Beispiel: e:\IDBSicherung\01..05) in einen Migrationsordner außerhalb des Servers kopiert. Falls lokal nicht genügend Plattenplatz für das Betreiben einer Jukebox vorhanden ist (Jukebox Dateien müssen auf lokalen Platten liegen), so kann alternativ eine Filelibrary mit Speicherung auf einer Netzwerkfreigabe verwendet werden. Die Jukeboxdefinition und die Laufwerksdefinition werden zur Sicherheit in Textdateien gespeichert. Jukeboxdefinition:
  

  E:\Program Files\OmniBack\bin>omnidownload -library IDBSicherung
  NAME "IDBSicherung"
  DESCRIPTION ""
  HOST servername.domain
  POLICY Jukebox
  TYPE File
  REPOSITORY
          "E:\IDBSicherung\01"
          "E:\IDBSicherung\02"
          "E:\IDBSicherung\03"
          "E:\IDBSicherung\04"
          "E:\IDBSicherung\05"
  MGMTCONSOLEURL ""
  

  Laufwerksdefinition:

  E:\Program Files\OmniBack\bin>omnidownload -device IDBSicherung_Drive01
  NAME "IDBSicherung_Drive01"
  DESCRIPTION ""
  HOST servername.domain
  POLICY Jukebox
  TYPE File
  POOL "IDBSicherung"
  LIBRARY "IDBSicherung"
  CONCURRENCY 10
  ENCRCAPABLE
  BUFFERS 16
  BLKSIZE 64
  RESTOREDEVICEPOOL NO
  COPYDEVICEPOOL NO
  

  Im Fehlerfall kann die Ausgabe zur Erstellung der Jukebox verwendet werden (siehe Hilfe zu Befehl omniupload).

• Stoppen des Data Protector Schedulers mit dem Befehl omnitrig -stop
• Export der internen Datenbank mit dem Befehl omnidbutil –writedb <pathname> (im Beispiel Z:\ExportIDB). Nach Aufforderung werden die Verzeichnisse DCBF, MSG und META in den Migrationsordner ausserhalb des Servers (z.B. Z:\Migration) kopiert.
• Stoppen der Data Protector Dienste mit dem Befehl omnisv -stop
• Kopieren der Data Protector Verzeichnisse ausserhalb des Servers (z.B. Z:\Migration). Hierbei kann auf das Kopieren der DCBF, MSG und META Verzeichnisse verzichtet werden, da dies bereits im vorherigen Schritt erfolgt ist. Hinweis: Beim Kopieren werden symbolische Links in der IDB Verzeichnisstruktur komplett kopiert, so dass auf dem Zielsystem entsprechen mehr Plattenplatz zur Verfügung gestellt werden muss. Mit dem Kopieren sind alle Data Protector relevanten Verzeichnisse gesichert, dies gilt nicht für eventuell weitere installierte Dienste auf dem Server.
• Neuinstallation der neuen Hardware oder des neuen Betriebssystems. Für die Installation des neuen Systems sind der gleiche Servername, IP Adresse, Domain, Benutzer und Gruppen zu verwenden. Bei notwendigen Änderungen müssen die anzupassenden Konfigurationsdateien (siehe unten) einzeln geprüft werden.
• Neu-Installation des HP Data Protector 8.XX nach “D:\Program Files\Omniback” und “D:\Programdata\Omniback”. Es ist die gleiche Version, inklusive Patches, Hotfixes, usw. wie auf dem Quell-System zu installieren.
• Impersonation konfigurieren:
  

  C:\Users\administrator>omniinetpasswd -inst_srv_user domain\administrator
  User 'domain\administrator' is configured to be used by Installation Server.
  

• Stoppen der Data Protector Dienste mit dem Befehl omnisv -stop
• Bei Bedarf Anpassung der lokalen Sicherheitsrichtlinie. Dies ist notwendig, wenn für den “Data Protector INET” Dienst ein personalisierter Account statt NT Authority\SYSTEM verwendet werden soll. Der verwendete Benutzer muss in der lokalen Sicherheitsrichtline bei den Policies “Impersonate a client after authentication” = “Annehmen der Clientidentität nach Authentifizierung” und “Replace a process level token” = “Ersetzen eines Tokens auf Prozessebene” hinzugefügt werden.
• Die DCBF, MSG und META Verzeichnisse werden an ihre neue Stelle kopiert. Der Pfad im Beispiel ist D:\Programdata\OmniBack\server\db80.
• Ändern der DCBF Verzeichnisse in der Datei dpidb.dat (siehe Export der internen Datenbank). Dieser Schritt ist nur notwendig, wenn die Zielverzeichnisse während der Migration geändert wurden. Ändern der DCBF Verzeichnisse von:
  

  COPY dp_catalog_dcbf_directory (db_uuid, seq_id, dcbf_directory, maxsize, fill_sequence, min_freespace, max_dcbf_files, cur_num_of_files, cur_occupied_space) FROM stdin;
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1002	E:/Program Files/OmniBack/server/db80/dcbf/dcbf1	214748364800	1	2147483648	100000	47	6341406720
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1004	E:/Program Files/OmniBack/server/db80/dcbf/dcbf3	214748364800	3	2147483648	100000	44	6964137984
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1001	E:/Program Files/OmniBack/server/db80/dcbf/dcbf0	214748364800	0	2147483648	100000	48	9023758336
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1003	E:/Program Files/OmniBack/server/db80/dcbf/dcbf2	214748364800	2	2147483648	100000	39	6941310976
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1005	E:/Program Files/OmniBack/server/db80/dcbf/dcbf4	214748364800	4	2147483648	100000	63	7780794368
  

  Ändern der DCBF Verzeichnisse auf:

  COPY dp_catalog_dcbf_directory (db_uuid, seq_id, dcbf_directory, maxsize, fill_sequence, min_freespace, max_dcbf_files, cur_num_of_files, cur_occupied_space) FROM stdin;
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1002	D:/ProgramData/OmniBack/server/db80/dcbf/dcbf1	214748364800	1	2147483648	100000	47	6341406720
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1004	D:/ProgramData/OmniBack/server/db80/dcbf/dcbf3	214748364800	3	2147483648	100000	44	6964137984
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1001	D:/ProgramData/OmniBack/server/db80/dcbf/dcbf0	214748364800	0	2147483648	100000	48	9023758336
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1003	D:/ProgramData/OmniBack/server/db80/dcbf/dcbf2	214748364800	2	2147483648	100000	39	6941310976
  20cf4d3f-d425-4f01-8823-9b9e9dcfa72c	1005	D:/ProgramData/OmniBack/server/db80/dcbf/dcbf4	214748364800	4	2147483648	100000	63	7780794368
  

• Selektives Wiederherstellen (Kopieren) der Dateien in D:\Programdata\OmniBack\log\server. Relevant sind Dateien wie media.log, Ob2Event.* und der Ordner auditing.
• Anpassen, bzw. Wiederherstellen der Konfigurationsdateien global (Beispiel: D:\ProgramData\Omniback\Config\Server\Options) und omnirc (Beispiel: D:\ProgramData\Omniback).
• Anpassen, bzw. Wiederherstellen der Dateien cell_info, lic.dat und installation_servers. Hinweis: Nach dem Upgrade auf DP 8.1X sind bisherige Lizenzen ungültig und müssen über http://webware.hp.com neu generiert werden. Dies setzt einen gültigen Wartungsvertrag voraus.
• Wiederherstellen (Kopieren) der Ordner: BarLists, Barschedules, consolidationlists, copylists, Datalists, dlgroups, dr, Integ, rptgroups, rptschedules, Schedules, users. Für die Dateien im Ordner users empfiehlt es sich selektiv Einträge aus der alten userlist zu übernehmen.
• Anpassen der Dateien hpdp-idb-cp.cfg und idb.config im Verzeichnis (Beispiel) D:\ProgramData\Omniback\Config\Server\idb. In beiden Dateien müssen die Pfade angepasst werden.
  Beispiel hpdp-idb-cp.cfg:

  [databases]
  hpdpidb = host=127.0.0.1 port=7112 dbname=hpdpidb
  
  [pgbouncer]
  service_name=hpdp-idb-cp
  listen_addr = *
  listen_port = 7113
  unix_socket_dir = /tmp
  auth_type = md5
  admin_users = hpdp
  stats_users = hpdp
  pool_mode = transaction
  server_reset_query =
  ignore_startup_parameters = application_name,extra_float_digits
  server_check_query = select 1
  server_check_delay = 10
  max_client_conn = 1200
  default_pool_size = 50
  query_wait_timeout = 10
  log_connections = 0
  log_disconnections = 0
  log_pooler_errors = 1
  logfile = D:\ProgramData\OmniBack\log\hpdp-idb-cp.log
  pidfile = D:\ProgramData\OmniBack\log\hpdp-idb-cp.pid
  auth_file = D:\ProgramData\OmniBack\config\server\idb\ulist
  

  Beispiel idb.config:

  PGHOSTNAME='localhost';
  PGIDBNAME='hpdpidb';
  PGUSER='hpdpidb_app';
  PGPASSWORD='bWhhbnTvZ3Xxbao2Zw==';
  PGSUPERUSER='hpdp';
  PGSUPERPASSWORD='anpabZl3bnh6dGY3eQ==';
  PGMAXOPEN_CONN_NUMBER='5';
  PGDATA_PG='D:\ProgramData\OmniBack\server\db80\pg';
  PGDATA_IDB='D:\ProgramData\OmniBack\server\db80\idb';
  PGDATA_JCE='D:\ProgramData\OmniBack\server\db80\jce';
  PGOSUSER='domain\administrator';
  PGPORT='7112';
  PGCPPORT='7113';
  PGWALPATH='D:\ProgramData\OmniBack\server\db80\pg\pg_xlog_archive';
  IDB_SEC_FLAG='11';
  

• Bei Bedarf und je nach Konfiguration müssen weitere Ordner wiederhergestellt werden. Beispielsweise wird bei einer Exchange Sicherung der Ordner (Beispiel) D:\ProgramData\Omniback\server\db80\vssdb\metadata60 zusätzlich benötigt.
• Starten der Data Protector Dienste mit dem Befehl omnisv -start.
• Stoppen des Data Protector Schedulers mit dem Befehl omnitrig -stop.
• Import der Datenbank mit dem Befehl omnidbutil -readdb <pathname> (im Beispiel Z:\ExportIDB).
• Stoppen der Data Protector Dienste mit dem Befehl omnisv -stop.
• Starten der Data Protector Dienste mit dem Befehl omnisv -start.
• Überprüfung der internen Datenbank mit dem Befehl omnidbcheck -extended. Es dürfen keine Fehler protokolliert werden.
• Überprüfung der Umgebung durch Starten von Sicherungen und Wiederherstellen von Daten vor und nach der Migration.
• Nach erfolgreicher Migration kann die verwendete Jukebox (IDBSicherung) und die verwendeten Verzeichnisse entfernt werden. Die anderen für die Migration verwendeten Verzeichnisse sollten zur Sicherheit für mindestens 7 Tage aufbewahrt werden.
• Nun kann bei Bedarf und falls nicht bereits auf dem Quell-System durchgeführt, das Upgrade auf die aktuelle Data Protector Version durchgeführt werden.

In einem früheren Artikel (siehe http://www.data-protector.org/wordpress/2013/05/persistent-binding-hp-lto-tape-drives-windows/) hatte ich zu “Tape Persistence” für Windows berichtet. Prinzipiell ändert sich an der Vorgehensweise für Windows 2012 nichts und die Registry Keys bleiben gleich. Voraussetzung ist jedoch, dass auf den Fibre Channel HBA “Target Persistent Binding” aktiviert ist. Für QLogic Adapter kann dies mit dem Tool “QConvergeConsole” (ehemals SANSurfer) konfiguriert werden. Für Emulex Adapter (HBAAnywhere) ist die Konfiguration ähnlich vorzunehmen. Nach Aktivieren und Konfigurieren auf dem Adapter, das Hinzufügen der Registry Keys und einem abschließenden Reboot, stehen die Laufwerke und Changer wie gewohnt “persistent” zur Verfügung. Kommentar: Alle Angaben getestet mit HP Libraries und Laufwerken.

Beispiel:

Registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hplto]
"AutoRun"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Tape]
"Persistence"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MChgr]
"Persistence"=dword:00000001

Mit Einführung von Data Protector 8.XX hat sich auch der Prozess zum Erstellen des Disaster Recovery Images geändert. Seit der neuen Version und der Trennung des IDB Backups vom Filesystem Backup ist es nicht mehr möglich das im Download Bereich zur Verfügung gestellte “makeiso.cmd” (siehe auch http://www.data-protector.org/wordpress/2011/03/recover-cell-server-with-enhanced-automated-disaster-recovery/) zu nutzen. Mit der Trennung ist es notwendig für den Befehl omniiso 2 Session ID’s zu übergeben; die Session ID der Filesystemsicherung und die Session ID der IDB Sicherung. Zur Vorbereitung auf ein Desaster Fall und zum automatischen Erstellen des Recovery Images wurden daher neue Batch Files erstellt. Nachfolgend die Anleitung zum Einbinden auf dem Cell Server. Die Anleitung ist nur gültig für die Data Protector Versionen 8.10 und 8.11 und wurde jeweils unter Windows 2012 R2 getestet. Für die Data Protector 8.0X Version funktionieren die zur Verfügung gestellten Batch Dateien nicht, da bei diesen Versionen noch nicht die Option -anyobj zur Verfügung stand. Mit einer leichten Modifikation lässt sich aber das Erstellen des ISO Images in diesem Fall über einen “Scheduled Task” einrichten und nutzen.

Voraussetzungen und Durchführung:

• Auf dem Cell Server ist das WAIK/ADK in der benötigten Version installiert – für Windows 2012 R2 wird das ADK für Windows 8.1 benötigt.
• Die Batch Dateien (siehe Download Link) werden im “Bin” Verzeichnis von Data Protector abgelegt (zum Beispiel: D:\Program Files\Omniback\bin).
• Die Sicherung des Filesystems des Cell Servers erfolgt mit den Optionen “Copy Recovery Set to disk” (Filesystem Options – Advanced – Tab Other) und “Detect NTFS hardlinks”, “Backup share Information for directories” und “Use Shadow Copy” (Filesystem Options – Advanced – Tab WinFS Options).
• Die Sicherung des Filesystems des Cell Servers erfolgt in einer eigenen Backupspezifikation und als Post-exec Skript wird die Batch DateiEADR_CS_FSBackup_Post.cmd (auszuführen auf dem Cell Server) eingetragen (Backup Specification Options – General – Post-exec).
• Die Sicherung der internen Datenbank des Cell Servers wird ohne Schedule erstellt (Aufruf erfolgt durch die vorherige Filesystem Sicherung) und als Post-exec Skript wird die Batch Datei EADR_CS_IDBBackup_Post.cmd (auszuführen auf dem Cell Server) eingetragen (Backup Specification Options – General – Post-exec).
• In der Batch Datei “EADR_CS_FSBackup_Post.cmd” sind folgende Anpassungen notwendig: Variablen OMNIHOME, OMNIDATA und IDBBACKUP (Name der Backup Spezifikation für die Sicherung der IDB Sicherung) entsprechend der Umgebung setzen.
• In der Batch Datei “EADR_CS_IDBBackup_Post.cmd” sind mindestens folgende Anpassungen notwendig: Variablen OMNIHOME, OMNIDATA, CELLSERVER, WAIKPATH, NETWORKSHARE entsprechend der Umgebung setzen.
• Die Batch Dateien wurden bereits mit Werten vor belegt, so dass eine leichte Anpassung an die eigene Umgebung möglich ist.

Beispiel Session Messages der Filesystem Sicherung:

[Normal] From: BSM@server.domain "CS_Backup_FS"  Time: 04.04.2014 11:01:57
	Starting to execute "EADR_CS_FSBackup_Post.cmd"...


Starting EADR preparation and IDB backup

Script Environment: host='SERVER' user='DOMAIN\user' 
                    script='D:\Program Files\OmniBack\bin\EADR_CS_FSBackup_Post.cmd' 
                    path='D:\Program Files\OmniBack\bin\' 
Backup successfully started.
Session Key: R-2014/04/04-23
[Normal] From: BSM@server.domain "CS_Backup_FS"  Time: 04.04.2014 11:01:57
	The exec script "EADR_CS_FSBackup_Post.cmd" has completed.

Beispiel Session Messages der IDB Sicherung:

[Normal] From: BSM@server.domain "CS_Backup_IDB"  Time: 04.04.2014 12:09:50
	Starting to execute "EADR_CS_IDBBackup_Post.cmd"...


Starting the EADR preparation process

Script Environment: host='SERVER' user='DOMAIN\user' 
                    script='D:\Program Files\OmniBack\bin\EADR_CS_IDBBackup_Post.cmd' 
                    path='D:\Program Files\OmniBack\bin\' 
Creating the ISO image ...
[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:09:55
	Creating the Disaster Recovery ISO image file. This may take a few minutes...

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:09:55
	Initializing MiniOS directory structure.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:09:55
	Mounting MiniOS image.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Inserting Recovery Info file into the MiniOS image file.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Inserting hardware information file into the MiniOS image file.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Inserting network information file into the MiniOS image file.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Inserting ASR BCD file into the MiniOS image file.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Copying MiniOS system files to the image file.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Copying DRM binaries to the image file.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Copying DRM configuration directory to the image file.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Copying backup application depot directory to the image file.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Storing phase 0 log file into the Recovery Set archive.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Configuring vendor specific system images.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Creating the MiniOS image startup file.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:00
	Installing additional MiniOS packages.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:10:17
	Installing additional MiniOS packages.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:11:04
	Installing additional MiniOS packages.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:11:09
	Installing additional MiniOS packages.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:11:15
	Installing additional MiniOS packages.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:11:20
	Installing additional MiniOS packages.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:11:25
	Installing additional MiniOS packages.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:11:32
	Installing additional MiniOS packages.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:11:39
	Cleaning up MiniOS image, preparing it for usage.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:11:39
	Injecting driver files into the MiniOS image.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:11:56
	Initializing MiniOS scratch space.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:11:57
	Dismounting/Committing MiniOS image.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:12:18
	Writing CD-ROM ISO image to the target location.

[Normal] From: omniiso@server.domain "omniiso"  Time: 04.04.2014 12:12:18
	Successfully created the Disaster Recovery ISO image.

Saving information about used media ...
Copying generated ISO file and information about used media to network share ...
        1 Datei(en) kopiert.
        1 Datei(en) kopiert.
        1 Datei(en) kopiert.
Finished
[Normal] From: BSM@server.domain "CS_Backup_IDB"  Time: 04.04.2014 12:12:26
	The exec script "EADR_CS_IDBBackup_Post.cmd" has completed.

Wer Data Protector kennt, weiß dass Anpassungen von Parametern über die Datei global und omnirc durchgeführt werden. Die Datei global wird auf dem Cell Server verwaltet, während die Datei omnirc (Linux/HP-UX: /opt/omni, Windows 2008 C:\programdata\omniback) auf jedem Client einzeln angepasst werden muss. Üblicherweise pflegt der Data Protector Administrator eine Version der Datei omnirc auf dem Cell Server und verteilt sie dann manuell auf die Clients, da bisher ein Verteilmechanismus nicht zur Verfügung stand.

Mit Data Protector 8.11 gibt es jetzt eine Möglichkeit die Datei omnirc über den Cell Server für den Client zu bearbeiten. Dafür wurde das Kommando util_cmd erweitert.

util_cmd -setomnirc <hostname> <name> [<value>]
util_cmd –getomnirc <hostname> <name>

name      – the name of the environment variable written in DP omnirc file.
hostname  – the name of the host on which to modify omnirc or get omnirc value from
value     – the value of environment variable to be added or modified in omnirc file.

Wenn der Wert nicht mehr gültig ist, so wird er aus der Datei entfernt. Wenn die Datei omnirc noch nicht existiert, so wird sie angelegt. Wenn eine Variable bereits existiert, so wird der Wert in der Datei geändert, andernfalls wird die neue Variable an das Ende der Datei angehangen. Zusätzlich kann das Kommando zum Auslesen von Variablen aus einer omnirc eines Clients genutzt werden.

Beispiel als Vorlage zur weiteren Automatisierung der Verteilung der omnirc Datei (Lesen einer nicht existierenden Variable, Setzen einer Variable, Lesen einer existierenden Variable):

C:\Program Files\OmniBack\bin>util_cmd.exe -getomnirc w2012r2dp.localdomain OB2IPCKEEPALIVE
*RETVAL*0

C:\Program Files\OmniBack\bin>util_cmd.exe -setomnirc w2012r2dp.localdomain OB2IPCKEEPALIVE 1
*RETVAL*0

C:\Program Files\OmniBack\bin>util_cmd.exe -getomnirc w2012r2dp.localdomain OB2IPCKEEPALIVE
1
*RETVAL*0

Ein neues Video Tutorial wurde hinzugefügt. Das Video zeigt den HP Backup Navigator im Einsatz. Das Video kann unter http://www.data-protector.org/wordpress/videotutorials/ angesehen werden. Danke an Uli für das Aufnehmen. Das Video steht in Deutsch und Englisch zur Verfügung.

Ein neues Video Tutorial wurde hinzugefügt. Das Video zeigt den HP Data Protector, Teil 1 zeigt einige Basics, die Architektur und Lizenzierung. Das Video kann unter http://www.data-protector.org/wordpress/videotutorials/ angesehen werden. Das Video steht in Englisch zur Verfügung.