Migration from version 3.6 to 5.1

To migrate from version 3.6 to version 5.1, please follow the steps below:

Note:

  1. The value for the field Tape Drive Device in Backup Where page of the backup set linked to the tape device, will not be migrated. After migration, it is crucial to update this field manually.

  2. If any configuration files within the directories /etc/zmanda/zmc/zmc_ags/device_profiles/ or /etc/amanda have been manually modified, or if the extensions of any file within these directories have been changed, their migration may not be successful. It is recommended to verify these files after migration.

  3. The zmc_migrate script should be executed only after upgrading to version 5.1. Follow the steps outlined in Migration section carefully to ensure a smooth migration process.

These notices are essential to guarantee a successful migration and to avoid any potential issues, and the proper execution of the migration script.

Step 1. Uninstall 3.6: 

  1. Autolabel Value Update: Before uninstalling version 3.6, update the autolabel value to only empty or I/O error on the Backup Where page. This is specifically for backup sets linked to tape devices.

  2. Uninstall Zmanda 3.6: Uninstall Zmanda 3.6 using /opt/zmanda/amanda/uninstall. Ensure that all configuration files are preserved during the uninstallation process.

  3. Optional Step for Debian/Ubuntu Machines: If your system is running Debian or Ubuntu, consider executing the following command to uninstall the amanda-enterprise-backup-server package.

# apt remove amanda-enterprise-backup-server 

Step 2. Pre-migration steps:  

Before initiating the migration process, follow these steps to ensure a smooth migration and provide the ability to re-attempt migration in case of any failures:

  1. Backup configuration directories: 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. Preserve encryption key: Copy the .am_passphrase file from /var/lib/amanda to preserve server encryption key.

  3. Delete migrated configurations: If a migration was previously attempted and failed, then delete all migrated configurations from the Zmanda Management Console (ZMC). This step is not needed if you are running the migration for the first time.

  4. Execute commands for configuration directories:
    Navigate to the /etc/amanda directory and execute the following command:

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

Go to the directory /etc/zmanda/zmc/zmc_ags/device_profiles and execute the following command:  

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

Replace config backup dir with the path to the directory where the backup set directories and device yaml files have been backed up to.  

5.       Run additional command [optional step]: 
cat zmc_migrate_fix>/usr/sbin/zmc_migrate 

6.      Migrate AWS devices with storage class ONEZONE_IA or STANDARD_IA: 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: 

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

  • Open the yml file corresponding to the concerned AWS device.

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

Step 3. Migration    

 

 Note: All the operations stated below are to be run as root user. 
  1. Install Zmanda 5.1 binaries: Install both Zmanda backup server and ZMC binaries by following the installation instructions for version 5.1. Linux Binary Installation

  2. Login to Zmanda Management Console (ZMC):

  • Log in to ZMC and upload the new or updated 5.1 license file.

  • Create a cluster by adding the server with its IP address (the machine where server binaries have been installed).

Please note that the migration script will not work unless license file is uploaded [new or updated 5.1 license]

3.        Run migration script: On the Zmanda backup server machine, execute the following                         command:

/sbin/zmc_migrate

4.        Provide the following inputs in the specified order:

    1. Admin-level username

    2. Password for the user

    3. IP address of the machine where ZMC is present

    4. Port of the machine where ZMC is running

    5. Cluster ID corresponding to the server on which the migration script is being executed

Step 4. Expected Behavior   

  • Migrated storages: During migration, only AWS S3, Tape Changer Library, V-Tapes, and disk/SAN/NAS storages are supported. Migration is restricted to these types, and a storage device will be migrated only if it is linked to at least one backup set.

  • Migrated backup sets: Any backup set linked to a storage device should be migrated. Backup sets not linked to any storage device will be skipped during migration.

  • Migrated sources: Sources of all types will be migrated. If an identical source has been created for multiple backup sets, only one instance of such a source will be created in Zmanda 5.1. This instance will be linked to each of the backup sets it was associated with version 3.6.

  • Migration to ZMC clusters: The migration script can migrate to any ZMC as long as the machine running the migration is registered in the Cluster section of the ZMC.

  • Non migrated configurations: The migration script will not migrate configurations related to vault, staging, and schedules for any backup set.

  • Backup Where and Backup How configurations: Backup Where and Backup How configurations will be migrated, except for a few fields that have to be assigned default ZMC 5.1 values.

  • Unavailable data post-migration: Data in the staging area and vault data will not be available after migration.

  • Data restoration: After migration is completed, the data backed up with the 3.6 console can be restored from the 5.1 console, provided that the configurations of the (Disk List Entry) DLE that was backed up have not been altered.

Step 5. Post migration   

To successfully complete the migration, perform the following necessary operations and edits:

  • For Tape Storage: To sync the slot details, navigate to the Backup Media page of the backup set that is tied to tape storage and select Scan Slots (Applicable in case of using the tape storage)

  • Hyper V: Choose Rediscover and select the option which was previously selected. 

  • CIFS: Add the correct value in the Network Domain field. Enter the correct username and password for CIFS configurations.

  • NDMP: Add correct vendor and password for NDMP configurations.

  • VMware: Choose Rediscover and select the option which was previously selected. 

  • MS Sql Server: Choose Rediscover and select the option which was previously selected. 

Step 6. Restoring Client-side Encrypted backup   

To initiate backup restores with client-side encryption turned on, follow these steps:

Copy the contents of the .am_passphrase file from the client side into the .am_passphrase file on the server temporarily. Revert this change once the restore is completed.

These post-migration steps are essential to ensure that configurations are synchronized and correctly set up for different storage types and virtualization platforms.