Migration

3. Pre-migration steps:  

Please perform the following steps before performing migration. These steps will help with reattempting the migration, if there are any migration failures during the process.  

1.    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. 

2.  Copy the .am_passphrase file from /var/lib/amanda to preserve server encryption key.

3.   If migration has already been attempted and failed, delete all migrated configurations from the Zmanda console [Not needed if running for the first time].    

4. Then execute the following cmds:      

   

o   Go to the directory /etc/amanda:   

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

o    Go to the directory /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. 

5. Run the following cmd[optional step]: 

       o   cat zmc_migrate_fix>/usr/sbin/zmc_migrate 

6. To migrate AWS devices which have storage class set as ONEZONE_IA or STANDARD_IA, perform the following  changes in order to migrate such devices and the linked backup sets: 

       o   Go to - /etc/zmanda/zmc/zmc_ags/device_profiles 

       o   Open the yml file corresponding to the concerned AWS device 

       o   Update the value of the field S3_STORAGE_CLASS to STANDARD or REDUCED_REDUNDANCY. 

4. Migration   

   

 

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

1.    Install 4.2.0.X binaries both AE server and ZMC UI binaries by following Installation Guide  

[Note: Mt-st is required to be installed before installing the Server binaries, in order to use Tapes storage. In case if mt-st is installed later, then make sure to run "setup-aee" utility as root user] 

              a. Copy 4.2.0.X ZMC and backup server binaries and give executable permissions. 

#chmod +x zmanda-zmc-4.2.0.14-x64.run
#chmod +x zmanda-backup-server-4.2.0.11-x64.run 

                         b. Before installing the ZMC and AE server, make sure SELINUX is disabled. 

#setenforce 0 

 c. Execute following command to disable the firewall.  

                     RPM Based      #service firewalld stop
                     Debian based  #ufw disable  

 d. Install ZMC and Backup Server binaries respectively with superuser permissions.

#./zmanda-zmc-4.2.0.14-x64.run
#./zmanda-backup-server-4.2.0.11-x64.run 

 e. Execute the following command to check if the ZMC [ zmc services] is installed correctly and is up and running.

#setup-zmc

#setup-aee

#systemctl start run-zmanda-zmc
#systemctl start run-zmanda-backup-server   

5. 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.2 only one instance of such a source will be created and will be linked to each of the backup sets 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.2. 
• 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.  
• 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 fields for which had to be assigned default ZMC 4.2 values. 
• Data in staging area and vault data will not be available post migration.
• After migration completes, the data backed with the 3.6 console can restored from 4.2 console provided that the configurations of the DLE which was backed-up have not been altered. 

6. Post migration   

   

 

Following operations/edits are necessary to successfully complete the migration: 

• Goto Backup Media page of the backup set which is bound to tape storage and click on Scan Slots to sync the slot details (Applicable in case of using the tape storage)

• Hyper V: “Rediscover” and select the option which was previously selected. 
• CIFS: Add correct value in “Network Domain” field and enter the correct username, password. 
• NDMP: Add correct vendor and password. 
• VMware: “Rediscover” and select the option which was previously selected. 
• MS Exchange: “Rediscover” and select the option which was previously selected. 
• MS Sql Server: “Rediscover” and select the option which was previously selected. 

7. 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. 

8. Restoring Client-side Encrypted backup   

   

 

When triggering restore of a backup which had client side encryption enabled, make sure that the contents of the “.am_passphrase” file from the client side is temporarily copied into the “.am_passphrase” file on the server. This change needs to be reverted once the restore is completed.