We have a physical server running Windows 2016 (with iSCSI volumes) and 200TB of data. We currently back up the server using a Veeam agent and forever incrementals to a Veeam backup repository (30 day retention). Thankfully, the daily increments have been relatively small in size.
However, we would like to virtualize this server. We do have two Vsphere 6.7 infrastructures, a primary site and a disaster recovery site. The 200TB VM will reside on iSCSI datastores using Powervault ME4 SANs (due to budget constraints).
Because of the server's large size and what should be a 72 hour RTO, I am planning to use Veeam Replication (primary to DR) and keeping 28 VM snapshot/restore points as the backup strategy; doing a traditional FULL recovery from a Veeam backup repository based on a 2Gbps throughput would unfortunately take ~9 days which exceeds the RTO, hence the different approach.
Is this idea sound and has anyone implemented this successfully in their environment with a VM of similar size? In theory it should work but are there any suggestions or considerations that I should be aware of? I do realize there are size limitations for Vsphere datastores. Also, I believe I can recover individual files/folders from the VM snapshots/restore points without breaking the Veeam replication chain.
If the above is a bad idea, any other Veeam suggestions/strategies to back up a 200TB VM that has an aggressive RTO?
Before someone suggests the idea, I am aware that the Powervault ME4 is capable of SAN snapshots - however, the technology is a little strange and requires a significant amount of additional storage to store the snapshot metadata. So SAN-based replication is unfortunately not an option.
Thanks.
-
- Novice
- Posts: 3
- Liked: never
- Joined: Jun 21, 2017 11:23 am
- Full Name: Marvin
-
- Veteran
- Posts: 370
- Liked: 99 times
- Joined: Mar 04, 2019 10:31 am
- Full Name: Stefan Zimmermann
- Location: Germany
- Contact:
Re: Strategy to backup a large VM (200TB in size)
Hi,
given that RTO requirement you have two choices (actually 3 if you also count CDP). Replication or Instant VM recovery. If instant VM recovery cannot satisfy your requirements (there will be a performance degradation as long as the move process is running), you can only use replication. There were some improvements to the IVMR engine in v11, so that might satisfy your requirements.
Otherwise replication is a valid way to go for to meet low RTO requirements. You can also have a look on replication from backups (though that means consuming space on repo and production storage - but at least you have a backup).
General BP apply: For larger VMs try to increase the number of VM disks rather than the size of single disks to leverage the parallel processing of VMDKs.
And yes, you can recover individual guest files from replicas.
given that RTO requirement you have two choices (actually 3 if you also count CDP). Replication or Instant VM recovery. If instant VM recovery cannot satisfy your requirements (there will be a performance degradation as long as the move process is running), you can only use replication. There were some improvements to the IVMR engine in v11, so that might satisfy your requirements.
Otherwise replication is a valid way to go for to meet low RTO requirements. You can also have a look on replication from backups (though that means consuming space on repo and production storage - but at least you have a backup).
General BP apply: For larger VMs try to increase the number of VM disks rather than the size of single disks to leverage the parallel processing of VMDKs.
And yes, you can recover individual guest files from replicas.
Kind regards, Stefan
Who is online
Users browsing this forum: AdsBot [Google], Bing [Bot] and 83 guests