Understand agents

Written By Tami Sutcliffe (Super Administrator)

Updated at June 17th, 2024

What is a backup agent? 

Note: All x360Recover protected systems require a backup agent.   

The agent is software installed on a protected system which performs the backup and sends the backup data to the local appliance. 

  • The agent software must be installed on each system to be protected.
  • After an appliance is deployed at a customer location, you can begin to download and install the agent software on protected systems. 
  • Backups of protected systems are image-based.
  • The agent can be installed on a Windows workstation or server.
  • You can install and uninstall agent software without the need to reboot the target device, reducing the impact to the customer environment. 

Agent requirements, parameters and prerequisites 

x360Recover Agent Configuration Parameters [PDF]


  • Configurations are case sensitive.
  • Boolean should be true and false and nothing else.
  • As a general rule, when several configurations are allowed they can be split by comma ","
  • Line comments are defined by #

Supported operating systems for agents 

Supported Operating Systems 

  • Server 2003 R2 *
  • Server 2003 R2 64-bit *
  • Server 2008 32/64 bit SP2 *
  • Server 2008 R2 SP1 * 
  • Server 2012
  • Server 2012 R2
  • Server 2016
  • Server 2019
  • Windows 8/10
  • Windows 7   SP1 
 * Microsoft Server 2003 and 2008 systems are deprecated and end-of-life. Although x360Recover is able to perform backups for these operating systems, support is limited to basic troubleshooting and diagnostics.

 Supported Filesystems

  • Microsoft NTFS 
  • Cluster Shared Volumes (CSVFS)**
 ** Requires Agent 2.24+ and Appliance 9.0.0+

Supported Networking

  • 1G Network Adapters and Switches
  • 10G Network Adapters and Switches 

 Supported DR Recovery Mechanisms

  • Bare-Metal Restore
  • Virtual Disk Export
  • iSCSI
  • Direct Virtualization

Supported Application Aware Backups

  • Microsoft Exchange Server 2003
  • Microsoft Exchange Server 2007
  • Microsoft Exchange 2007 
  • Microsoft Exchange 2010
  • Microsoft Exchange 2013
  • Microsoft Exchange 2016
  • Microsoft Exchange 2019
  • Microsoft Exchange DAG Groups **
  • Microsoft SQL Server 2005
  • Microsoft SQL Server 2008
  • Microsoft SQL Server 2008 R2
  • Microsoft SQL Server 2012
  • Microsoft SQL Server 2014
  • Microsoft SQL Server 2016
  • Microsoft SQL Server 2017
  • Microsoft SQL Server 2019
  • Oracle Database versions with Oracle VSS Writer installed
  • Other third-party Database software with their own VSS writer services

*Microsoft no longer supports this operating system. Although x360Recover can perform backups, support is limited to basic troubleshooting and diagnostics.

 ** Only the Active Cluster member in the DAG group will receive a VSS-aware backup of the message store. Passive cluster members will receive a crash-consistent backup.  (This is a Microsoft limitation of the Exchange VSS Writer.)

Supported Virtual Disk Formats

  • VMDK (VMware ESX/ESXi 3.x-6.x)
  • VMDK (VMware Workstation / Fusion)
  • VHD (Microsoft Hyper-V Gen-1 / Xen)
  • VHDX (Microsoft Hyper-V Gen-2)
  • VDI (VirtualBox)
  • RAW (KVM)


As an administrator, you will install the agent onto each protected device that you support. Before you begin, complete the following prerequisites for each protected device:

  • Uninstall third-party backup agents.
  • You must uninstall previous backup agents before installing the agent. Backup agents from other products can interfere with the ability to properly access VSS writers and successfully create backups.
  • Record the IP address of the appliance.
  • During the agent installation process, you will be prompted to enter the IP address of the appliance.
  • Check license availability.
  • The agent will not back up a protected system without a license. Log in to the appliance and check to be sure you have a license available for the protected system. To add or remove licenses, visit the Licensing Portal.

TCP Ports 

  • 9090-9200 is required if a firewall exists between the agent and the appliance.
  • 15000 internally is required for virtualization.
  • 860 and 3260 internally is required for an iSCSI connection to the appliance.

Important notes 

