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]

Notes:

• 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 

Prerequisites 

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. 

• Hyper-V : Virtualize an x360Recover appliance or vault as a guest VM

Summary 

• 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 

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

  Notes:

  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.

Examples:

• 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.)

  Recommendations:

  • 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.

  Delete

• Third-party backup agents
• VSS snapshot disk space requirements
• Reduce application-level backups
• Check Windows system health
• Disk Volume Fragmentation
• Antivirus Scanning Issues

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

• Contact Axcient Support at https://partner.axcient.com/login or call 800-352-0248
• Free certification courses are available in the Axcient x360Portal under Training
• To learn more about any of our Axcient products, sign up for a free one-on-one training
• Subscribe to the Axcient Status page for a list of status updates and scheduled maintenance