Altaro Continuous Data Protection

Altaro v7.6 introduces a Continuous Data Protection (CDP) feature which reduces data loss by providing Recovery Point Objectives (RPO) of up to 5 minutes. Altaro CDP works by saving a point in time copy of the virtual machine based on snapshots at set intervals, configurable per host or per virtual machine. The frequency options available are every 5 minutes, 15 minutes, 30 minutes, every hour, 4 hours, 8 hours, or 12 hours. Each version of a CDP backup is retained for 4 hours since the last successful backup, after this CDP backups are merged into a single recovery point and kept in accordance with your own configured retention policy.

Altaro v7.6 is available now, you can read about what is new in v7.6 here. CDP is initially available for Hyper-V, with VMware expected mid Q2 this year. This post will be updated when VMware CDP compatiblity is added.


Configuring CDP

  • If you do not already have Altaro VM Backup installed see the Altaro VM Backup Install and Overview post. You can download a copy of Altaro here.
  • The CDP Settings option can be accessed from the navigation pane of the Altaro VM Backup management console, under Setup. Hosts that have been added to Altaro are listed, along with any discovered VMs.
  • Use the Enable CDP check box and Maximum Frequency drop down to configure CDP with the desired settings.


  • When configuring CDP there should already be a backup schedule and backup location in place for the virtual machines. If you have not yet configured this part then see the install and overview post referenced above.
  • Click Save Changes to commit the CDP configuration.


  • The first time you configure CDP backups the VM Backup management console will display a warning about the Backup Health Monitor. The Backup Health Monitor verifies the state of backup data, during which time backups cannot run.
  • Depending on your environment and desired configuration you can change the schedule of the Backup Health Monitor to not conflict with CDP backups.
  • Once CDP backups are in use they become available restore points for restoring virtual machines.


  • The Backup Health Monitor can also be configured from the navigation pane under Sandbox & Configuration.


In summary, Altaro CDP boosts business continuity by allowing administrators to recover to a more granular point in time; thereby reducing data loss from virtual machine restores. The feature is easy to configure and the frequency options provide near continuous data protection with the maximum data loss being up to 5 minutes, this along with application consistent backups should be sufficient protection for most business critcal applications. When planning implementation of a CDP model you should consider other factors such as network bandwidth, and hypervisor performance, for example having a high number of machines taking snapshots every 5 minutes on the same host may add a CPU/memory overhead.

Altaro v7.6 is available now, you can download here.

Altaro VM Backup 7.5 Install and Overview

In this post we will install and configure Altaro VM Backup 7.5 whilst taking a look at the some of the key features. Version 7.5 introduces cloud backup to Azure and restore from Azure to Altaro instances in different locations. The Cloud Management Console (CMC) allows for users to monitor and manage all installations of Altaro through an intuitive and easy to use web client accessible anywhere. Support for vSphere 6.5 is also now included, for a full list of the new functionality see this post.


Altaro allows users to backup VMware and Hyper-V environments; taking application and file consistent backups of Windows, Linux, and applications compatible with the Microsoft VSS writer including Exchange and SQL. Backups benefit from compression, inline deduplication, and military grade encryption configurable right down to individual VM level. Granular restores also allow for individual file or email restores, as well as sandbox restores. Furthermore Altaro’s unique Backup Health Monitor proactively monitors backups and automatically repairs or replaces any corruption as part of the next backup job. Advanced automation and reporting can be configured using Altaro’s built in REST API. Altaro has easily accessible pricing and licensing information, and multiple channels to engage technical support including live chat from within the management console itself.

  • See the graphic below for a summary of Altaro features for each licensing option. For full product, version, and pricing information click here.
  • The Altaro VM Backup Quick Start Guide can be reviewed here, and full product user guides here. Altaro Support and FAQ can be accessed here.



The installation of the main backup console is simple and quick. Download the installer to a Windows machine and run as administrator. Accept the license agreement, set the destination, and hit Install. Altaro VM Backup can run on 64 bit versions of Windows 7, 8, or 10, and Windows Server 2008 R2 through to Windows 2016 (including Hyper-V and Core versions).

Once the install has completed open the management console. The VM Backup management console offers an intuitive user interface, allowing for local or remote management of multiple Altaro instances. In this example we’ll connect to the instance running on the local machine.


After connecting to the new instance the dashboard will load with a handy quick setup workflow.


Step 1 is to add the hosts to backup. In this example we’re using VMware so after clicking Add Hyper V / VMware Host select VMware vCenter Server and Next.


Enter and validate the vCenter Server information using Test Connection, click Next.


Review the hosts detected and click Finish. The hosts and inventory information from the specified vCenter Server are now added to the management console. We can see the host status and number of VMs for each host that has been added.


The product comes with a 30 day fully functioning trial. At any time you can install a license key by clicking Manage License under Setup and Hosts.

