CPU and RAM
x360Recover recommends a minimum of 8GB of RAM and 4 CPU cores with support for Intel VT or AMD-V hardware virtualization. More RAM and CPU resources are recommended when protecting many systems, or if you plan to provide virtualization as a recovery option.
Notes on CPU and RAM
- RAM over 64GB and CPU cores greater than 8 will only impact performance when you are virtualizing many protected systems or when operating very large storage pools.
- Enabling Intel VT or AMD-V is required to perform virtualization of protected systems directly from the backup snapshot images.
Disks and storage pools
We recommend configuring the x360Recover operating system on a single dedicated hard disk:
- Use three or more separately dedicated disks for the backup storage pool.
- OS drives may be standard SATA/IDE, M.2, NvME, or SSD.
- 128-256GB is an optimal size for the OS volume.
For details on creating storage pools, see: Set up initial storage pool configuration
The storage pool should consist of three or more high-speed enterprise SATA/SAS or SSD drives, connected directly to the motherboard or non-RAID storage controller.
- Native ZFS software RAID is preferred over expensive hardware RAID. Native ZFS software RAID is preferred because of lower total cost, higher data integrity, better alerting and more recovery options when replacing failed disks.
Create the optimal storage pool using three or four disks in RAID-5 mode with LZ4 compression. (LZ4 provides faster performance, Gzip4 provides slightly better compression.)
Expand capacity in segments by adding the same number of disks to the system and using the ‘Expand Pool’ option.
Notes on disks and storage pools:
- By expanding the storage pool in smaller sets of disks, you (a) improve overall disk IO performance and (b) provide for a higher level of disk redundancy in the event of a failure.
- While RAID-6 can provide a higher level of redundancy than RAID-5 (allowing larger disk sets), the storage IO performance will be significantly impacted. We recommend RAID-5 mode.
For a detailed discussion on RAID types see: What is RAID?
For details on creating the storage pool see: Set up initial storage pool configuration
Hardware for appliances and vaults
Typically, appliances should be built using mid to high-end workstation or low-end server equipment, depending on the target environment.
Vaults should be constructed on low- to mid-range server equipment for performance and reliability.
Notes on hardware:
- Typical white-label hardware (without high-end video controllers, RAID controllers, or other add-ons) is generally well-supported by Ubuntu Linux.
- For a partial list of supported hardware, refer to the hardware compatibility list for Ubuntu 18.04 LTS
- We recommend dedicated IPMI or other out-of-band management. This helps ensure robust remote management options when maintaining your fleet of devices. IPMI (or Dell iDrac, HP iLo, etc.) can be valuable when you are remotely troubleshooting an offline appliance or vault.
Your hardware should provide one or more 1Gigabit or faster network cards, connected to the LAN where your protected systems are configured.
Note: VLAN support is not yet implemented. However, your appliance can support multiple VLANs. You can do this by providing multiple network adapters and configuring each switch port to the UNTAGGED mode on the corresponding VLAN. (Advanced VLAN configuration is planned for future implementation.)
Storage devices may be provided via software iSCSI to a NAS or SAN storage device.
To ensure good disk IO performance, we recommend using a dedicated high-speed 10Gigabit ethernet (or similar) for connection to iSCSI target devices. (Simple 1Gigabit iSCSI connectivity will provide poor disk IO.)
External IP Addresses (if you are hosting your own cloud)
Each vault and Management Portal instance running in your data center is an independent machine, using overlapping network ports. Each of these devices needs their own dedicated public IP address (unless you are using a third-party VPN tunnel solution to route traffic from your customer appliances.)
Public DNS records
Creating public DNS records for each device is optional but recommended.
Note on D2C endpoints on self-hosted private vaults: If you plan to deploy Direct-to-Cloud (D2C) endpoints to your self-hosted private vault, a DNS ‘A’ record for that vault’s public IP address is mandatory.
(If you are using the Axcient cloud, these details will be taken care of for you.)
For a complete list of all firewall ports needed by x360Recover, please see:
Appliance and vault installation requirements
- For best performance, we recommend that Axcient x360Recover be installed on bare metal.
- To install Axcient x360Recover as a virtual machine, refer to the Deploy x360Recover as a virtual machine (VM) article.
- Axcient x360Recover offers the flexibility to select your own hardware or purchase pre-configured BDR appliances.
- Axcient x360Recover BDR appliances provide exceptional performance and reliability using enterprise SATA or FastFlash SSD storage, along with our patented Durabit data integrity system.
- We recommend using a single disk volume for the operating system. As long as storage data is stored on separate disks, the protection of the operating system disk is not critical. (A recovery procedure is available to reload and restore all device settings from the storage pool.)
- Unless you are using a SAN, we recommend deploying three or more physical disks and using ZFS Software RAID when creating the storage pool. ZFS RAID is more robust than hardware RAID and x360Recover has been optimized to provide disk failure and replacement of ZFS volumes.
- When using a SAN, you may opt to create a RAID-0 storage pool consisting of iSCSI LUNs. (The disk redundancy will be provided by the SAN.) For optimal performance, create a RAID-1 storage pool using multiple 10Gbe network adapters to provide access to the iSCSI disk volumes. Ideally, each iSCSI volume should be provided by a separate SAN server.
- DHCP should be enabled on the network when installing x360Recover to simplify the startup network configuration of the device for licensing and initial software upgrade. During configuration or after setup has completed, a permanent static IP address should be assigned to the device so that agents have consistent access to the device.
Best Practices for deploying agents on Windows
Remove other third party backup software
x360Recover can generally co-exist with other third party backup agents and software, but you must give some consideration to backup scheduling. (Overlapping backups may impair system performance.)
We recommend removing other third party backup software, once your migration to x360Recover is completed and you have established sufficient recovery points to meet SLA requirements.
- Some legacy backup software, such as Backup Exec or Acronis may not completely remove their proprietary VSS extensions when uninstalled using Add/Remove Programs. We recommend using the specific stand-alone uninstaller utility if available, to help ensure proper cleanup and removal of these agents.
- Deploying x360Recover parallel with your existing backup agent may be a good method of migrating from your legacy solution to x360Recover. Both backups can run side by side until you have enough backup history within x360Recover to meet your SLA and retire the old solution.
Monitor frequent large file creation
- Perform a search for files greater than 50MB created within the last seven days. Verify that there are no ongoing large data dumps being performed on the server that can dramatically balloon the size of Axcient x360Recover incremental backup images. Some possible examples to avoid: SQL database backups; Quickbooks company file backups; PST File exports or copies, Windows Server Backup images, etc.
- If large file creation is discovered, alleviate the issue by disabling the source of the file creation, or retarget the file storage to a separate disk volume and then disable that volume from backup by the Axcient x360Recover agent.
- Applications that generate a large amount of change data on a frequent basis may cause high storage utilization on your appliance. We do not recommend capturing unnecessary data (such as other backup solution files, application-level backups of SQL or Quickbooks). These types of files should be excluded from backup if possible.
Verify settings for Volume Shadow copy Services (VSS)
- From an elevated command prompt, run ‘vssadmin list shadowstorage’ . Examine the volume shadow copy size column and verify that it is NOT set to UNBOUNDED
- The recommended default storage size is 10% of total space
- If less than 15% of the disk volume is free, we recommend redirecting shadowstorage to another volume with sufficient free space.
For details on managing your Volume Shadow Storage settings see: Configure Microsoft VSS
Customers and locations
- When deploying Axcient x360Recover to customers with multiple locations, create only one customer account within the License Portal and assign multiple locations to the account.
- Each customer location will have its own appliance for local backups.
- For customer locations without an appliance (or to backup roaming devices such as laptops), deploy a Direct-to-Cloud agent on each endpoint. Note that Direct-to-Cloud endpoints do not belong to any ‘Location’. This means you do not need to create a location or assign licenses in the License Portal for Direct-to-Cloud backups.
Networks, switching, and routing
- Appliances should be connected to the same physical LAN and VLAN as the protected systems they are guarding. Avoid transporting data through firewalls or routers to alleviate network congestion and performance bottlenecks.
- Appliances and protected systems should be connected to 1Gigabit Ethernet switches or faster for best performance.
Perform backup scheduling on a 24/7 basis
- Axcient recommends performing backups on a 24/7 basis and not limiting backup windows strictly to expected business hours for the customer. Backups taken outside of working hours where no changes to data have been made will be extremely small and it is always better to have the option to restore from additional recovery points in the event of the unexpected.
Avoid scheduled defragmenting of disks
- Performing disk defragment operations on systems protected by image-based backup solutions can generate unnecessarily large incremental backups due to excessive block changes. We do not recommend performing frequent or regularly scheduled defragmentation operations on systems protected by image-based backup solutions like x360Recover.
Microsoft Exchange and SQL Server VSS agents
- The Exchange VSS agent is disabled by default on Windows Server 2003 SBS. Ensure that this service is set to automatic startup and running to ensure consistent Exchange backups and log file cleanup.
- The Exchange VSS agent is set to manual by default on Exchange 2008 and newer. Ensure that this service is set to automatic startup and running to ensure consistent Exchange backups and log file cleanup.
- Verify that the Microsoft SQL VSS Writer service is set to automatic and is running to ensure consistent backups of Microsoft SQL databases.
Important note: We recommend enabling FastDelta mode for protected systems where Microsoft Exchange or Microsoft SQL will be backed up.
SUPPORT | 720-204-4500 | 800-352-0248
- To learn more about any of our 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 a list of status updates and scheduled maintenance.
888 | 1061 | 1298