Backing Up / Replicating the Acronis Appliance
What's the best practice for backing up / replicating the Acronis appliance itself?
Within Devices, All machines it's listed twice:
1 - "Virtual machine"
2 - "A virtual machine with an agent inside.".
Should I be backing up / replicating one of these? Which one? (Or both?)
Is there any special consideration for backing it up / replicating it? I want to avoid a scenario where the backup of the Acronis appliance itself interferes with its other backup operations. I also don't want to include other VM disks that may be mounted by the Acronis appliance at any given time.
Thanks

- Log in to post comments


We updated to build 10130 recently, and our backup of the virtual appliance now fails.
The error message is that the disks don't exist.
When I try to create a new backup plan in the same way and choose the disks, it says "Nothing to display" and I can't select any disks.
Any ideas? Is this an issue with 10130? I see 10330 was released, but the release notes don't mention anything related to this.
Thanks
- Log in to post comments

I've updated to build 10330, and now I can see the disks again.
Is this the correct selection of disks? Do I need to worry about Disk 2 and Disk 3? (No backups were running at the time I brought up this dialog.)
Thanks
- Log in to post comments

Hi Brian,
From what I have discovered after further investigation, there is a significant limitation when backing up the appliance via local Agent for Linux installed inside it: the recovery from such backup will be possible only into original appliance (that's what I actually tried myself when posting previous comments), but when this backup is restored to a freshly deployed new appliance - it will become unbootable. The reason is that there are dependencies on disk UUIDs which are used to distinguish appliance local disks from the ones attached to it during other VMs backup, so in new appliance these UUIDs are different and thus recovery causes non-bootable system (recovery into original is not affected).
The additional disk 2 + disk 3 (without volumes) shown on your screen shot are service disks with no data - they are added to appliance VM in order to configure additional SCSI controllers on the backup appliance and thus increase the amount of virtual disks it can attach to itself (there are limits for number of disks attached per SCSI controller). Regardless whether you include or not these disks into backup plan - they will be automatically skipped since they are not partitioned (this behavior applies to agent-based backup only). Plus due to reasons explained above it's not recommended to backup appliance using this method at all.
The proper alternative for appliance self-protection would be the following:
1) Deploy an additional regular Agent for VMware (Virtual Appliance) from "all-in-one" appliance console (Devices->Add->ESXi host)
2) Bind the "all-in-one" appliance VM to this deployed Agent for VMware (Virtual Appliance)
3) Capture "Entire machine" backup of "all-in-one" appliance VM which will be performed in agent-less mode by Agent for VMware (Virtual Appliance)
See below screen shot with comments explaining the concept, where:
AcronisAppliance-Fresh = "all-in-one" appliance instance reported by locally installed Agent for Linux
AcronisBackupAppliance10330Fresh = "all-in-one" appliance instance reported by Agent for VMware
VAforAIOFresh = "Agent for VMware (Virtual Appliance)" additional appliance connected to vSphere which can back up "AcronisBackupAppliance10330Fresh" instance in agent-less mode.
(The screen shot shows how to "bind" VM to particular agent from Details tab of the VM, which should be VAforAIOFresh in my case)
The recovery from this backup should be done also in agent-less mode, e.g. performed by Agent for VMware. Browse the backup from Backups tab (register existing backup location if you have new freshly deployed appliance) and start VM recovery:
P.S. In case IP address is changed for restored appliance - see "NOTE" from my previous comment.
Thank you.
- Log in to post comments

Thanks for the reply.
Just to confirm, you're saying to access the Backup Management Console of the existing All-in-One Appliance, then add a new device and select "VMware ESXi" under "Virtualization Hosts" as shown below, correct?
On the following screen, we want to select "Deploy as a virtual appliance to each host of a vCenter", correct?
Does the appliance actually need to be on each host in vCenter, or can we deploy it to a specific host only (the host with the current All-in-One Appliance)? (We almost never move VMs around.)
After that, we just bind the new agent to the existing All-in-One Appliance VM (the one listed as "Virtual machine", not the one listed as "A virtual machine with an agent inside."), then setup an entire machine backup of that Appliance VM.
Are there any licensing considerations for deploying the additional agent?
Could we accomplish the same thing by deploying an agent for VMware on a Windows system, pointing it to the management server of the existing All-in-One appliance, and then binding the new agent as detailed above?
I was considering deploying an agent for VMware on a Windows system (the system which stores most of our onsite backups), in order to see if the verification can avoid the network and complete faster. I'm not sure what licensing would be involved for this, if any. We wouldn't be backing up anything new, we'd just be running an extra agent on the system that stores backups (in a directly-attached RAID array).
- Log in to post comments

Hi Brian,
>> On the following screen, we want to select "Deploy as a virtual appliance to each host of a vCenter", correct?
Yes, correct
>> Does the appliance actually need to be on each host in vCenter, or can we deploy it to a specific host only (the host with the current All-in-One Appliance)? (We almost never move VMs around.)
It could be just a single additional appliance deployed - when you click "Settings" on that screen you can define how many appliances will be deployed (to each or to just one host).
>> Are there any licensing considerations for deploying the additional agent?
No there are not - the licensing applies to protected resources (VMs, hosts, etc.) and does not restrict the amount of agents you deploy. You can have several agents (appliances) connected to the same vCenter and they will all use the same set licenses (1 license per host), regardless of the number of agents.
>> Could we accomplish the same thing by deploying an agent for VMware on a Windows system, pointing it to the management server of the existing All-in-One appliance, and then binding the new agent as detailed above?
Yes, this is also one of the options - the agent type (appliance or Windows) does not really matter here.
Note that if you would use this Windows agent for protecting VMs then the data will be read over network (NBD transport method) instead of attaching backed up virtual disks to the agent machine (HotAdd transport method used in case appliance). This would happen unless you install agent inside a Windows VM running on one of the ESXi hosts - in this case this agent will act exacly like appliance: the backed up VMs virtual disks will be attached to this Windows VM during backup (HotAdd method) for direct data access avoiding network utilization.
Thank you.
- Log in to post comments

Perfect, thanks for the explanation.
We might try setting up an Agent for VMware on the Windows system that stores the backups and see how it works out and how it affects the total time for the backups.
- Log in to post comments