Migrate Data Protector 7.0x to Data Protector 9.

0x
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 version en 8.13 and newer, as it will cause serious damages in the
internal database (no fix available/possible). For versions older 8.13 it is too
recommended not to use a patched installation source due to missing tests by
engineering. In this case, please install Data Protector 9.0 first followed by
installation of current patch bundle. One exception to use a patched installation
source is when doing a new installation (green field approach i.e. Windows
2012 R2 Cluster Cell Server), es there are no depenencies for upgrading internal
database.
Data Protector 7.0 was introduced on 16.04.2012 and meanwhile superseded by
two major releases. On 30.06.2016 the time has come and the support for Data
Protector 7.0x ends. Thus, it is time for all undecided customer to upgrade to the
current version Data Protector 9.06. A big step, as with the upgrade the
internal database will change. Many customers have been postponed this step
due to uncertainties with the upgrade. Hewlett Packard Enterprise already
released in the past two advisories and explained how the upgrade to the new
internal database can be performed (please refer
to http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04350769 and
http://h20566.www2.hpe.com/hpsc/doc/public/display?docId=c04937621).
However, the change to the new version also offers opportunities, the backup
and recovery strategy (e.g. backup to HPE StoreOnce) might be reconsidered, as
the current version offers a lot of new features compared to Data Protector 7.0x.
Some selected features:

3PAR Remote Copy support

Automated pause and resume of backup jobs

Accelerated VMware backup through 3PAR snapshot management

Cached VMware single item recovery direct from HPE 3PAR snapshot or Smart
Cache

VMware Power On and Live Migrate from HPE 3PAR snapshot or Smart Cache

StoreOnce Catalyst over Fiber Channel and Federated Catalyst support

Data Domain appliance to appliance replication management

Automated Replication Synchronization synchronize metadata of replicated

objects between Cell Manager

On the web there are many instructions, but no step-by-step documentation for
upgrading to latest version. Therefore, this article deals with the upgrade of
Data Protector 7.0x to Data Protector 9.06 and offers all required steps as a
runbook.
Some notes before you can start:

This step-by-step documentation is valid for Cell Manager Installation on Windows

2008 or Windows 2012. It is assumed that the path C:\Program
Files\OmniBack and C:\ProgramData\OmniBack is used. This runbook can also be used for
Linux or deviating installation paths.

When migrating (this is a separate and subsequent process) the DCBF files are
converted into a new format. The new DCBF format is approximately 1.5 times to 2
times larger than the old format, it is therefore enough free disk space required.

All existing Data Protector licenses should be regenerated in advance using the
new licensing portal https://myenterpriselicense.hpe.com, old OVKEY3 licenses can
no longer be used in current Data Protector versions. Of course you can only be
migrate licenses, for which there is a maintenance contract.

Should the upgrade fail despite these detailed instructions, there is always a
rollback to Data Protector 7.0x possible. But you need to have your DP 7.0
installation sources and the most recently installed patch bundle available.

It is recommended to move all used and appendable media into a separate pool
so that mixing of to be migrated and new media is avoided.

The Catalog Migration of DCBF files is a downstream process and can either be
performed directly after the upgrade or after a few weeks. If possible plan for no
activity on the Cell Server during the catalog migration.

It is recommended to test the upgrade using a virtual machine. Using the

exported Data Protector 7 database it can be easily imported into the test
environment.

With Data Protector 9.0x name resolution is top most priority to avoid problems
during or after the migration. It is therefore required that the Cell Manager is always
been resolved (FQDN, short and reverse).

By upgrading to the latest version earlier operating system versions may stop
working, as e.g. Windows 2003 is no longer supported. In such a case and if the
client is running as a virtual machine, the client can be backed up with the VMware
or Hyper-V integration in the future.

The following steps are only one possible path for migration, there are several
ways to upgrade. Thus the success is not guaranteed, because a successful upgrade
also depends on the existing environment. This runbook were however already
carried out during many successful migrations and thus the instructions should be
appropriate for your environment too.

Preparation:

Checking the consistency of the internal database. There must be no errors

appear. If errors are seen you need to address them before the upgrade to DP 9.0x
can be continued. To check the IDB use the command:
o

omnidbcheck -extended

Cleaning of the old internal database:

o

Close Data Protector GUI

omnidbutil -clear

omnidb -strip

omnidbutil -purge -sessions 90 (or correspondingly higher, lower value)

omnidbutil -purge -dcbf -force

omnitrig -stop

omnistat (no backup job must run)

omnidbutil -purge -filenames -force

Open Data Protector GUI

Monitor -> Current Sessions

Select the purge session

Watch progress and wait for the end of the process

During the purge of filenames no backups can run, scheduled jobs are queued
and will only be executed if the purge has been completed. In larger environments, it
may be necessary to cancel the purge process and continue at a later time. To stop
the purge use the command omnidbutil -purge_stop. Alternatively, the purge can also be
performed selectively for individual clients.

Create directories for the migration:

o

mkdir C:\migration\mmdb

mkdir C:\migration\cdb

mkdir C:\migration\other

mkdir C:\migration\program files\omniback

mkdir C:\migration\program data\omniback

Defrag the internal database using export and import

o

It must not run any backups, check with the command omnistat

omnidbutil -writedb -mmdb C:\migration\mmdb -cdb C:\migration\cdb

At the end of the export you are prompted to copy some special
directories. You need to copy them before the database is re-enabled. These are
usually the DCBF and MSG directories, but there might be other directories
required to copy. For safety the following directories are copied:

robocopy "C:\ProgramData\OmniBack\DB40\DCBF" C:\migration\other\DCBF

*.* /e /r:1 /w:1

Copying may be necessary for further DCBF directories. In this

case, the copy operation is continued in line.

robocopy "C:\ProgramData\OmniBack\DB40\msg" C:\migration\other\msg *.* /e

/r:1 /w:1

robocopy "C:\ProgramData\OmniBack\DB40\meta" C:\migration\other\meta

*.* /e /r:1 /w:1

robocopy "C:\ProgramData\OmniBack\DB40\vssdb" C:\migration\other\vssdb *.*

/e /r:1 /w:1

Now the exported database can be imported again, the following

command is used:

omnidbutil -readdb -mmdb C:\migration\mmdb -cdb C:\migration cdb

If the command omnidbinit -force was used prior importing the database the
DCBF, MSG and META directories need to be copied back into the old location,
because the original folders are deleted when the database is initialized. For this,
however, the Data Protector services must be stopped. If necessary, additional
DCBF directories for the internal database must be created beforehand.

For safety, the omnidbcheck -extended is performed again, it must not show any
errors.

If necessary, temporary files

in C:\ProgramData\OmniBack\tmp and C:\ProgramData\OmniBack\log can be removed. But
please be beware: not all log files can be deleted. Files as the media.log must be
retained, because it might be required in case of recovering data. The media.log
provides information when and in what order a media was used during a backup.

Copy/backup the entire Data Protector installation:

o

omnisv -stop

robocopy "C:\Program Files\OmniBack" C:\migration\programfiles\omniback *.* /e

/r:1 /w:1 /purge

robocopy C:\ProgramData\OmniBack C:\migration\programdata\omniback *.* /e /r:1

/w:1 /purge

omnisv -start

Installation sources:

It is highly recommended to use a patched installation source for the installation.

To this end, the following steps are carried out on a temporary Windows server on
which no Data Protector installation exists.
o

Perform the Data Protector 9.0 installation as an administrator (run as

admin) and select the installation of the installation server. No any other
components apart from the installation server will be installed.

Install additional patch bundle and patches after the installation has been
completed. Please refer to https://www.data-protector.org/wordpress/2016/04/hpedata-protector-patch-bundle-9-06-features/ and https://www.dataprotector.org/wordpress/2013/06/basics-installation-order-patches/

The so updated installation can be used as an installation source for the upgrade
of the Cell Manager. To this end, all the folders of the depot from the temporary
installation server are copied to the Data Protector Cell Manager 7.0x (e.g.
to C:\migration\install). Once done, the temporary installation server can be uninstalled.

Upgrade:

The upgrade is carried out with the patched installation sources and setup.exe is
executed as an administrator (run as admin).

It is recommended to leave all the proposed defaults during installation and thus
perform the upgrade.

During the upgrade parts of the old database are exported and prepared for
import into the new database. This process may take some time depending on the
size of the environment; the process should not be interrupted.

Following this part the installation of Data Protector 9.0x is continued normally.

After the upgrade it is recommended to review and adjust the configuration

files global and omnirc.

In addition, the backup specification of the Cell Manager should be checked.

During the upgrade to DP 9.06 the existing specification has been divided into an IDB
and a filesystem specification.

After the upgrade:

After the upgrade the DCBF directories should be migrated to the new format. In
principle there are two options: the immediate migration of all DCBF files or
migration of the DCBF files for long-term backups only.

The second way is the preferred method, as you wait for the expiration of the
short-term protection of the old media and thus these DCBF files will not have to be
migrated. After four to six weeks you migrate only media with long-term protection.

Required steps for both ways:

o

Open administrative command line and change into the

directory C:\Program Files\OmniBack\bin
Run the command: perl omnimigrate.pl -start_catalog_migration

The DCBF migration is very time consuming, however, runs in the

background and does not have to be actively monitored.

After the DCBF migration is done check that all the media have been
migrated. For this purpose, the command perl omnimigrate.pl -report_old_catalog is
used. As a result "DCBF (0 files)" is expected. Should still files are displayed, the
following steps must not be executed.

If new backups have already run during DCBF migration, it may happen
that DCBF 2.0 files were created in the DB40\DCBF* directories.
The files found in DB40\DCBF* are moved

to C:\ProgramData\OmniBack\server\DB80\DCBF\dcbf1-4. The files can be distributed, in

principle it is not necessary to maintain a certain order.
o

To adapt the change the command omnidbutil -remap_dcdir is executed after

moving the DCBF files.
The old DCBF directories will be removed, the following commands are

o
used:

omnidbutil -remove_dcdir "C:\ProgramData\OmniBack\DB40\DCBF"

omnidbutil -remove_dcdir "C:\ProgramData\OmniBack\DB40\dcbf1"

omnidbutil -remove_dcdir "C:\ProgramData\OmniBack\DB40\dcbf2"

omnidbutil -remove_dcdir "C:\ProgramData\OmniBack\DB40\dcbf3"

omnidbutil -remove_dcdir "C:\ProgramData\OmniBack\DB40\dcbf4"

Depending on the size of the environment less or more DCBF directories

may be present and must be removed accordingly.

With the command perl omnimigrate.pl -remove_old_catalog the old catalog is

removed.

In the file C:\ProgramData\OmniBack\Config\server\options\global the

variable SupportOldDCBF=0should be set, but it can also be removed (default after
upgrade is 1).

Now the DB40 path can be deleted C:\ProgramData\OmniBack\DB40

Rollback:

If the upgrade fails, you can rollback at any time, assuming that no migration of
files DCBF files began.

The failed Data Protector 9.0x installation needs to be removed and installation
of Data Protector 7.0x and patches to be done.

The command omnidbutil -readdb -mmdb C:\migration\mmdb -cdb C:\migration\cdb will be

used to re-import the old database.

Additional directories as DCBF, MSG and META, need to be copied back to the
DB40 path.

The configuration from the previously saved Data Protecor installation

(C:\migration\omniback\programdata) needs to be copied
to C:\ProgramData\OmniBack\config\server so that the initial state is restored.