Step 2 is to configure a backup location, this can be a physical drive or network path. From the dashboard workflow click Choose Where to Store Backups.


For the purposes of this lab installation we will use the data drive of the Windows server.


Multiple backup locations can be added. Once a backup location is configured you can drag and drop VMs, clusters, datacenters, or vCenters into the appropriate area. After adding a local or LAN based backup location you can also add an offsite location, such as a WAN or Azure target. When the objects you require backing up are all assigned a backup location click Save Changes.


The final step in the workflow is to take our first backup, to take an on demand backup straight away click Take First Backup. Backup schedules and retention policies can be configured from the navigation menu on the left hand side. You’ll also notice Notifications and Advanced Settings where deduplication, encryption, and CBT can be configured on a per object basis, as well as providing the ability to exclude certain drives. Application consistent backups and truncating logs can be enabled under VSS Settings.

Cloud Management Console

The Cloud Management Console (CMC) can be accessed here. When you first login the getting started dashboard will be displayed, use the workflow to link an Altaro VM Backup installation.


A one time access key is generated to link the Cloud Management Console with the Altaro VM Backup installation. From the management console click the CMC button and enter this code to pair the installation with the CMC.


Once CMC is paired with your Altaro VM Backup instance you can monitor and manage the backup environment using the web client. Multiple installations can be added to CMC.


VMware NSX Backup and Restore

This post will detail how to backup and restore NSX. NSX configuration and components configurable through the NSX Manager UI or API are included in the NSX Manager backup. This includes controller nodes, Edge configurations (Distributed Logical Router, Edge Services Gateway), firewall rules, etc. as well as all events and audit log tables. Virtual switches are included in the vCenter Server database backup. When planning a backup strategy for NSX consider the following:

  • NSX Manager backups can be taken on demand, or scheduled at hourly, daily, or weekly intervals.
  • Ensure that the vCenter Server (and database if external) are backed up and factored into the NSX backup schedule. For example if you need to restore the entire environment it is recommended that the NSX Manager backup is taken at the same time as vCenter Server.
  • The only method of backup and restore for NSX Manager is with FTP/SFTP. Using any other method to backup NSX components could result in errors when restoring objects and is not supported by VMware.
  • When restoring NSX Manager a new NSX Manager is deployed and the configuration restored. The restore process of NSX Manager is only compatible from an NSX Manager of the same version. Therefore it is important to backup NSX Manager both before and after upgrades.

NSX Manager Backup

As outlined above, NSX configuration is backed up using the NSX Manager. Open a web browser to the IP address or FQDN of your NSX Manager. Log in with the admin user.


From the home page select Backup and Restore.


Click Change next to the FTP Server Settings row.


Enter the details for the destination FTP/SFTP server, add a filename prefix for the backup files, and configure a pass phrase. Make a note of the pass phrase in a password safe since this will be needed for restores.


Optional – next to Scheduling click Change to configure a backup schedule.


Optional – next to Exclude click Change to logs or events from the backup.


Once the backup server is configured backups will run as scheduled, or click Backup to backup NSX Manager now.


Click Start to confirm the backup job.


Completed backups will be listed in the Backup History table.


To remove a backup you can delete the files from the FTP/SFTP server and it will be removed from the Backup History table when the browser page is refreshed.


NSX Manager Restore

To restore NSX configuration a new NSX Manager must first be deployed. While it is possible to restore NSX configuration from an existing NSX Manager it is assumed that since a restore is required NSX Manager has failed and it is best practise to deploy a new instance. For assistance with deploying NSX Manager see this post.

Ensure the old NSX Manager is powered off. Deploy a new NSX Manager instance and configure it with a management IP address (this will be temporary, all settings will be reverted back to the previous NSX Manager after the restore is complete).

Log into the newly deployed NSX Manager and select Backup and Restore.


Click Change next to the FTP Server Settings row.


When configuring the FTP Server Settings ensure the same settings are configured as when the NSX Manager was backed up. This includes the hostname, username, password, backup directory, filename prefix, and pass phrase.

Select the backup from the Backup History table and click Restore.


Confirm the restore when prompted. NSX Manager is unavailable during the restore process.


When the NSX Manager is available log in, the summary page will display a System restore completed message.

vSphere Data Protection Install Guide

This post will walk through the installation of vSphere Data Protection (VDP) 6.1.3; a vSphere integrated backup and recovery solution. Data Protection is based on EMC Avamar deduplication backup and recovery software, and can also integrate with EMC Data Domain for scalability. In addition to full virtual machine backups vSphere Data Protection offers file level restores, application level backup and restores,  backup data replication to remote sites, and reporting. An emergency host level restore feature has been added for situations where the vCenter Server or web interface is unavailable. For more information on the features available to vSphere Data Protection 6.1.x see this technical overview.

