On the other hand, backup files are 10x smaller (so take 10x less disk space and replication traffic).ĭuring your planning, consider that with version 5, you will be able to do the same thing (quoted above) with compressed backup files - without having to spend any time to actually restore VM from backup. As any normal VM, it does not need anything else to run - however, it takes 10 times more disk space and replication traffic (because Veeam Backup has to deal with uncompressed VMDK data). The benefit and drawbacks of using replicas come from the fact that it is full-blown VM.
#Veeam backup replication full#
This will save me days of work to do a full test and I will be able to perform it during the day.
The DR network would have no interaction with my production network. This way I can restore a VM in the DR site and the VM’s NICs will map to their normal NIC which is now on a DR network. All ESX server will have their NIC setup the same with the same name. I am placing extra nics in all my production ESX servers at both sites. My new DR plan I want to be able to mount the replicated DR VMs at will with little work. Larry wrote:I have two main sites, each are the DR of the other site. After using Veeam I keep finding new uses and DR will now be the most important. My main goal with Veeam was just to get a remote backup so I didn’t have the risk of shipping tapes.
I have two main sites, each are the DR of the other site. Unless I am missing something I see no reason to use any thing but Veeam for this. Even using Rsync I would be pulling the data over the WAN twice. Both are much, much quicker when changed blocks are used than using Rsync and the Veeam reports are much better. I also been using the Veeam server in the DR site to backup over our 100 meg WAN and that also works great. I been using Veeam to replicate to a remote esx and it works great. Veeam Backup will query latest changeID (USN), and because it will be lower than changeID memorized during latest backup, Veeam Backup will realize that storage rollback happened, and will not leverage CBT data for the given incremental pass - instead, it will scan the whole source image to determine blocks which actually differ from those stored in the latest state backup state. Yes, CTK information is stored with VM files, so this will be fine. So instead, you could contact your Veeam sales rep, and ask to share with you some existing presentations. But I find that some explanations are in UG are too technical and confusing for committee presentation. We will never know you did that Seriously though, it's fine to do. Based on the feedback so far, Linux RSYNC works best.ĭoes anyone use RecoverPoint to replicate backups off-site? This works very well, and this is what I would personally do if I needed to keep my backups offsite. Larry, for offsite DR our customers are typically using RSYNC or DFS-R to sync backups over to remote site.