Wenn der Patch DPWIN_00483 (VEPA Patch) installiert ist, kann man auf dem Client über die GUI kein Backup (Exchange, SQL, …) mehr anlegen. In der GUI bleibt ausgegraut nach der Instanz zu browsen. Die Ursache hierfür ist ein Bug in der ausgetauschten manager.exe durch den Patch DPWIN_000483. Als Workaround kann hier die JAVA GUI genutzt werden in der dieses Verhalten nicht sichtbar ist. HP hat hierzu auch ein Advisory herausgegeben, siehe Advisory Sektion.
Aktuelle Patches
UPDATE 17.12.2010: Auf Grund neuer Patches und zur besseren Übersichtlichkeit wird die Liste der aktuellen Patches zukünftig unter „Current Patches“ weitergeführt.
Nachfolgend eine Liste der aktuellen Patches. Dieser Artikel wird geändert, sobald neue Patches erscheinen (Patches vor Juni 2010 werden hier nicht gelistet) – alle Angaben gültig für Data Protector 6.11, die neuen Patches stehen immer oben:
- Herbst 2010 – Es wurden ergänzende Patches freigegeben, welche auf den GR Patches von Juli aufbauen. Somit behält die Liste vom 08.07.2010 ihre Gültigkeit, ergänzt um diese Patches:
- Windows: SharePoint GRE – DPWIN_00482, SQL – DPWIN_00480, DA – DPWIN_00478, SAP – DPWIN_00474, VEPA – DPWIN_00483
- HP-UX (PA-RISC): SAP – PHSS_41311,
- HP-UX (IA64): SAP – PHSS_41312
- Linux: SAP – DPLNX_00132
- Solaris: SAP – DPSOL_00426
- 08.07.2010 – Es wurden komplett neue Patches herausgebracht, auch wenn die einzelnen Release Tage von einem anderen Datum sind wurden diese jedoch erst am 08.07.2010 im Web verfügbar gemacht. Die folgenden Patches stellen somit den momentan kompletten Stand der verfügbaren Patches dar:
- Windows: AUTODR – DPWIN_00461, CC – DPWIN_00457, CORE – DPWIN_00455, CS – DPWIN_00456, DA – DPWIN_00459 (obsolete), DOKU – DPWIN_00464, JAVAGUI – DPWIN_00458, MA – DPWIN_00460, ORA – DPWIN_00454, SMIS – DPWIN_00462, VMware – DPWIN_00467, XP – DPWIN_00463
- HP-UX (PA-RISC): AUTODR – PHSS_40823, CC – PHSS_40815, CORE – PHSS_40811, CS – PHSS_40813, DA – PHSS_40819, DOKU – PHSS_40829, JAVAGUI – PHSS_40817, MA – PHSS_40821, ORACLE – PHSS_40622, SMIS – PHSS_40825, VMWARE – PHSS_41127, XP – PHSS_40827
- HP-UX (IA64): AUTODR – PHSS_40824, CC – PHSS_40816, CORE – PHSS_40812, CS – PHSS_40814, DA – PHSS_40820, DOKU – PHSS_40830, JAVAGUI – PHSS_40818, MA – PHSS_40822, ORACLE – PHSS_40623, SMIS – PHSS_40826, VMWARE – PHSS_41128, XP – PHSS_40828
- Linux: AUTODR – DPLNX_00120, CC – DPLNX_00116, CORE – DPLNX_00114, CS – DPLNX_00115, DA – DPLNX_00118, DOKU – DPLNX_00123, JAVAGUI – DPLNX_00117, MA – DPLNX_00119, ORACLE – DPLNX_00113, SMIS – DPLNX_00121, VMWARE – DPLNX_00125, XP – DPLNX_00122
- Solaris: AUTODR – DPSOL_00414, CC – DPSOL_00410, CORE – DPSOL_00408, CS – DPSOL_00409, DA – DPSOL_00412, DOKU – DPSOL_00417, JAVAGUI – DPSOL_00411, MA – DPSOL_00413, ORACLE – DPSOL_00407, SMIS – DPSOL_00415, VMWARE – DPSOL_00419, XP – DPSOL_00416
- 02.07.2010 – Solaris VMware Patch – DPSOL_00419
- 02.07.2010 – HP-UX IA64 VMware Patch – PHSS_41128
- 02.07.2010 – LinuxVMware Patch – DPLNX_00125
- 02.07.2010 – HP-UX PA-Risc VMware Patch – PHSS_41127
- 30.06.2010 – Windows VMware Patch – DPWIN_00467
Recover Cell Server
In einem früheren Beitrag habe ich berichtet wie man einen Windows 2003 Server mit der Enhanced Automated Disaster Recovery Option wiederherstellt. Was ist aber mit dem Cell server selbst? Auch hierfür muss man sich entsprechend vorbereiten. Die nachfolgenden Schritte gelten prinzipiell für Cell Server unter allen Betriebssystemen und stellen 1 Variante von verschiedenen dar.
Eine wichtige Komponente 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 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.
Tritt nun der Desaster Fall ein, so kann man prinzipiell folgende Schritte anwenden:
Initialization of medium failed – filelibrary full
Der Fehler Initialization of medium failed wird gemeldet wenn die Filelibrary (ein oder mehrere Mountpoints der Filelibrary) mal vollgelaufen ist. Wenn die GR Patches vom Juli 2010 noch nicht eingespielt wurden, so kann man in diesem Zusammenhang im entsprechenden Mountpoint / Verzeichnis der Filelibrary jede Menge Medien mit blauem Fragezeichen sehen. Zusätzlich ist zu beobachten dass ein Export der MMDB (omnidbutil -writedb -mmdb Verzeichnis) eine sehr große Größe der cart.txt anzeigt.
Als erste Lösung ist der Plattenplatz entsprechend zu erweitern oder Medien von der Filelibrary auf ein anderes Medium zu migrieren, so das man freien Plattenplatz erhält. Im zweiten Schritt kann probiert werden die Medien mit blauem Fragezeichen zu formatieren.
Sollte dies nicht helfen so kann folgende Prozedur benutzt werden:
omnidownload -library Libraryname -file Filenameomniupload -modify_library Library -file FileNameIn jedem Fall sind die GR Patches vom Juli 2010 einzuspielen, da der Fehler schon seit geraumer Zeit behoben wurde.
Sollten die Fehler nach dieser Prozedur immer noch auftreten, so empfehle ich die Filelibrary komplett zu leeren (Migrieren der Medien aus der betroffenen Fiellibrary auf ein anderes Medium) und in der cart.txt die nicht benötigten (besser falschen) Einträge zu entfernen. Was aber in der cart.txt zu löschen ist erkläre ich hier nicht, da dieser Weg nicht supportet ist. Gegen Einwurf kleiner Geldscheine übernehme ich diese Arbeit gern in einer Remote Session.
SystemState Backup Windows – Error [81:52]
Bei Windows Sicherung und installiertem Automated Disaster Recovery Modul kann es manchmal passieren das man bei einer Sicherung des Systemstates von Windows (Configurationssicherung) diese Meldung erhält.
[Critical] From: VBDA@CLIENT "CONFIGURATION:" Time: 21.09.2010 09:20:32
[81:52] /CONFIGURATION
Not a valid mount point => aborting
Die Erklärung wenn man auf den Link drückt ist dabei leider nicht hilfreich. Im debug.log stehen keine verwertbaren Informationen und ein autodr.log wurde nicht erstellt, da die Sicherung vorher abbricht. In der Regel hilft hier ein Reboot des Servers, ist aber nicht immer notwendig. In meinem Fall hatte es geholfen den zu sichernden Server mal genauer anzuschauen und ein Blick in <omnihome>\tmp\config zeigte das hier noch Reste der Configurationssicherung aus einem früheren Backupjob lagen (vermutlich eine abgebrochene Sicherung). Ich hatte einfach alles in <omnihome>\tmp\config gelöscht und dann funktionierte auch wieder die Sicherung des Systemstates von diesem Windows Server.