Migration

Version as of 16:06, 4 May 2024

to this version.

Return to Version archive.

View current version

Please follow below steps to migrate Amanda Enterprise 3.6 to 4.1 version first and then upgrading to 4.1.0.106 latest version.  

Points of caution/Warnings

  1. During migration, value for the field “Tape Drive Device” in backup where page of backup set linked to tape device, will not be migrated so that has to be updated manually post migration. 
  2. If any configuration file within /etc/zmanda/zmc/zmc_ags/device_profiles/ or /etc/Amanda has been manually modified or the extension of any file within these directories have been modified, then their migration may not be successful.

Uninstall 3.6 

  1. Uninstall Zmanda 3.6 using /opt/zmanda/amanda/uninstall, preserving all the configuration files.
  2. If you are using Debian/Ubuntu machines, uninstall amanda-enterprise-backup-server package by using the following command. If not, please skip this step. 

# apt remove amanda-enterprise-backup-server 

Precaution  

Below precautions to be taken before running migration, below steps will help in reattempting the migration, if there is any migration failure 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, copying has to be done before running migration script.  

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

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

Prerequisites         

  1. Move all backup directories related to disk, vtape storage devices from /var/lib/amanda-1 to /var/lib/amanda. Run the following command for each of the copied directories: 

       o   chown -R amandabackup:amandabackup [copied directories] 

   2.   Run the following cmd:

              o  cat /var/lib/amanda-1/.am_passphrase>/var/lib/amanda/.am_passphrase

   3.   Run the following cmd[optional step]: 

       o   cat zmc_migrate_fix>/usr/sbin/zmc_migrate 

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

Running migration         

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

1.    Install 4.1 binaries both AE server and ZMC UI binaries by following Installation Guide to update the link 

[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] 

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.    Apply 4.1.0.106 patch by installing ZMC and Backup Server binaries 

                 i. For RPM Based Systems(CentOS/RHEL/Fedora/SUSE) 

a. Install the latest 4.1.0.106 patch binaries by using, 

                                            i.    # ./patch-backup-server-4.1.0.106x64.run 

                                           ii.    # ./patch-zmc-4.1.0.106-x64.run 

                ii. For Debian Based Systems (Ubuntu/Debian) 

a. Uninstall the 4.1.0.18 Backup Server and ZMC binaries by using, 

                                             i.    /opt/zmanda/amanda/zmanda-zmc-pkg/uninstall 

                                            ii.    / opt/zmanda/amanda/zmanda-backup-pkg/uninstall 

b. Install the 4.1.0.106 patch binaries by using, 

                                             i.    # ./ patch-backup-server-4.1.0.106x64.run

                                            ii.    # ./patch-zmc-4.1.0.106-x64.run

          4. 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.1 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.1. 
  • 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.1 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.1 console provided that the configurations of the DLE which was backed-up have not been altered. 

Post migration         

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 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. 
  • Move the contents of /var/lib/amanda-1/amvmware to /var/lib/amanda/amvmware. 

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. 

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.