{"id":694,"date":"2011-07-29T18:17:17","date_gmt":"2011-07-29T16:17:17","guid":{"rendered":"http:\/\/www.data-protector.org\/wordpress\/?p=694"},"modified":"2015-12-10T09:49:38","modified_gmt":"2015-12-10T08:49:38","slug":"data-protector-migration-unix-to-other-os","status":"publish","type":"post","link":"https:\/\/www.data-protector.org\/wordpress\/de\/2011\/07\/data-protector-migration-unix-to-other-os\/","title":{"rendered":"Data Protector Migration Unix to other OS"},"content":{"rendered":"

Ich kenne nicht viele gute Gr\u00fcnde warum man eine Data Protector Installation von HP-UX auf ein anderes Betriebssystem wechseln sollte, dennoch gibt es viele Kunden die diesen Schritt gehen wollen und zum Beispiel auf Windows oder Linux wechseln; meist noch verbunden mit einem Upgrade auf eine aktuelle Version von Data Protector. Und hier genau steckt das Problem: es gibt keinen Migrationspfad. Der Grund hierf\u00fcr ist ganz einfach, die DCBF Verzeichnisse zwischen UNIX und den anderen Betriebssystemen sind nicht kompatibel und somit gibt es keine M\u00f6glichkeit mit zum Beispiel einen Export und Import der internen Datenbank auf Linux zu wechseln. Die DCBF Verzeichnisse unter HP-UX sind im big-endian und auf Linux im little-endian Format abgelegt und hierf\u00fcr gibt es kein Migrationstool. Was diese Formate kennzeichnet kann man bei einer Suchmaschine sehr schnell nachlesen.<\/p>\n

Der Artikel ist recht umfangreich, es werden ca. 30 Minuten zum Durcharbeiten des Artikels ben\u00f6tigt, der Artikel richtet sich an Data Protector Experten. Am Ende des Artikels ist dann auch der Downloadlink f\u00fcr die verwendeten Export und Import Skripte.<\/p>\n

Auf Grund der oben beschriebenen Problematik ist das einzige was man daher von einem HP-UX Cell Server migrieren kann das Verzeichnis \/etc\/opt\/omni<\/code> (die Backup Jobs, Schedules, …). Wie man trotzdem ganz leicht eine Migration vornehmen kann zeige ich nachfolgend am Beispiel HP-UX 11.11 – DP 6.11 nach Windows 2008 R2 – DP 6.2. Das Wesentliche was hierf\u00fcr notwendig ist: das Importieren der B\u00e4nder in die neue Zelle. Ich habe durchaus schon Kunden gehabt die zwischen 500 und 2000 B\u00e4nder importieren mussten. Und erst mit dem Import der B\u00e4nder in die neue Zelle erh\u00e4lt man wieder die Historie (Restoref\u00e4higkeit) da bei dem Vorgang die DCBF Verzeichnisse wieder gef\u00fcllt und die Filename Versions wieder importiert werden. Diesen Schritt scheuen allerdings sehr viele Kunden da nur wenigen bekannt ist das man bei diesem Vorgang kein einziges Band in die Hand nehmen muss, es wurde mit Einf\u00fchrung von Data Protector 6.11 ein spezielles Kommando eingef\u00fchrt der einen Export des Katalogs erm\u00f6glicht.<\/p>\n

Im weiteren Verlauf des Artikels wird die Migration von HP-UX 11.11 auf Windows 2008 R2 und somit ein Migrationspfad aufgezeigt. Die durchzuf\u00fchrenden Schritte stellen nur einen von mehreren m\u00f6glichen Varianten dar, im besonderen sind die Bedingungen am Ende des Artikels f\u00fcr eine erfolgreiche Migration zu beachten.<\/p>\n

Folgende Schritte werden bei der Migration angewandt (es sind nur die wesentlichen Schritte dokumentiert):\n<\/p>\n

1<\/b> Installation des neuen Cell Servers auf Windows 2008 R2<\/p>\n

2<\/b> Library \/ Laufwerk:<\/p>\n

2.1<\/b> physikalischer Umbau und Anschluss an den neuen Cell Server bei SCSI Library<\/p>\n

2.2<\/b> \u00c4nderung des Zoning auf den neuen neuen Cell Server bei FC Library<\/p>\n

3<\/b> Konfiguration des neuen Cell Servers:<\/p>\n

3.1<\/b> global,<\/p>\n

3.2<\/b> omnirc,<\/p>\n

3.3<\/b> Hinzuf\u00fcgen weiterer DCBF Verzeichnisse, z.B.:<\/p>\n

omnidbutil -add_dcdir \"D:\\ProgramData\\OmniBack\\db40\\dcbf1\" -seq 1<\/code><\/p>\n

omnidbutil -add_dcdir \"D:\\ProgramData\\OmniBack\\db40\\dcbf2\" -seq 2<\/code><\/p>\n

3.4<\/b> Hinzuf\u00fcgen von Filenames Extension Files, z.B.: (mehrmaliges Ausf\u00fchren f\u00fcgt mehrere Erweiterungen hinzu)<\/p>\n

omnidbutil -extendfnames \"D:\\ProgramData\\OmniBack\\db40\\datafiles\\cdb\" -maxsize 2047<\/code><\/p>\n

3.5<\/b> weitere Optimierungen nach Bedarf (z.B.: Archiving – siehe Artikel zu obrindex.dat)<\/p>\n

4<\/b> Deaktivieren des Schedules auf dem alten Cell Server mit dem Befehl \/opt\/omni\/sbin\/omnitrig -stop<\/code> (das entfernt den crontab Eintrag)<\/p>\n

5<\/b> Export der Clients aus der alten Zelle mit omnicc -export_host <Hostname><\/code>, wobei f\u00fcr Hostname der identische Name verwendet werden muss wie er auch im cell_info File steht. Zur Automatisierung kann man ein \"cat\"<\/code> auf das cell_info File machen und \u00fcber awk nur den Hostnamen ausgeben lassen und den Output in einem Shell Skript weiter verarbeiten. Aber nicht vergessen den Output zu sichern, die Hostnamen werden wieder f\u00fcr den Import ben\u00f6tigt. Beispiel f\u00fcr den Export:<\/p>\n

MYHOSTS=$(cat \/etc\/opt\/omni\/config\/server\/cell\/cell_info | awk '{print $2}')<\/code><\/p>\n

for EXPORTHOST in ${MYHOSTS}<\/code><\/p>\n

do<\/code><\/p>\n

\/opt\/omni\/bin\/omnicc -export_host ${EXPORTHOST}<\/code><\/p>\n

done<\/code><\/p>\n

6<\/b> Falls noch weitere Installation Server zus\u00e4tzlich zum Cell Server existieren und diese in der neuen Zelle ben\u00f6tigt werden so k\u00f6nnen die Server mit dem Befehl omnicc -export_is <hostname><\/code> auch exportiert werden (Outut sichern, damit die Server sp\u00e4ter wieder importiert werden k\u00f6nnen).<\/p>\n

7<\/b> Import der Clients in die neue Zelle, die Hostnamen sind ja noch aus dem Export bekannt. Der verwendete Befehl f\u00fcr den Import ist omnicc -import_host <Hostname><\/code>, f\u00fcr den Import gelten die gleichen Angaben wie beim Export.<\/p>\n

8<\/b> Import der zus\u00e4tzlichen Installation Server in die neue Zelle mit dem Befehl omnicc -import_is <hostname><\/code>. Wenn der Installation Server auch aktualsiert werden muss, so erfolgt die Installation der Software auf dem Installation Server lokal und manuell. Achtung: Die Installation der Patches sollte nicht vergessen werden, sofern Patches verf\u00fcgbar sind. Falls es in der neuen Zelle noch ein Installation Server f\u00fcr Linux\/Unix ben\u00f6tigt wird, ein RedHat oder SLES (beides nur 64 Bit) ist unter VMware schnell installiert, die Installation des IS ist mit einem Aufruf schnell realisiert.<\/p>\n

9<\/b> Upgrade der Clients auf die aktuelle Data Protector Version (Achtung: wer noch Windows 2000 Clients hat, bel\u00e4sst diese auf dem letzten Stand der Client Software da DP 6.2 kein Windows 2000 mehr unterst\u00fctzt; diese Konfig ist supported f\u00fcr die Funktionen die in dieser Version enthalten sind. Es wird unter Umst\u00e4nden eine 6.11er GUI f\u00fcr den Import der Windows 2000 Clients ben\u00f6tigt.). F\u00fcr die Aktualisierung oder Neuinstallation der Linux \/ Unix Clients muss unter Umst\u00e4nden noch der SSH Key auf dem Installation Server erstellt werden und auf die Clients verteilt werden.<\/p>\n

10<\/b> Pools und Devices auf dem neuen Cell Server anlegen:<\/p>\n

10.1<\/b> Hier k\u00f6nnen in kleinen Umgebungen die Libraries, Laufwerke und Pools neu angelegt werden. Diese Vorgehensweise bietet auch die M\u00f6glichkeit sich von „historisch gewachsenen“ Unmengen von Pools zu trennen, in der Regel reichen in mittelst\u00e4ndischen Umgebungen maximal 10 Medienpools aus um alle F\u00e4lle abdecken zu k\u00f6nnen. Das gleiche gilt f\u00fcr die Laufwerke, hier m\u00f6chte man vielleicht endlich von der Blocksize 64k auf einen h\u00f6heren Wert von 256k oder auch 512k wechseln (abh\u00e4ngig vom Controller und den Laufwerken).<\/p>\n

10.2<\/b> L\u00f6schen von nicht ben\u00f6tigten Pools, am einfachsten per Skript, es werden alle Pools au\u00dfer \"Default File\"<\/code> und \"Default LTO-Ultrium\"<\/code> gel\u00f6scht:<\/p>\n

omnimm -remove_pool \"Default AIT\"<\/code><\/p>\n

omnimm -remove_pool \"Default DDS\"<\/code><\/p>\n

omnimm -remove_pool \"Default DLT\"<\/code><\/p>\n

omnimm -remove_pool \"Default DTF\"<\/code><\/p>\n

omnimm -remove_pool \"Default Exabyte\"<\/code><\/p>\n

omnimm -remove_pool \"Default Optical\"<\/code><\/p>\n

omnimm -remove_pool \"Default QIC\"<\/code><\/p>\n

omnimm -remove_pool \"Default SAIT\"<\/code><\/p>\n

omnimm -remove_pool \"Default SD-3\"<\/code><\/p>\n

omnimm -remove_pool \"Default SuperDLT\"<\/code><\/p>\n

omnimm -remove_pool \"Default T10000\"<\/code><\/p>\n

omnimm -remove_pool \"Default T3480\/T4890\/T9490\"<\/code><\/p>\n

omnimm -remove_pool \"Default T3590\"<\/code><\/p>\n

omnimm -remove_pool \"Default T3592\"<\/code><\/p>\n

omnimm -remove_pool \"Default T9840\"<\/code><\/p>\n

omnimm -remove_pool \"Default T9940\"<\/code><\/p>\n

omnimm -remove_pool \"Default Tape\"<\/code><\/p>\n

11<\/b> neue Pools per Skript anlegen, z.B.:<\/p>\n

omnimm -create_free_pool \"FreePool\" \"LTO-Ultrium\" 60 250<\/code><\/p>\n

omnimm -create_pool \"Filesystem\" \"LTO-Ultrium\" -free_pool \"FreePool\"<\/code><\/p>\n

omnimm -create_pool \"Database\" \"LTO-Ultrium\" -free_pool \"FreePool\"<\/code><\/p>\n

omnimm -create_pool \"DataProtectorInternalDatabase\" \"LTO-Ultrium\" -no_free_pool -no_move_free_media<\/code><\/p>\n

12<\/b> Laufwerke und Libraries anlegen:<\/p>\n

12.1<\/b> Hierf\u00fcr kann man entweder die „Auto configure“ Funktion von Data Protector nutzen.<\/p>\n

12.2<\/b> Das Tool sanconf, die Beschreibung steht im Client Reference Guide, funktioniert sehr zuverl\u00e4ssig.<\/p>\n

12.3<\/b> Download der Libraries und Laufwerke mit dem Befehl omnidownload auf dem alten Cell Server, Bearbeiten der Dateien und Anpassung der Hostnamen, \u00dcbertragen der ge\u00e4nderten Dateien auf den neuen Cell Server, Anlage der Libraries und Laufwerke mit dem Befehl omniupload auf dem neuen Cell Server.<\/p>\n

12.4<\/b> Eine weitere Alternative ist das Tool savedevices (findet ihr hier in www.data-protector.org), allerdings ist dies in der momentanten Version nur f\u00fcr Migrationen zwischen Windows einsetzbar, f\u00fcr Unix \/ Linux muss es noch angepasst werden.<\/p>\n

12.5<\/b> die letzte Alternative w\u00e4re der Export der mmdb, der anschlie\u00dfende Import der mmdb und das abschlie\u00dfende L\u00f6schen aller B\u00e4nder in der neuen Zelle, da diese ja sp\u00e4ter erst durch die Skripte importiert werden. Im Abschluss muss noch der Cell Servername korrigiert werden, da beim Import die Laufwerke noch dem alten Cell Server „geh\u00f6ren“. Die Befehle hierf\u00fcr w\u00e4ren zum Beispiel:<\/p>\n

omnidbutil -writedb -mmdb \/<ein Export Verzeichnis><\/code> – im Anschluss wird der Ordner auf den neuen Cell Server, z.B. nach c:\\temp<\/code> kopiert.<\/p>\n

omnidbutil -readdb -mmdb c:\\temp<\/code><\/p>\n

omnidbutil -change_cell_name [<alter cell server>]<\/code><\/p>\n

13<\/b> Selektives Kopieren der Inhalte aus dem alten \/etc\/opt\/omni<\/code> Verzeichnis auf den neuen Cell Server, hier macht es unter Windows Sinn mit dem Tool unix2dos die Dateien wegen der „anderen“ Zeilenumbr\u00fcche in das DOS Format zu \u00fcbertragen. Wichtige Verzeichnisse sind hierbei in der Regel (kein Anspruch auf Vollst\u00e4ndigkeit):<\/p>\n

13.1<\/b> barlists<\/p>\n

13.2<\/b> barschedules<\/p>\n

13.3<\/b> datalists<\/p>\n

13.4<\/b> schedules<\/p>\n

13.5<\/b> copylists<\/p>\n

13.6<\/b> consolidationlists<\/p>\n

13.7<\/b> integ<\/p>\n

Von der userlist im Users Verzeichnis sollten nur die Eintr\u00e4ge \u00fcbertragen werden welche die eigenen Benutzer darstellen. Die ersten 3-4 Zeilen auf dem neuen Cell Server wurden bei der Installation des Cell Servers angelegt, ein \u00dcberschreiben dieser Eintr\u00e4ge kann den Zugriff auf den Cell Server verhindern.<\/p>\n

Damit sind die vorbereitenden Arbeiten abgeschlossen und der neue Cell Server w\u00e4re nun auch schon einsatzbereit und fertig, jetzt m\u00fcssen nur noch die Informationen von den alten B\u00e4ndern und die B\u00e4nder in den neuen Cell Server importiert werden. Zu Beginn des Artikels habe ich schon erw\u00e4hnt das f\u00fcr diesen Prozess kein einziges Band bewegt werden muss das es hierf\u00fcr seit Data Protector 6.11 einen Befehl gibt. Die notwedigen Befehle habe ich in 2 Skripten zusammengefasst, einem exportcatalog.pl und einem importcatalog.pl Perl Skript; beide k\u00f6nnen nach Belieben angepasst und erweitert werden. Da f\u00fcr die Skripte bestimmte Bedingungen erf\u00fcllt sein m\u00fcssen, verweise ich auch nochmals auf die genannten Bedingungen am Ende des Artikels. Beim Export des Katalogs auf dem Unix Cell Server werden die Dienste des Cell Servers nach jedem erfolgreichen Export eines Mediums neu gestartet. Der Grund ist hierf\u00fcr der hohe Memory Verbrauch des RDS Daemons beim Export, der zum Crash des RDS Dienstes f\u00fchren kann, wer das nicht braucht kommentiert es einfach aus. Zus\u00e4tzlich habe ich in der .omnirc<\/code> den _M_ARENA<\/code> Parameter auf 1:32<\/code> gesetzt und in der rdmserver.ini<\/code> die Threads auf 32 begrenzt. Sollte jemand auf gleiche Probleme sto\u00dfen und detailliertere Informationen zu den Einstellungen und Hintergr\u00fcnden ben\u00f6tigen, so kann ein Kommentar hinterlassen werden oder besser per Mail mit mir Kontakt aufgenommen werden.<\/p>\n

Nun zu den Skripten:\n<\/p>\n

Export:\n<\/p>\n

1<\/b> Das Skript wird mit perl exportcatalog.pl aufgerufen, eine Installation von Perl ist nicht notwendig, die Module die durch Data Protector installiert werden sind ausreichend.<\/p>\n

2<\/b> Das Skript auf Unix wurde mit Perl und Betriebssystemkommandos realisiert. Bei Bedarf (Spende) kann eine komplette \u00dcbersetzung auf Shell realisiert werden.<\/p>\n

3<\/b> exportcatalog.pl:<\/p>\n

\r\n
# define the pools on source cell server<\/code><\/p>\r\n
# all the pools must exist before starting the script<\/code><\/p>\r\n
# it is recommended to move 100-200 pools to the transfer pool<\/code><\/p>\r\n
# once all media are exported, continue with next 100-200 media<\/code><\/p>\r\n
<\/code><\/p>\r\n
# in this pool we search for our media<\/code><\/p>\r\n
my $pool=\"_TransferPool\";<\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# on error we move the media to failed pool<\/code><\/p>\r\n
my $errorpool=\"_TransferPoolError\"; <\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# once the media is exported it will be moved to a new pool<\/code><\/p>\r\n
my $successpool=\"Z_MediaExported\"; <\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# define the paths we need during the export when no search path is set<\/code><\/p>\r\n
my $omni_bin=\"\/opt\/omni\/bin\/\";<\/code><\/p>\r\n
my $omni_sbin=\"\/opt\/omni\/sbin\/\";<\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# the directory to store the mcf files, a separate mount point was created for the migration<\/code><\/p>\r\n
my $output=\"\/exportcatalog\"; <\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# other stuff we need<\/code><\/p>\r\n
my $command;<\/code><\/p>\r\n
my @media;<\/code><\/p>\r\n
my $media;<\/code><\/p>\r\n
my $mediumid;<\/code><\/p>\r\n
my $result;<\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# this will return the media ID - [XX1234L2] for all media in the transfer pool<\/code><\/p>\r\n
$command=$omni_bin.\"omnimm -list_pool \".$pool.\" \\| awk \\'\\{print \\$2\\}\\'\";<\/code><\/p>\r\n
@media=`$command`;<\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# nextlines will do the export<\/code><\/p>\r\n
foreach $media (@media)<\/code><\/p>\r\n
{<\/code><\/p>\r\n
  # next 3 lines to restart DP in case we have a memory problem with RDS (this makes the export faster)<\/code><\/p>\r\n
  $command=$omni_sbin.\"omnisv -stop\"; `$command`;<\/code><\/p>\r\n
  $command=$omni_sbin.\"omnisv -start\"; `$command`;<\/code><\/p>\r\n
  $command=$omni_sbin.\"omnitrig -stop\"; `$command`;<\/code><\/p>\r\n
<\/code><\/p>\r\n
  chomp $media;<\/code><\/p>\r\n
  # remove the brackets from the media ID - [XX1234L2] --> XX1234L2<\/code><\/p>\r\n
  $media=~ s\/\\[\/\/ig;<\/code><\/p>\r\n
  $media=~ s\/\\]\/\/ig;<\/code><\/p>\r\n
  <\/code><\/p>\r\n
  # we only run if we have a media<\/code><\/p>\r\n
  if (($media ne \"Medium\") && ($media ne \"\"))<\/code><\/p>\r\n
  {<\/code><\/p>\r\n
    print \"working on media: \".$media.\"\\n\";<\/code><\/p>\r\n
    $command=$omni_bin.\"omnimm -copy_to_mcf \".$media.\" -output_directory \".$output.\" > \".$output.\"\/\".$media.\".txt\";<\/code><\/p>\r\n
    `$command`;<\/code><\/p>\r\n
    $command=\"cat \".$output.\"\/\".$media.\".txt \\| grep \\'1 out of 1\\'\";<\/code><\/p>\r\n
    $result=`$command`;<\/code><\/p>\r\n
    if (!($result =~ \/1 out of 1 catalog\\(s\\) successfully copied to file\\(s\\).\/))<\/code><\/p>\r\n
    {<\/code><\/p>\r\n
      print \"ERROR: export of media failed - moving to error pool\\n\\n\";<\/code><\/p>\r\n
      $command=$omni_bin.\"omnimm -move_medium \".$media.\" \".$errorpool;<\/code><\/p>\r\n
      `$command`;<\/code><\/p>\r\n
    }<\/code><\/p>\r\n
    else<\/code><\/p>\r\n
    {<\/code><\/p>\r\n
      print \"SUCCESS: media exported - moving to success pool\\n\";<\/code><\/p>\r\n
      $command=$omni_bin.\"omnimm -move_medium \".$media.\" \".$successpool;<\/code><\/p>\r\n
      `$command`;<\/code><\/p>\r\n
      $command=\"cat \".$output.\"\/\".$media.\".txt \\| grep \\' ('\";<\/code><\/p>\r\n
      $result=`$command`;<\/code><\/p>\r\n
      ($dummy, $mediumid)=split(\/\\(\/,$result,2);<\/code><\/p>\r\n
      $mediumid=~ s\/\\)\/\/ig;<\/code><\/p>\r\n
      $mediumid=~ s\/\\.\/\/ig;<\/code><\/p>\r\n
      $mediumid=~ s\/\\:\/_\/ig;<\/code><\/p>\r\n
      chomp $mediumid;<\/code><\/p>\r\n
      print \"renaming mcf file \".$mediumid.\".mcf to done_\".$mediumid.\".mcf\\n\\n\";<\/code><\/p>\r\n
      $command=\"mv \".$output.\"\/\".$mediumid.\".mcf \".$output.\"\/done_\".$mediumid.\".mcf\";<\/code><\/p>\r\n
      `$command`;<\/code><\/p>\r\n
      ### you may want to ftp the files afterwards to a different server when not picked up from the UNIX server<\/code><\/p>\r\n
      $command=\"chmod 777 \".$output.\"\/done_\".$mediumid.\".mcf\";<\/code><\/p>\r\n
      `$command`;<\/code><\/p>\r\n
    }<\/code><\/p>\r\n
  }<\/code><\/p>\r\n
}<\/code><\/p>\r\n
<\/code><\/p><\/pre>\n
Import:\n<\/p>\n
1<\/b> Das Skript wird mit perl importcatalog.pl<\/code> aufgerufen, eine Installation von Perl ist nicht notwendig, die Module die durch Data Protector installiert werden sind ausreichend.<\/p>\n
2<\/b> F\u00fcr einen permanenten Import bereits exportierter B\u00e4nder wird empfohlen einen Scheduled Task auf dem neuen Cell Server mit dem Aufruf f\u00fcr die Dauer der Migration einzurichten.<\/p>\n
3<\/b> Alle weiteren Dinge stehen als Kommentare im Skript.<\/p>\n
4<\/b> importcatalog.pl:<\/p>\n
\r\n
# the same pool we used during the export, all media will be imported here<\/code><\/p>\r\n
my $pool=\"_TransferPool\";<\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# on the UNIX server a samba shared was used to export the catalog<\/code><\/p>\r\n
# so we use the share to pickup the mcf files<\/code><\/p>\r\n
# when samba cannot be configured you could enhance the exportcatalog.pl to upload<\/code><\/p>\r\n
# the mcf files to another server using i.e. FTP<\/code><\/p>\r\n
# my $source=\"Z:\\\\Migration\\\\exportedmedia\\\\\";<\/code><\/p>\r\n
# aternate source (line above) should be used when Samba is not used<\/code><\/p>\r\n
my $source=\"\\\\\\\\unixserver\\\\exportcatalog\\\\\";<\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# our working directory and the directory when the import is done<\/code><\/p>\r\n
my $destination1=\"Z:\\\\Migration\\\\working\\\\\";<\/code><\/p>\r\n
my $destination2=\"Z:\\\\Migration\\\\done\";<\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# other stuff we need<\/code><\/p>\r\n
my $command;<\/code><\/p>\r\n
my @media;<\/code><\/p>\r\n
my $media;<\/code><\/p>\r\n
my $mediumid;<\/code><\/p>\r\n
my $result;<\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# we copy (no movement before import was successful) the mcf file to the working directory <\/code><\/p>\r\n
$command=\"copy \".$source.\"done*.mcf \".$destination1; `$command`;<\/code><\/p>\r\n
<\/code><\/p>\r\n
# we build the array of files to be imported<\/code><\/p>\r\n
$command=\"dir \".$destination1.\"done*.mcf \/o\/b\"; @media=`$command`;<\/code><\/p>\r\n
<\/code><\/p>\r\n
<\/code><\/p>\r\n
# next lines will do the work, on error the mcf file stays in the working directory until manually moved<\/code><\/p>\r\n
foreach $media (@media)<\/code><\/p>\r\n
{<\/code><\/p>\r\n
  chomp $media;<\/code><\/p>\r\n
  print \"working on media: \".$media.\"\\n\";<\/code><\/p>\r\n
  $command = \"omnimm -import_from_mcf \".$destination1.\"\".$media.\" -no_pool_prefix -orig_pool -import_as_original\";<\/code><\/p>\r\n
  $result=`$command`;<\/code><\/p>\r\n
  if (!($result =~ \/1 out of 1 media successfully imported.\/))<\/code><\/p>\r\n
  {<\/code><\/p>\r\n
    print \"ERROR: import of media failed - renaming media\\n\";<\/code><\/p>\r\n
    $command=\"ren \".$destination1.\"\".$media.\" ERROR_\".$media;<\/code><\/p>\r\n
    `$command`;<\/code><\/p>\r\n
  }<\/code><\/p>\r\n
  else<\/code><\/p>\r\n
  {<\/code><\/p>\r\n
    print \"SUCCESS: media imported - moving media to another location\\n\";<\/code><\/p>\r\n
    $command=\"move \".$destination1.\"\".$media.\" \".$destination2; `$command`;<\/code><\/p>\r\n
    $command=\"del \/q \".$source.\"\".$media; `$command`;<\/code><\/p>\r\n
  }<\/code><\/p>\r\n
}<\/code><\/p>\r\n
<\/code><\/p><\/pre>\n
Der Export \/ Import der B\u00e4nder l\u00e4uft mit den Skripten ganz automatisch ab, es ist kein B\u00e4nderwechsel oder \u00e4hnliches notwendig, die Migration l\u00e4uft ganz nebenbei und ben\u00f6tigt nur wenig Kontrollarbeit. In gemischten Umgebungen mit bis zu 500 zu importierenden B\u00e4ndern wird dieser Teil der Migration ca. 1 Woche laufen. Und hier noch der Downloadlink zu den Skripten:<\/p>\n
[wpdm_file id=8]<\/p>\n
Bedingungen:\n<\/p>\n
1<\/b> Der alte Zell Server bleibt f\u00fcr die Migration und den Abschluss des Imports der B\u00e4nder bestehen.<\/p>\n
2<\/b> Der Cell Server Name und die IP Adresse bleiben auf dem alten Cell Server erhalten (es w\u00e4re auch ein Wechsel m\u00f6glich, daf\u00fcr w\u00e4ren aber Emergency Lizenzen oder EVAL Lizenzen notwendig – bei Bedarf kann man seinen HP Partner, HP Partnerbertreuer oder HP VB anfragen).<\/p>\n
3<\/b> \u00dcber Webware werden die Lizenzen auf die neue IP Adresse ge\u00e4ndert.<\/p>\n
4<\/b> Die Lizenzen werden auf dem neuen Cell Server erst eingetragen wenn der Export der B\u00e4nder auf dem alten Cell Server abgeschlossen wurde – solange verbleibt die neue Zelle mit den 60 Tage Instant On Lizenzen.<\/p>\n
5<\/b> Nach Eintragung der Lizenzen auf dem neuen Cell Server muss der alte Cell Server deaktiviert werden da sonst eine Lizenzverletzung besteht.<\/p>\n
6<\/b> Der alte Cell Server ist auf aktuellem Patchstand, nur dann ist ein Export der B\u00e4nder erfolgreich. Hintergrund: in den Patches vor Mai 2011 gab es ein Problem mit der Option „Log Files, Log Directories, Log Folder, Log All“ beim Exportieren und anschlie\u00dfendem Import der B\u00e4nder.<\/p>\n
7<\/b> In der Datei global wird die Variable EnableMCFCompression=1 aktiviert. Die Variable wird f\u00fcr die Copy Catalog Session ben\u00f6tigt und komprimiert die geschriebene Katalogdatei.<\/p>\n
8<\/b> Es steht ein ausreichend gro\u00dfes Migrationsverzeichnis zur Verf\u00fcgung.<\/p>\n
9<\/b> Die B\u00e4nder haben einen Barcode, falls es keinen Barcode gibt, so muss das Skript angepasst werden, damit die richtige Medium ID bestimmt werden kann.<\/p>\n
10<\/b> Auf dem alten und neuen Cell Server muss perl vorhanden sein, ein einfacher Check mir perl -v pr\u00fcft gibt die installierte Version zur\u00fcck.<\/p>\n
Diese Anleitung ist in dieser Ausf\u00fchrlichkeit nur bei www.data-protector.org zu finden, daher die Bitte an alle Consultants und Endkunden: wenn euch dieser Artikel geholfen hat und ihr in euren Projekten davon profitieren k\u00f6nnt, so w\u00fcrde ich mich daher \u00fcber eine Spende (Donation Button rechts oben) freuen.<\/p>\n","protected":false},"excerpt":{"rendered":"
Ich kenne nicht viele gute Gr\u00fcnde warum man eine Data Protector Installation von HP-UX auf ein anderes Betriebssystem wechseln sollte, dennoch gibt es viele Kunden die diesen Schritt gehen wollen und zum Beispiel auf Windows oder Linux wechseln; meist noch verbunden mit einem Upgrade auf eine aktuelle Version von Data Protector. Und hier genau steckt das Problem: es gibt […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_mi_skip_tracking":false,"spay_email":""},"categories":[11],"tags":[102,14,111,9,20],"translation":{"provider":"WPGlobus","version":"2.8.8","language":"de","enabled_languages":["en","de"],"languages":{"en":{"title":true,"content":true,"excerpt":false},"de":{"title":false,"content":true,"excerpt":false}}},"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p28cjj-bc","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":3004,"url":"https:\/\/www.data-protector.org\/wordpress\/de\/2016\/07\/runbook-migrate-data-protector-7-0x-data-protector-9-0x\/","url_meta":{"origin":694,"position":0},"title":"RUNBOOK \u2013 Migrate Data Protector 7.0x to Data Protector 9.0x","date":"5. Juli 2016","format":false,"excerpt":"{:en} Update 2016\/0705: In section installation source it was recommended to use a patched installation source for the upgrade. This method must not be used for upgrades from Data Protector versionen 8.13 and newer, as it will cause serious damages in the internal database (no fix available\/possible). For versions older\u2026","rel":"","context":"In "HowTo"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1892,"url":"https:\/\/www.data-protector.org\/wordpress\/de\/2014\/03\/migrate-dp-8-xx-dp-8-xx-hardware-ms-windows-operating-system\/","url_meta":{"origin":694,"position":1},"title":"Migrate DP 8.XX to DP 8.XX using new hardware or different MS Windows operating system","date":"26. M\u00e4rz 2014","format":false,"excerpt":"{:en}The migration of the internal database to new hardware or to a new Microsoft Windows operating system was no big deal in the past and before the release of Data Protector 8.xx. With the introduction of PostgreSQL as the new internal database this has been changed and several steps are\u2026","rel":"","context":"In "HowTo"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":3262,"url":"https:\/\/www.data-protector.org\/wordpress\/de\/2016\/12\/migrate-dp-9-0x-dp-9-0x-hardware-microsoft-windows\/","url_meta":{"origin":694,"position":2},"title":"Migrate DP 9.0X to DP 9.0X using new hardware and Microsoft Windows","date":"8. Dezember 2016","format":false,"excerpt":"{:en}I already wrote several articles on how to migrate the internal database to a new hardware, new Data Protector version, or new operating system (see link). With the introduction of PostgreSQL as internal database for Data Protector and compared to previous versions (DP 6 and DP 7), some more steps\u2026","rel":"","context":"In "HowTo"","img":{"alt_text":"writedb","src":"https:\/\/i1.wp.com\/www.data-protector.org\/wordpress\/wp-content\/uploads\/2016\/12\/writedb.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":1787,"url":"https:\/\/www.data-protector.org\/wordpress\/de\/2014\/01\/advisory-dp-8-00-8-10\/","url_meta":{"origin":694,"position":3},"title":"Advisory DP 8.00 \/ 8.10","date":"15. Januar 2014","format":false,"excerpt":"{:en}Data Protector 8.10: With Data Protector 8.10 it is very important to check name resolution before starting the installation. If it's not possible to resolve the FQDN of the cell server (of course short and revers too), a login prompt will appear when opening the GUI (this is the LDAP\u2026","rel":"","context":"In "Advisory"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":150,"url":"https:\/\/www.data-protector.org\/wordpress\/de\/2011\/07\/reorganisation-der-internen-datenbank\/","url_meta":{"origin":694,"position":4},"title":"Internal Database error – reorganize your IDB","date":"15. Juli 2011","format":false,"excerpt":"{:en}Update: There are still a lot of old Data Protector installations (version 6.0, 6.1) and in all cases I've seen there is still the old errror described below. Thats why I updated and enhanced this article from August 2010. When updating from a former Data Protector (5.X to 6.0 to\u2026","rel":"","context":"In "HowTo"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":62,"url":"https:\/\/www.data-protector.org\/wordpress\/de\/2010\/06\/export-import\/","url_meta":{"origin":694,"position":5},"title":"Export \/ Import","date":"28. Juni 2010","format":false,"excerpt":"{:en}No translation for this article available.{:} {:de} Immer wieder mal findet man Anleitungen wie ein Export \/ Import der internen Datenbank von Data Protector vorzunehmen ist. Diese Prozedur wird immer dann eingesetzt wenn Probleme in der Datenbank auftreten (korrupte Medien, ...) - Stichwort Healthcheck und omnidbcheck. Bei der nachfolgenden Prozedur\u2026","rel":"","context":"In "HowTo"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.data-protector.org\/wordpress\/de\/wp-json\/wp\/v2\/posts\/694"}],"collection":[{"href":"https:\/\/www.data-protector.org\/wordpress\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.data-protector.org\/wordpress\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.data-protector.org\/wordpress\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.data-protector.org\/wordpress\/de\/wp-json\/wp\/v2\/comments?post=694"}],"version-history":[{"count":41,"href":"https:\/\/www.data-protector.org\/wordpress\/de\/wp-json\/wp\/v2\/posts\/694\/revisions"}],"predecessor-version":[{"id":2725,"href":"https:\/\/www.data-protector.org\/wordpress\/de\/wp-json\/wp\/v2\/posts\/694\/revisions\/2725"}],"wp:attachment":[{"href":"https:\/\/www.data-protector.org\/wordpress\/de\/wp-json\/wp\/v2\/media?parent=694"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.data-protector.org\/wordpress\/de\/wp-json\/wp\/v2\/categories?post=694"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.data-protector.org\/wordpress\/de\/wp-json\/wp\/v2\/tags?post=694"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}