Migration

Uninstall 3.6 

• Restore the backups 
• Uninstall 3.6 using /opt/zmanda/amanda/uninstall, preserving all the configuration files. 
• Follow Precaution section 

Prerequisites 

·         Copy all backup directories related to disk, vtape storage devices, staging from /var/lib/amanda-1 [paths could be /var/lib/amanda-1/disk,/var/lib/amanda-1/vtape, etc] to /var/lib/amanda. Run the following command for each of the copied directories: 

o   chown -R amandabackup: amandabackup [copied directories] 

Running migration 

All the operations stated below are to be run as root user. 

·         Install 4.0 binaries both server and rest binaries. 

·         Login to the Zmanda console, upload the license and add the machine IP in the cluster. 

·         Run the command – 

o   zmc_migrate  

o   Inputs[to be entered in this order]: 

§  Admin level username 

§  Password for the user 

§  IP of the machine on which the Zmanda console is present 

§  Port of that machine 

§  Cluster Id corresponding to the server on which the migration script is being run 

Expected Behavior 

·         Migrated storages: AWS S3, Tape Changer Library, V-Tapes, Disk/SAN/NAS [Migration for any other kind of storage is not supported]. A storage device will be migrated only if it is linked to at least one backup set. 

·         Migrated backup sets: Any backup set that was linked to a storage device should get migrated, will be skipped if it’s not linked to any storage device. 

·         Migrated sources: Sources of all types will be migrated. If identical source has been created for multiple backup sets, then on 4.0 only one instance of such a source will be created and link them to each of the backup set with which it was associated in 3.6. Merging of request bodies is possible for all source types except source types 14, 15, 17, 10, as these source types do not support multiple backup set linking in 4.0. 

·         The migration script can migrate to any UI console provided the machine on which the migration is being run is registered in the “Cluster” section of the UI console. 

·         User can also restore data backed up in 3.6, after migration.  

·         Migration script will not migrate vault, staging and schedule configurations of any backup set. 

·         Backup where and backup how configurations will be migrated except a few  

Post migration 

Check host for certain source types fail, so following operations/edits are necessary to successfully complete the migration: 

·         Hyper V: “Rediscover” and select the option which was previously selected. 

·         CIFS: Add correct value in “Network Domain” field and enter the correct password. 

·         NDMP: Add correct vendor and password. 

·         VMware: “Rediscover” and select the option which was previously selected. 

Reporting a bug 

In case the migration run fails please include the timestamp which is printed right above the part where you are prompted to enter the “username”, or the one which is printed at end of the migration run. 

Precaution 

Useful when migration needs to be run multiple times on the same set of backup sets, dles and storage devices. 

·     If multiple migrations are to be run on the same set of migration files, then copy the backup set directories from /etc/amanda and device yaml files from /etc/zmanda/zmc/zmc_ags/device_profiles to any directory of your choice[copying has to be done right after uninstalling 3.6]. 

·     Before running migration the next time, delete every migrated configuration from the Zmanda console[Not needed if running for the first time].  

Then run the following cmds: 

o   From within /etc/amanda:  

ls [config backup dir]|xargs rm -rf; cp -R [config backup dir]/*/ ./; chown -R amandabackup *; chgrp -R amandabackup * 

o   From within /etc/zmanda/zmc/zmc_ags/device_profiles: 

rm -rf *.yml; cp [config backup dir]/*.yml ./; chown amandabackup *.yml; chgrp amandabackup *.yml 

[config backup dir] – path of the directory where the backup set directories and device yaml files have been backed up to.