Please note the following:

  • Image-based backup and recovery can be a network-intensive operation. x360Recover does not recommend deployment on networks slower than 1Gigabit between the BDR and the protected system.
  • x360Recover does not support the backup of NTFS volumes shared between multiple services using Microsoft clustering.
  • x360Recover expects a standard Windows partition layout. Uncommon configurations (like custom OEM partitions, boot volume not on Disk 0, C drive not on a primary partition, etc.) might prevent successful virtualization.
  • x360Recover does not support recovery scenarios where multiple volumes exist on a single disk (for example, C and E on Disk 0). During recovery, each Windows volume will be created on a separate disk.
  • Most supported operating systems can be virtualized, except for XEN Server Virtual Machines with XEN-Tools drivers. XEN-Server 7.x+ paravirtual drivers are incompatible with the KVM Hypervisor used by x360Recover.
  • x360Recover currently does not support bare metal recovery onto systems that utilize Windows-only drivers. These drivers are typically embedded motherboard RAID controllers on very low-end servers or mid-range workstation devices.
  • The x360Recover Bare Metal Restore Wizard cannot recover systems with multiple Windows volumes on a single physical disk (for example, C and E on Disk 0). 

Hyper-V backups 

Host-level Hyper-V backups 

We do NOT recommend Hyper-V host-level backups (even though they are possible) 

Background: Why Hyper-V host-level backups are (technically) possible

  • The x360Recover backup agent uses Microsoft VSS, which typically can take successful snapshots of the entire host hypervisor system, including the VHD(X) files associated with running VMs. 
  • Hyper-V has a VSS writer that allows it to coordinate with the VSS snapshot process. This means it can safely take snapshots of VMs that x360Recover can backup.
  • Our FastDelta change detection mechanism is optimized for capturing change in large files, like virtual disk images. This makes it possible (and relatively straight forward) to deploy a single agent on the Hyper-V host to capture ‘backups’ of multiple running guest virtual machine systems.

Why don't we recommend Hyper-V host-level backups? 

Recovery is much more challenging when accessing VMs from a host-level backup:

1. Our backup appliances and Virtual Office cloud virtualization don’t support nested virtualization. This means that although you can quickly virtualize the Hyper-V host on one of our backup appliances or in our cloud, you'll be unable to do the nested virtualization needed to immediately turn on and recover the child VMs. You’d have the VHD(X) files with the data for those VMs -  but you would have no way to run them locally (or in the cloud) in a disaster recovery scenario.  

2. The only ‘backup’ of your virtual machine guests would be the raw virtual disk file, VHD or VHDX. This makes it difficult to do simple file and folder recovery. You would have to download the entire virtual disk image and mount it somewhere else before performing file and folder recovery.  

3. If you backup your protected systems at the hypervisor host level, you lose the most important part of your backup integrity checking:  AutoVerify. The nightly boot check would only be able to check the hypervisor host itself; It would not check any of the guest virtual machines that represent the primary data set you are backing up.

What we DO recommend 

  • Instead of installing the agent on the Hyper-V host,  install a backup agent directly onto each Hyper-V guest virtual machine

In this way, all systems will be backed up directly and each system can be virtualized in our cloud (or on the local appliance) - instantly, and without any issues. 

Additionally, nightly boot checks will be performed individually for each protected system, and all normal recovery options will be available. When failing back to the Hyper-V host, files can easily be restored as VHD(X) disk images again and configured as guest virtual machines. 


  • We don’t officially support backing up Hyper-V hosts natively (in order to back up the guest virtual machines all at once.)
  • Instead, we strongly encourage installation of the backup agent inside of each individual virtual machine. This ensures the best possible backup results, including accurate data integrity validation and a efficient recovery experience for you and your clients.

Agent best practices 

The x360Recover agent is designed and intended to work out of the box, without any special modifications in most cases. That said, there are still a few best practices that partners should consider:

Third party backup agents 

In general, Axcient recommends running only a single backup agent on your protected system. 

However, we realize you may sometimes need to run concurrent backup solutions (for example, during a transition from one platform to another.)

The x360Recover agent has been tested to successfully coexist with a wide variety of third-party backup solutions, including both image-based and file-based solutions.  

  • If there are other non-Axcient backup agents installed on the machine we recommend that these other backups be configured to run at a different time than the x360Recover backups. This will prevent potential VSS snapshot collisions or high system utilization due to concurrent backup operations (which might impact user experience.)

Axcient x360Recover backups should be able to run successfully on the same machine configured with other backup vendors when necessary.

VSS snapshot disk space requirements 

You'll need to verify that volumes have enough free disk space for Microsoft VSS snapshots. 

