Using Veeam Replicas for Granular Restore Points

Recently, when I attended the Toronto vForum, I found myself hanging around the Veeam booth … a lot. I know quite a few of the local folks, so I enjoy chatting with them. They also work with me on my Veeam User Group, so sometimes the conversation steers that way too. But, I also have a passion for helping people. Given that I usually have some form of Veeam swag on, it isn’t uncommon for me to get questions from folks who assume I’m an Systems Engineer. I am always very quick to point out that I don’t work for Veeam, and I find that usually changes the tone of a conversation. Folks like hearing from customers, the good and the bad. I’ll usually try and loop an SE is as well since a) it’s not my booth and b) they will have different experiences and potentially different suggestions.

While at the vForum, I was talking to one gentleman about using Veeam for replication. He was aware of the feature but wasn’t entirely sure what he could do with it. I ran a similar setup in that I replicated to old hardware, and although performance would be abysmal if I needed to run my workloads on there, at least I had a copy. We then touched on the recovery of files from replicas, a feature he wasn’t familiar with. After talking to him, I wondered how many other folks aren’t aware of that feature, hence this post. So, let’s have a run-through of how to recover from replicas, and why would you want to.


When do most businesses do backups? I’m sure the answer varies quite widely depending on all sorts of variables. I’d also be willing to bet that a lot of SMBs, and potentially the majority of organizations, do them at night. What happens if someone creates a file at 9 AM and works on it all day until 4 PM, and accidentally deletes it at 4:30 pm? Because it is outside of your backup window, you won’t be able to restore it because it was never backed up.

Let’s take this same example and suppose you replicate every hour. Well, you can fire up Veeam and restore the file from a replica. This is also handy for cases where a file was accidentally overwritten and you may not necessarily need the version back from the night before. It’s important to note the distinction between backup jobs and replication jobs, as their use-cases are quite different. Backups will typically have longer retention pools, but the frequency will likely be something like once a day. Replication on the other hand typically has shorter retention pools (e.g. 10 restore points), but occur more frequently, such as once an hour.

It is also worth mentioning that if you have a Veeam Backup & Recovery license, then this feature is ‘free’. Free in the sense that you don’t need a vSphere license for the host that your data is being replicated to – you can replicate to an ESXi Free host, which is awesome. This is also why I use old hardware: it is something that I have kicking around, it gives me better data availability, and there is no new cost.


From the ‘Home’ view, choose Restore –> VMware (or Hyper-V if that’s your thing).

Veeam - Restore from replica 01

On the right hand side of the window, we’ll have a list of replication restore options. Choose the type of restore you want to do. In my case, it is a File Level Restore.

Veeam - Restore from replica 02

Select the replication job and VM you want to restore from.

Veeam - Restore from replica 03

Select the snapshot to restore from. In this example, the job is run every 6 hours, so I’ll have multiple points from the same day to choose from.Veeam - Restore from replica 04

After this, you can finish up with the Wizard. Veeam will automatically pop up the ‘Backup Browser’ at which point you can find the files you need and restore them as you see fit.

Veeam Backup Browser


To wrap things up, using Veeam for replication isn’t just about failovers (but that is a fantastic feature). Rather, you can leverage these points in time to get additional short-term restore points, without affecting the length of your backup chain. Another consideration is that you can replicate to a host with a datastore that resides on physically different storage than your backups. In this case, if your backup repository dies, you’ll still have a copy of the VMs (but remember, the retention limits will likely be different).