Design Considerations

  • vSphere Data Protection is deployed as an OVA template.
  • The virtual appliance can be deployed with the following configurations:
    • 0.5 TB backup datastore, 873 GB disk space, 4 vCPU, 4 GB memory.
    • 1 TB backup datastore, 1600 GB disk space, 4 vCPU, 4 GB memory.
    • 2 TB backup datastore, 3 TB disk space, 4 vCPU, 4 GB memory.
    • 4 TB backup datastore, 6 TB disk space, 4 vCPU, 8 GB memory.
    • 6 TB backup datastore, 9 TB disk space, 4 vCPU, 10 GB memory.
    • 8 TB backup datastore, 12 TB disk space, 4 vCPU, 12 GB memory.
  • The backup datastore can be extended after deployment, up to the maximum size of 8 TB per appliance.
  • For assistance with sizing the appliance for your environment see pages 27 and 28 of the vSphere Data Protection Administratrion Guide.
  • To avoid block size limitations the appliance should be deployed to VMFS5 or later.
  • Each vCenter Server supports up to 20 vSphere Data Protection appliances.
  • Each vSphere Data Protection appliance supports up to 400 virtual machines however…
  • The amount of virtual machines each appliance typically supports is 150 – 200. This is dependent on factors such as the virtual machine size, the amount of changed data, and the date retention period.
  • By default Data Protection can backup machines utilising SAN, NAS, or VSAN datastores.
  • For hosts using DAS, or hosts in remote locations, external proxies can be deployed as virtual appliances from the VDP UI.
  • Up to 8 proxies can be deployed per vSphere Data Protection appliance.
  • Review the vSphere Data Protection 6.1.x Release Notes and vSphere Data Protection Administratrion Guide.


  • The table below lists the supported vCenter Server versions for 6.1 variations of vSphere Data Protection.


  • If you are using vCenter 5.5 U3 with Data Protection 6.1, 6.1.1, or 6.1.2, see this kb.
  • All variations of Data Protection 6.1.x support ESXi 5.1 through to ESXi 6.0 U2. For ESXi 6.5 version 6.1.3 of Data Protection should be used.
  • To check compatibility with any other VMware products see the Product Interoperability Matrix.
  • Editions of vSphere Essentials Plus and above (or vSphere with Operations Management / vCloud Suite) include licensing for vSphere Data Protection.
  • FQDN resolution must be in place. A forward and reverse DNS entry needs manually adding.
  • A static IP address is required for the VDP appliance and any additional proxy appliances.
  • The vCenter Server and attached ESXi hosts must be configured with an NTP server. The VDP appliance pulls the time configuration from vSphere.
  • The following disk types are unsupported: independent, RDM independent (virtual compatibility mode), and RDM physical compatibility mode.
  • Each virtual machine to be backed up should be running VMware Tools and hardware v7 or above.

Install VDP

Download the VMware vSphere Data Protection OVA here. The ISO is used for upgrades. Browse to the vSphere web client and right click the cluster where the virtual appliance will reside. Click Deploy OVF Template. Browse to the downloaded OVA file and click Next.


Review the OVF template details and click Next.


Accept the EULA and click Next.


Enter a name for the virtual appliance and select a location, click Next.


Select the datastore for the virtual appliance and click Next. Select the VM network to use and click Next.


Enter the network settings for the virtual appliance. Review the summary page, tick the Power on after deployment box and click Finish.


Configure VDP

DNS values for forward and reverse lookup must be in place for the configuration wizard. Manually add a DNS host record for the IP address of the virtual appliance and the desired host name and domain.

After deployment browse to https:\\:8543/vdp-configure, where is the IP address or FQDN of the vSphere Data Protection appliance. Log in with the root default password changeme.


The configuration wizard will load, click Next.


Enter a host name and domain for the appliance. The network settings are auto- populated, click Next. If DNS forward and reverse lookup values are not in place the wizard will fail at this point.


Select a time zone and click Next.


Configure a new root password for the virtual appliance and click Next.


Enter the vCenter Server details and click Test Connection. If successful click Next.


Select the size of the datastore to create for backup data, click Next.


Select the storage to use and the provisioning type, click Next. Accept the default CPU and memory allocations and click Next.


Select or leave the Customer Experience Improvement Program check box and click Next.


Select whether or not to run performance analysis on the storage configuration. The performance analysis tests the read, write, and seek speeds of the underlying storage. Once ready click Next to apply the changes. Click Yes to confirm. The virtual appliance will now be reconfigured and rebooted.


This process can take around 15 minutes depending on your infrastructure. When the appliance is back online a VDP icon will be added to the home page of the vSphere web client, default alarms are also added.


