At Zmanda, we tend to bring in major version upgrades to deliver the best enterprise data management solution for our customers. We have done it again, this time by adding the latest building block to our platform as Zmanda 4.1.3 release, and it’s BIG!
Introducing Zmanda 4.1.3: Power Plus Power.
The new Zmanda 4.1.3 has many new features and enhancements like LDAP integration, enhanced user interface, comprehensive logs, support for Ubuntu 22.04, and the most up-to-date API documentation that can help you with wider compatibility, building automation, and seamless backup.
We understand that upgrading to an entirely new platform takes time and effort, so we are committed to helping you. In this article, we’ll walk you through the installation process step-by-step to help you upgrade to the latest version of Zmanda.
How to Upgrade From the Old Version to Zmanda 4.1.3?
Here’s a quick overview of the different upgrade paths that will allow you to switch to the latest version of Zmanda.
|22.214.171.124 -> 126.96.36.199
|3.6 -> 188.8.131.52
Upgrading ZMC and Backup Server from 184.108.40.206 to 220.127.116.11
1. Uninstall the 18.104.22.168 Backup Server and ZMC binaries on both RPM and Debian-based systems using the below commands
RPM Based : #yum remove zmanda-platform-shared
Debian Based : #apt remove zmanda-platform-shared
2. Only if you are a Debian user, you need to run the following commands before moving to steps 3 and 4,
#cp /var/lib/amanda/backup/db.sqlite3 /var/lib/amanda/ae_service/db.sqlite3
3. Then copy 22.214.171.124 ZMC and backup server binaries onto respective servers and give executable permissions
#chmod +x zmanda-zmc-126.96.36.199-x64.run
#chmod +x zmanda-backup-server-188.8.131.52-x64.run
4. After copying, install the 184.108.40.206 ZMC and backup server binaries by running them with superuser permissions
- It is mandatory to run Step 2, to perform the upgrade on Debian-based systems.
- For rpm-based systems, Step 2 is not required.
- It is mandatory to upgrade both Backup Server and ZMC.
Migration from 3.6 to 220.127.116.11
Please follow the below-mentioned steps to migrate from Amanda Enterprise 3.6 to 18.104.22.168.
Before you start migrating, please go through these important notes to avoid any last-minute hassle.
1. Important Notes
Some of the important things to consider before upgrading are:
- Value for the field “Tape Drive Device” in the “backup where” page of backup set linked to a tape device, will not be migrated. Please remember to update it manually post-migration.
- 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.
- Zmc_migrate script should be executed only after upgrading to 22.214.171.124. Please follow the steps in the “Migration” section carefully.
2. Uninstall 3.6
Before uninstalling 3.6,
- Update the auto-label value to “only empty or I/O error” on the Backup Where page. [ Only for Tapes Related Backup sets ]
- Uninstall Zmanda 3.6 using /opt/zmanda/amanda/uninstall, preserving all the configuration files.
- (Optional) If you are using Debian/Ubuntu machines, uninstall the Zmanda-enterprise-backup-server package by executing the following command 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 the migration. These steps will help with re-attempting the migration if there are any migration failures during the process.
- 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.
- Copy the .am_passphrase file from /var/lib/amanda to preserve server encryption key.
- If migration has already been attempted and failed, delete all migrated configurations from the Zmanda console [Not needed if running for the first time].
- Then execute the following commands:
- Go to the directory /etc/amanda:
ls [config backup dir]|xargs rm -rf; cp -R [config backup dir]/*/ ./; chown -R amandabackup *; chgrp -R amandabackup *
2. 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.
- Run the following cmd[optional step]:
- To migrate AWS devices that 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.
All the operations stated below is to be run as a root user.
1. Install 126.96.36.199 binaries both AE server and ZMC UI binaries by following the Installation Guide
[Note: Mt-st is required to be installed before installing the Server binaries, in order to use Tapes storage. In case mt-st is installed later, then make sure to run the “setup-aee” utility as the root user]
- Copy 188.8.131.52 ZMC and backup server binaries and give executable permissions.
#chmod +x zmanda-zmc-184.108.40.206-x64.run
#chmod +x zmanda-backup-server-220.127.116.11-x64.run
Install ZMC and Backup Server binaries respectively with superuser permissions.
2. Log in to the Zmanda console, upload the license and add to the cluster, the IP of the machine on which the server binaries have been installed.
[Please note that the migration script will not work unless the license file is uploaded]
[Caution: the license must be as per the features supported by that of the 3.6 licenses]
3. Run the command –
- 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 behaviour
Here are some expected things which might occur during the upgrade process.
- Migrated storage: 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 the 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, and 10, as these source types do not support multiple backup sets 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.
- The 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 the staging area and vault data will not be available post-migration.
- After migration completes, the data backed with the 3.6 consoles can restore from the 4.1 consoles provided that the configurations of the DLE which was backed up have not been altered.
Following operations/edits are necessary to successfully complete the migration:
- Go-to 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 the correct value in the “Network Domain” field and enter the correct username and password.
- NDMP: Add the 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 that had client-side encryption enabled, make sure that the contents of the “.am_passphrase” file from the client side are temporarily copied into the “.am_passphrase” file on the server. This change needs to be reverted once the restore is completed.
Fresh Install – 18.104.22.168 [ ZMC and Backupserver ]
Please refer installation guide for detailed steps to install 22.214.171.124.
Ready for some testing? Upgrade to our all-new and powerful Zmanda 4.1.3. For further assistance, raise a support ticket on your Network Zmanda portal or email our sales team at firstname.lastname@example.org. Our support services are oriented to help you make the most out of Zmanda.
For more details about new features and improvements in this release, please read the Zmanda 4.1.3 release notes.
Not an existing Zmanda customer? Request a demo and get started.