We will discuss the fix for “Veeam Agent for AIX: Initial Deploy/UUID Error”. When deploying Veeam Agent for AIX in environments running on IBM Power Systems, you may face unexpected issues during VM cloning. Please, see Backup and Restore Proxmox VE virtual machines with Veeam, how to Protect your Windows Devices with MFA with SystoLOCK, and how to Set up Microsoft PKI (ADCS) for SystoLOCK via PowerShell.

I recently went through this process: after performing the initial manual deployment of the agent, I discovered that cloned VMs were replacing the original servers in the Veeam Protection Group instead of being added as new machines. In this blog post, I’ll walk you through:

How I performed the initial deploy of Veeam Agent for AIX.
Why cloned VMs replaced the original ones in VBR.
The root cause of the UUID duplication issue.
Step-by-step instructions to fix the problem.

Please, see How to disable Ads in Windows 11, how to Import a user profile in Windows to another PC, and how to Set up Veeam Backup for Microsoft Azure.

Initial Manual Deploy of Veeam Agent for AIX

Before running into the UUID issue, I went through the full manual deployment of the Veeam Agent for AIX. Below is the exact installation process I followed.

1. Create a Protection Group in Veeam

Open the Veeam Backup & Replication console. Navigate to Inventory > Physical Infrastructure, and create a new Protection Group where your AIX server will be managed.

During the Protection Group creation wizard, VBR will prompt you to:

Select the Veeam Agent package for AIX. Next, choose an export path on your Windows VBR server.

Slecting the package ant the export path

Applying and configuring required components

After finishing the wizard, VBR automatically generates and exports two important files to that folder

Please, see “Veeam Agent Vulnerability: Fix Veeam Agent vulnerability for Microsoft Windows“, and “Error 1385: The user has not been granted the requested logon type at this time“.

2. Export the Installation Packages and Configuration File

From the VBR console, export the Veeam Agent for AIX installation RPM packages.
Also export the XML configuration file (which contains the settings for connecting the agent back to VBR).

You should now have two things ready:

A set of RPM packages (veeam-*.rpm).
A ConfigFile.xml generated by Veeam.

3. Install the RPM Packages on AIX

On the AIX server, navigate to the directory where you placed the files and install the agent:

cd /tmp
rpm -ivh veeam-*.rpm

This command installs the Veeam Agent and its required components.

4. Apply the Configuration File

Once installed, apply the exported XML file so that the agent can register with VBR automatically:

veeamconfig mode setVBRsettings --cfg /tmp/ConfigFile.xml

The Problem: VM Clone Replaces Original Server

After deploying the agent, I noticed something strange when adding a new AIX server into the Protection Group: instead of appearing as a new host, it replaced an existing machine that was already registered.

At first, this was very confusing. The new system had a different hostname and a different IP address, so there was no obvious reason why Veeam would treat it as the same server.

Only later I realized that this machine wasn’t a completely new build. It was actually a cloned VM running on IBM Power Systems.

And when a VM is cloned in that environment, the Veeam Agent UUID is cloned as well. Since Veeam uses the UUID as the unique identifier for each machine, both systems were seen as one and the same host.

Why Veeam Confuses Cloned VMs

When you install Veeam Agent for AIX or Linux, the agent generates a unique identifier (UUID) and stores it locally on the system.

This UUID becomes the primary identity of the machine in Veeam Backup & Replication.

Hostname changes? It doesn’t matter.
IP address changes? Still doesn’t matter.
As long as the UUID is the same, VBR considers it the same host.

The problem is that when you clone a VM, the UUID is cloned as well. That means the new VM has the exact same identity as the original one. From Veeam’s perspective, the clone is not a new server. It is just the same server re-registered.

As a result, the clone simply overwrites the original entry in the Protection Group.

Bonus Tip: Want to integrate an IBM Tape Library with Veeam for even stronger backup strategies? Read my full guide: Using IBM Library with Veeam, and Veeam Backup and Replication Disk I/O with diskspd.

Fix the UUID Issue in Veeam Agent for AIX

The solution is to regenerate the UUID on the cloned machine before registering it with VBR. This way, Veeam sees it as a completely independent host. Here’s the exact procedure I followed:

1. Stop the Veeam Agent service

stopsrc -s veeamsvc

2. Remove or Rename the existing database

rm -f /var/lib/veeam/veeam_db.sqlitemv /opt/veeam/bin/veeamagentid /opt/veeam/bin/veeamagentid.bak

3. Generate a new UUID and save it in veeamagentid

uuid_get

The file should contain only the UUID in curly braces, for example:

{04bfcddc-XXXX-XXXX-XXXX-XXXXXXXXXXXX}

Update the file /var/lib/veeam/veeamagentid and /etc/veeam with the same value for consistency.

Please, see Fixing AIX Veeam agent job startup delay issue, how to backup Azure VM with VM Settings, and how to Backup Mac with Veeam Agent for Mac to Synology DS923+ NAS.

4. Start the Veeam Agent service

startsrc -s veeamsvc

5. Re-register the agent with VBR

veeamconfig mode setvbrsettings --cfg <ConfigFile.xml>

After completing these steps, the cloned VM was recognized as a separate machine. The original server remained in the Protection Group, and the clone appeared alongside it, with no overwriting or conflicts.

Key Takeaways

Veeam Agent for AIX and Linux identifies servers by UUID, not by hostname or IP. When cloning a VM, the UUID is copied causing conflicts in VBR.

To avoid overwriting, always regenerate the UUID on the cloned VM before registering it with VBR. This issue affects both AIX and Linux environments.

Conclusion

Cloning VMs is a common practice, but when using Veeam Agent for AIX or Linux, it introduces an extra step: updating the UUID. Simply changing the hostname or IP won’t prevent conflicts, because Veeam relies exclusively on the UUID for host identification.

By regenerating the UUID on cloned VMs, you ensure that:

Each machine is treated as unique.
Protection Groups remain consistent.
Backup jobs run smoothly without overwriting existing servers.

If you’re deploying Veeam Agent for AIX in IBM Power Systems or Linux environments, make sure to include this step in your workflow whenever you clone a VM. It will save you troubleshooting headaches and keep your backup infrastructure reliable.

I hope you found this blogpost on “Veeam Agent for AIX: Initial Deploy/UUID Error” very useful. Please, feel free to leave a comment below.