To view and change settings related to the virtual appliance you can log back into https:\\:8543/vdp-configure, where is the IP address or FQDN of the vSphere Data Protection appliance.


The installation is now complete and you can begin scheduling backup jobs using the Create Backup Job wizard.


VCSA 6.5 Backup and Restore

The vCenter Server Appliance got a bunch of extra features in vSphere 6.5. One of which is native backup and restore functionality utilising the vCenter Server Management API. The vCenter Server database, configuration files, and alarms can be backed up to minimise the time required to restore data centre operations. There is also the option of including statistics, events, and tasks. The backup process compresses key files into a tar bundle, which can be encrypted if desired.

In this post we will walk through configuring a backup of the vCenter Server Appliance and then restoring it. For more information see the vSphere 6.5 Documentation Centre. A backup job can also be invoked as a cron job from a bash script, for an example click here.


The backup procedure is done through the VCSA appliance management page. Browse to https://VCSA:5480, where VCSA is the IP address or FQDN of your vCenter. Log in using the root password.


You will see the vCenter Server Appliance dashboard. Locate the Backup button in the top right of the screen.


Select the protocol, location, and credentials to use for the backup, and then click Next. Supported protocols are FTP SFTP, HTTP, HTTPS, and SCP. The location must be an empty folder. In this example I will be backing up the VCSA to an FTP server.

Should you require backups to be encrypted select the Encrypt Backup Data tickbox and supply a password.


Select the data to backup and click Next.


Review the summary page and click Finish.


The backup will now proceed and a status bar will be displayed.


Once the backup is complete click Ok.



Should we ever need to restore the VCSA from a backup the procedure involves deploying a new appliance, and importing all data and settings from the backup. Before beginning the restore process ensure the old VCSA is not powered on, as this would cause an IP address conflict.

If your virtual appliance still exists in vCenter consider deleting or renaming the old appliance. During the restore process you can configure the network settings and host name of the old appliance; however you will not be able to give the the new appliance the same name as the old one since duplicate names cannot exist in the vSphere inventory.

Download the VMware vCenter Server Appliance 6.5 ISO from VMware downloads. Mount the ISO on your computer. The VCSA 6.5 installer is compatible with Mac, Linux, and Windows. Browse to the corresponding directory for your operating system, e.g. \vcsa-ui-installer\win32. Right click Installer and select Run as administrator. As we are restoring from an existing backup click Restore.


The installation is split into 2 stages, we begin with deploying the appliance. Click Next.


Accept the EULA and click Next.


Enter the details of the backup, this includes the protocol, location, credentials, and encryption password if applicable. Click Next.


Review details of the backup and confirm by clicking Next.


Enter the FQDN or IP address of the host, or vCenter upon which you wish to deploy the appliance. Enter the credentials of an administrator or root user and click Next. The installer will validate access, if prompted with an untrusted SSL certificate message click Yes to continue. Tip – connect to the vCenter for visibility of any networks using a distributed switch, connecting to the host direct will only pull back networks using a standard switch.


Enter the VM name and root password, click Next. Remember that this is the inventory name for the appliance as mentioned above.


Configure the deployment size for the vCenter, and click Next.


Select the datastore to locate the virtual appliance and click Next. Configure the network settings for the appliance and click Next.


Review the summary page and click Finish.


The new vCenter Server Appliance will now be deployed.


Once complete click Continue to move on to stage 2.


Stage 2 imports the data from the backup into the newly deployed appliance, click Next.


The backup is retrieved from the data we entered during stage 1. Click Finish to begin the restore. Note the warning about shutting down your original appliance, if it is still online, to avoid network conflicts.


Click Ok to the message that the restore cannot be paused or stopped.


The VCSA will now be restored.


When the restore is complete click Close. Log into the vSphere web client. The restored vCenter Server is ready to use.


Veeam Backup Error: Out of the Vector Bound

When running a backup job using Veeam Backup & Replication v8 or v9 the job fails with Error: Out of the vector bound. Record index: [0]. Vector Size: [1] Job finished with error. Running an active full produces the same result. In our case this issue was caused by corruption to the metadata file. This can occur when the metadata file is not properly closed and breaks the chain, potentially down to a file system filling up, or server failure.

To resolve we start a new chain to re-create both full data and metadata. This is done by cleanly deleting records about the backup job from the Veeam Backup & Replication console and configuration database, and deleting backup files themselves from the destination storage. The job itself remains so does not need recreating.

  • First disable the job; open the Veeam Backup & Replication client. Ensure Backup & Replication is selected on the task pane on the left hand side and select Jobs. Right click the failed job and click Disable.


  • Next we need to remove the corrupted files.  Still in the Backup & Replication task pane select Backups. Right click the failed job and click Delete from disk to remove the backup files and records.


  • Now go back to the Jobs page and enable the job. Run an Active Full to create new data and metadata files.