Migrating from 3.X to 4.X

How to upgrade from Zmanda 3.X versions to 4.X

1. Important Notes:

  1. 1.
    Value for the field “Tape Drive Device” in “backup where” page of backup set linked to tape device, will not be migrated. Please remember to update it manually post migration.
  2. 2.
    If any configuration files within /etc/zmanda/zmc/zmc_ags/device_profiles/ or /etc/amanda have been manually modified or the extensions of any file within these directories have been modified, then their migration may not be successful. Please verify after migration.
  3. 3.
    Zmc_migrate script should be executed only after upgrading to 4.2.0.X. Please follow the steps in “Migration” section carefully.

2. Uninstall 3.6:

  1. 1.
    Before uninstallaing 3.6, update the autolabel value to “only empty or I/O error” on Backup Where page. [ Only for Tapes Related Backupsets ]
  2. 2.
    Uninstall Zmanda 3.6 using /opt/zmanda/amanda/uninstall, preserving all the configuration files.
  3. 3.
    (Optional) If you are using Debian/Ubuntu machines, uninstall amanda-enterprise-backup-server package by executing the following command for migration for migration to be smooth. If not, please skip this step.
# apt remove amanda-enterprise-backup-server

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:
Edit section
Edit section
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
Edit section
Edit section
Edit section

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
#chmod +x 
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.
e. Execute the following command to check if the ZMC [ zmc services] is installed correctly and is up and running.
f. Executing following command to check if the AE Server [aee services] is installed correctly and is up and running.
If there is any issue with zmc services or aee services and they are not starting automatically, then execute the following commands to start them manually.
#systemctl start run-zmanda-zmc
#systemctl start run-zmanda-backup-server   
Now check the services by following steps e and f instructions respectivelly.
2. Login to the Zmanda console, upload the license and add to the cluster, IP of the machine on which the server binaries have been installed.
[Please note that the migration script will not work unless license file is uploaded]
[Caution: the license must be as per the features supported by that of 3.6 license]
3. 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

5. Expected Behavior
Edit section
Edit section
Edit section

  • 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
Edit section
Edit section
Edit section

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
Edit section
Edit section
Edit section

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
Edit section
Edit section
Edit section

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.