Agent best practices - x360Recover

x360Recover BDR FAQs

Written By Tami Sutcliffe (Super Administrator)

Updated at January 22nd, 2024

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 

  • To learn more about any Axcient products,  sign up for free one-on-one training.
  • Please contact your Partner Success Manager or Support if you have specific technical questions.
  • Subscribe to the Axcient Status page for updates and scheduled maintenance.

888  |  1550