You'll also need enough free space available on the volume to satisfy data changes that might occur to the volume during the backup.  For the initial full base image backup, this might mean hours (or even days,  in extremely large systems.)  If the volume runs out of free space during a backup, Windows will automatically ‘free’ the VSS snapshot in use, causing the backup to fail.

  • We recommend that the shadow storage limit be set to at least 10% of the total size of the volume
  • If a given volume has less than 15% free space, we recommend redirecting VSS shadow storage to another volume with more free space.
  • To do this, run the following command from an elevated command prompt: 

    vssadmin resize shadowstorage /for=X: /on=Y: /maxsize=30GB


    1. Change X: to the volume that needs to have its shadow storage area redirected
    2. Change Y: to the volume that should contain the shadow storage
    3. Change 30GB to the amount of space to reserve (This should be at least 10% of the total size of the volume being redirected)

Reduce application-level backups 

Some applications have an option to generate file-level backups of their data and configurations.

This means scheduled application-level backup jobs might be writing large amounts of data to volumes that will also be backed up by x360Recover.


  • Microsoft SQL server configured to take daily full database dumps, saving to a local volume
  • Windows backup configured to take full disk backups and save them to a local volume
  • Quickbooks generating large backup files on a regular basis.  
  • While x360Recover can backup these backups, doing so causes the total daily incremental data changes to be very large.  In fact, these large incremental data changes can possibly exceed what can be uploaded by the system’s internet bandwidth in one day. 

    In general, x360Recover can capture the underlying application and database files successfully on its own. So, making such application-level backups is not necessary and can lead to excessive storage use on your backup appliance (along with prohibitively large incremental backups that are difficult to replicate off-site.)


    • If you must make application-level backups, please store them to a local storage location that is excluded from x360Recover backups
    • QuickBooks may automatically generate application-level backups periodically when opening or closing the application. These daily backup files can be fairly large, but as long as the frequency of backups is not excessive, we recommend allowing Quickbooks to make such backups.
    • Some third-party business applications built on Microsoft SQL or other database platforms may produce automatic file-level backups on a schedule. Often, the product support for these types of applications requires that such backups be performed.  If the data change generated by such backups is excessive, we recommend configuring the backups to be stored on a disk volume excluded from x360Recover protection.

Check Windows system health 

When deploying a new x360Recover agent, it is a good idea to evaluate the overall health of the system about to be protected.

Corrupt Windows system files can cause surprise issues with (a) Microsoft VSS snapshots (causing backups to fail) or (b) the P2V process required for instant backup virtualization.

To check for corruption in Windows system files (and get repair instructions), run:

sfc /scannow

Disk volume fragmentation 

Disk volumes which are filled near to capacity (or have been filled near to capacity in the past) are likely to have a high level of file fragmentation.

Fragmentation occurs when there are no open disk spaces large enough to store a file in a single chunk. When this happens, the blocks must be written to disparate parts of the disk. 

  • Highly fragmented disk volumes can cause severe performance problems, especially when attempting to virtualize the system later during a disaster recovery.  If you suspect there is heavy fragmentation on the system, and the system is a physical machine with hard disks (and not flash storage), then defragment the volumes on the system prior to the first full backup.

The best time to defragment a volume is before the first full backup is taken of the system.

Note: Since x360Recover is an image-based backup solution, defragmenting a disk volume may cause an excessive amount of data change that will be included in the next backup.  Even though the files are not changed during a defrag operation, reorganizing the block data on the drive will be detected as change by the agent.  Remember: The best time to defragment a volume is before the first full backup is taken of the system.

Important note: Do not perform disk defragmentation on a schedule!  This will generate excessive and unnecessary block change and impact backup storage consumption for little reason.

Antivirus scanning issues 

Axcient strives to conform to all recommended coding and security practices. 

Our x360Recover agent software is signed by an extended validation code signing certificate, and we follow Microsoft documented best practices and use cases. 

That said, the x360Recover agent is operating at a low system-hardware level to achieve successful image-based backups and occasionally, in rare instances, we have encountered issues with certain antivirus solutions. 

  • Generally, if problems occur, the issues involve heuristic-based scanners (like Sentinel One). Heuristic-based scanners rely on artfully analyzing applications behavior in real-time. This is in contrast with the more commonly used signature-based scanners whose detection uses specific chunks of code (or signatures) to identify malicious software. 
  • If you suspect that your antivirus solution is affecting your x360Recover agent, refer to this article Exclude an agent from anti-virus scans or contact Axcient Support for assistance.


 SUPPORT | 720-204-4500 | 800-352-0248