Please follow below steps to migrate Amanda Entreprise 3.6 to 4.1 latest version. 

Uninstall 3.6 

  • Follow Points of Caution section. packages if you are using Debian/Ubuntu machines. 
  • Make sure to uninstall amanda-enterprise-backup-server & amanda-enterprise-extensions-server packages if you are using Debian/Ubuntu machines. 
  • Uninstall 3.6 using /opt/zmanda/amanda/uninstall, preserving all the configuration files. 
  • Follow Precaution section.


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

  • Run the following cmd:

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

  • Run the following cmd[optional step]: 

       o   cat zmc_migrate_fix>/usr/sbin/zmc_migrate 

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

·         Install 4.1 binaries both Backup server and ZMC UI binaries. 

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

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

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


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. 


 Points of caution:

  1. During migration, if any port mentioned in the “Port range” field in backup how is in /etc/services[for 4.1]. 
  2. 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. 
  3. 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.