Version 9
WAN-Optimized Replication allows businesses to be back up and running in minimal time should disaster strike by switching to a replicated virtual machine (VM) that is running offsite.
Requirements
- .NET Framework 4.8 or higher is required
- It requires a new port to be opened on the AOS, specifically for Replication Data Transfer - 36100
- [Hyper-V] The Altaro Offsite Server must be installed on a Windows server OS which is the same as the one where production VMs are running. Below you can find a list supported OS's that you can replicate to:
Host OS Supported Replication Altaro Offsite Server OS 2012 to 2012 2012R2 to 2012R2 2016 to 2016 2019 to 2019 2022 to 2022 Azure Stack HCI to Azure Stack HCI - [VMware] The host added to the Altaro Offsite Server must be the same OS as the source host being replicated from. Below you can find a list supported OS's that you can replicate to:
Host OS Supported Replication Host OS 5.5 to 5.5 6.0 to 6.0 6.5 to 6.5 6.7 to 6.7 7.0 to 7.0 8.0 to 8.0 - [VMware] On ESXi hosts you will see the replicated VMs in the vSphere console when you enable replication for your VMs. It is imperative that you do not boot the VM outside of the Altaro Offsite Server. The replicated VM is fully managed by Altaro and will essentially end up discarding any changes made if booted outside of the Altaro Offsite Server.
Replicated VMs are NOT to be:
- manually started from vSphere (outside of Altaro Offsite Server)
- deleted from vSphere
- manual merging/management of disks/snapshots
Good to Know
- Maximum Replication frequency of 5 minutes can be achieved
- Windows Server 2016/2019/2022 and VMwware ESXi hosts will have multi-version support. You'll have the option to select from the 10 latest replicated versions upon Boot.
- Windows Server 2012 and 2012R2 will be limited only to the latest replicated version
- When replication is enabled, CDP will automatically be enabled with the same set frequency. Only enable high-frequency (15 minutes or less) on VM’s that you really need to. This will ensure that the VM’s you really need to will be able to achieve the selected maximum frequency and in order not to have an impact your Hypervisor's performance.
- [Hyper-V] Replication can only take place to the Hyper-V Host where the AOS is installed. In order to replicate multiple machines (different OS's), you will need a separate AOS installation with a matching OS.
- [VMware] One Altaro Offsite Server can handle multiple [Replication Target Hosts] and you can add all of your VMware hosts on the same site to this one AOS installation. The source Host OS must match the Replication Target Host OS.
- [VMware] On ESXi hosts you will see the replicated VMs in the vSphere console when you enable replication for your VMs. It is imperative that you do not boot the VM outside of the Altaro Offsite Server. The replicated VM is fully managed by Altaro and will essentially end up discarding any changes made if booted outside of the Altaro Offsite Server.
- All data being sent from Altaro VM Backup (AVMB) to the AOS will be fully encrypted in transit with WCF. This is decrypted on arrival on the AOS, so data is stored in plain text, ready available to be booted at a moment's notice.
- Backup / Restore / Retention / Backup Health Monitor operations will not interrupt Replication jobs
- Replication is independent from Offsite Backups, therefore offsite retention jobs will not affect any replication
- Backup performance will be limited to the throughput available for Replication to your AOS. Also Replication is dependent on the Primary backups. Essentially:
- If the Primary backup is slow; then Replication is slow
- If the Primary backup fails; then Replication fails
- If Replication is slow; the Primary backup will be slow
- If Replication fails; the Primary backup can still be successful
- Only local disks (Physically connected/iSCSI) are supported for Replication. ie: AOS account must specify a local disk not Network shares for target replication
- If you already have an AOS Offsite Backup repository an automatic seed from the offsite backups will take place, avoiding the first replica over the WAN connection. If this operation fails, replication will kick in and transfer any required data in order to successfully complete the VMs replication.
- Windows Server 2008R2
Booting the VM
From the AOS you'll be able to Boot up a Replicated VM whereby a new VM is added to Hyper-V.
VMware Hosts on the other hand will list the replicated VM in the vSphere console when you enable replication for that specific VM. It is imperative that you do not boot the VM outside of the Altaro Offsite Server. The replicated VM is fully managed by Altaro and will essentially end up discarding any changes made if booted outside of the Altaro Offsite Server.
Upon booting, replication is immediately paused for that VM and you'll have the ability to Restore the VM or Discard the changes.
If you choose to Restore, all of the user changes will be fully merged. If so, the previously replicated data won't be usable any longer for replication purposes then, a new target needs to be manually configured later on.
Recovery
If Replication takes long, misses a copy (due to connectivity issues for instance), a process to recover the changes lost since the last replication ran.
Basically, all the blocks since the last replication point, up till the current state of the VM (Primary backup) need to be computed in order to be included in the next replication run.
If the last successful replication version is not equal to last successful backup version, then Recovery is needed.
Please note that the changes to be re-transmitted will be added to the Primary backups' CBT (Changed Block Tracking) list. The Operation History will reflect this in the amount of changes backed up for the primary backups. You'll notice especially as you'll see a high percentage of savings.
Version 8
WAN-Optimized Replication allows businesses to be back up and running in minimal time should disaster strike by switching to a replicated virtual machine (VM) that is running offsite.
Requirements
- .NET Framework 4 or higher is required
- It requires a new port to be opened on the AOS, specifically for Replication Data Transfer - 35120
- [Hyper-V] The Altaro Offsite Server must be installed on a Windows server OS which is the same as the one where production VMs are running. Below you can find a list supported OS's that you can replicate to:
Host OS Supported Replication Altaro Offsite Server OS 2012 to 2012 2012R2 to 2012R2 2016 to 2016 2019 to 2019 2022 to 2022 Azure Stack HCI to Azure Stack HCI - [VMware] The host added to the Altaro Offsite Server must be the same OS as the source host being replicated from. Below you can find a list supported OS's that you can replicate to:
Host OS Supported Replication Host OS 5.5 to 5.5 6.0 to 6.0 6.5 to 6.5 6.7 to 6.7 7.0 to 7.0 8.0 to 8.0 (V9 BETA Only) - [VMware] On ESXi hosts you will see the replicated VMs in the vSphere console when you enable replication for your VMs. It is imperative that you do not boot the VM outside of the Altaro Offsite Server. The replicated VM is fully managed by Altaro and will essentially end up discarding any changes made if booted outside of the Altaro Offsite Server.
Replicated VMs are NOT to be:
- manually started from vSphere (outside of Altaro Offsite Server)
- deleted from vSphere
- manual merging/management of disks/snapshots
Good to Know
- Maximum Replication frequency of 5 minutes can be achieved
- Windows Server 2016/2019 and VMwware ESXi hosts will have multi-version support. You'll have the option to select from the 10 latest replicated versions upon Boot.
- Windows Server 2012 and 2012R2 will be limited only to the latest replicated version
- When replication is enabled, CDP will automatically be enabled with the same set frequency. Only enable high-frequency (15 minutes or less) on VM’s that you really need to. This will ensure that the VM’s you really need to will be able to achieve the selected maximum frequency and in order not to have an impact your Hypervisor's performance.
- [Hyper-V]Replication can only take place to the Hyper-V Host where the AOS is installed. In order to replicate multiple machines (different OS's), you will need a separate AOS installation with a matching OS.
- [VMware] One Altaro Offsite Server can handle multiple [Replication Target Hosts] and you can add all of your VMware hosts on the same site to this one AOS installation. The source Host OS must match the Replication Target Host OS.
- [VMware] On ESXi hosts you will see the replicated VMs in the vSphere console when you enable replication for your VMs. It is imperative that you do not boot the VM outside of the Altaro Offsite Server. The replicated VM is fully managed by Altaro and will essentially end up discarding any changes made if booted outside of the Altaro Offsite Server.
- All data being sent from Altaro VM Backup (AVMB) to the AOS will be fully encrypted in transit with WCF. This is decrypted on arrival on the AOS, so data is stored in plain text, ready available to be booted at a moment's notice.
- Backup / Restore / Retention / Backup Health Monitor operations will not interrupt Replication jobs
- Replication is independent from Offsite Backups, therefore offsite retention jobs will not affect any replication
- Backup performance will be limited to the throughput available for Replication to your AOS. Also Replication is dependent on the Primary backups. Essentially:
- If the Primary backup is slow; then Replication is slow
- If the Primary backup fails; then Replication fails
- If Replication is slow; the Primary backup will be slow
- If Replication fails; the Primary backup can still be successful
- Only local disks (Physically connected/iSCSI) are supported for Replication. ie: AOS account must specify a local disk not Network shares for target replication
- If you already have an AOS Offsite Backup repository an automatic seed from the offsite backups will take place, avoiding the first replica over the WAN connection. If this operation fails, replication will kick in and transfer any required data in order to successfully complete the VMs replication.
- Windows Server 2008R2 and VMware ESXi 5.0 hosts are not supported
Booting the VM
From the AOS you'll be able to Boot up a Replicated VM whereby a new VM is added to Hyper-V.
VMware Hosts on the other hand will list the replicated VM in the vSphere console when you enable replication for that specific VM. It is imperative that you do not boot the VM outside of the Altaro Offsite Server. The replicated VM is fully managed by Altaro and will essentially end up discarding any changes made if booted outside of the Altaro Offsite Server.
Upon booting, replication is immediately paused for that VM and you'll have the ability to Restore the VM or Discard the changes.
If you choose to Restore, all of the user changes will be fully merged. If so, the previously replicated data won't be usable any longer for replication purposes then, a new target needs to be manually configured later on.
Recovery
If Replication takes long, misses a copy (due to connectivity issues for instance), a process to recover the changes lost since the last replication ran.
Basically, all the blocks since the last replication point, up till the current state of the VM (Primary backup) need to be computed in order to be included in the next replication run.
If the last successful replication version is not equal to last successful backup version, then Recovery is needed.
Please note that the changes to be re-transmitted will be added to the Primary backups' CBT (Changed Block Tracking) list. The Operation History will reflect this in the amount of changes backed up for the primary backups. You'll notice especially as you'll see a high percentage of savings.