Sync'ing on premises repository with public cloud

[mdb_ec]

Hi.

I'm trying to figure out if the following DR scenario can be addressed with Veeam B&R.

Say we have a main site with B&R running usual backups to a local server and repository. Backups are periodically copied to an offline repository (be it a NAS or tape).

We intend to send a copy of these backups to a public cloud (either send backup or VM replication).

Say disaster strikes at main site also affecting the B&R server and its repository. But the offline repository is unharmed.

DR can take place by spinning up VM's on the public cloud based on the backups (or replicated VM's) previously sent.

At main site physical servers are replaced including B&R server.

I want to failback VM's from public cloud to on premise, but not having to replicate all VM data, but to seed the on premise B&R server with the offline repository.

Can B&R take this outdated repository (say some days back) and request only deltas from public cloud to perform the failback of the VM's?

The usual seeding process, which involves producing a backup from the DR site and sending it over to the main site, would take too long to download over the internet. This is why I would use the offline repository.

Thanks

[HannesK]

Hello,
I'm thinking about in which situation everything get's destroyed except the repository. Because then I would put everything to the place where the repository is

To make it short: you wish is good, but not realistic. In DR case your machine is converted to something else (from Hyper-V to Amazon / Azure VM) or in case of VM based replication to a new VM at the service provider. To backup in EC2 or Azure, you will use a different technology / product to backup. Also changes will be huge before you rebuilt your on-prem location, that seeding is not really relevant anymore.

Best regards,
Hannes

[mdb_ec]

Hello, Hannes.

The repository that survives is offline and stored off site, it's broght on site and sent away for secure storage. It's updated say weekly.

Perhaps scenarios you've seen are different, but I'm describing a very realistic one. Just think of a database 1 TB in size that gets only few GBs updates daily. It makes a lot of sense if internet link is relatively slow.

What I'm worried about now is that you're considering the scenario as unrealistic rather than describing a way in which Veeam B&R can handle it, which makes me think maybe it cannot and I should look for another product.

Any other thoughts?

Thanks

[HannesK]

Hello,

it's broght on site and sent away for secure storage. It's updated say weekly.

so in worst case you have one week old backup in secured storage. This is probably not the source you restore from to Amazon / Azure (because one week old data is too old). Is my assumption correct, or would you restore one week old data?

Let's take the situation where you have a replication to a Veeam cloud service provider with Hyper-V. You have one week old backups and it takes a month, or maybe two to rebuild your on-prem server location. So at least 4 weeks change rate. At this point, the seeding from the old backup makes no sense for me anymore (well, technically it can work - but I would not suggest it). But with help of the service provider, you could create a seed and use that fresh data.

Just think of a database 1 TB in size that gets only few GBs updates daily.

what kind of database do you have, that does not do reorganizations and changes a lot more than the pure data? Change rates on databases (SQL etc) are usually pretty high, even if you only change small amounts of data.

For Azure / EC2 restores I see not technical way with Veeam to do seeding on failback. If you find a solution that can do that, I would be interested to hear about it The way with replication is something I consider as "ugly" - that's why I did not suggest it.

What I suggest is:
- use "Copy backups to object storage as soon as they are created " to have up-to-date backups in a safe place
- restore to Amazon / Azure in case of DR
- use Veeam Agent for Windows or Backup for AWS / Azure to backup in AWS / Azure (that needs to be planned and tested carefully to cover everything of your environment. Veeam Backup for Azure is not released yet - but you can use agents instead)
- use backup copy job to get the data back on-prem after you rebuilt the location
- restore from that to your on-prem Hypervisor

Best regards,
Hannes

[mdb_ec]

Hello, Hannes.

Let me rephrase why the seeding would be helpful:

Local Veeam B&R backs up to local repository and also sends backups (or replicates) over to public cloud regularly (daily or x times a day).
In parallel, the backup is copied weekly over to either a NAS or tape which is stored off site.

Disaster occurs.
I spin VM's in public cloud for DR. This from daily backups previously sent on regular basis, not from weekly backup on NAS.
I redeploy local equipment. Say it's only a couple of servers (not dozens). This can even be rented so it might take a week.

I want to have VM's running back in local site, but replicating or downloading a complete VM backup from public cloud to on premise would take weeks.
I would like to use the NAS or tape backup (which is only outdated a few days) as a starting point (seed) for rebuilding local VM's and only download from public cloud a delta with changes so far.

So I can schedule planned downtime, shutdown VM's in public cloud, download only backup delta from public cloud (over the weekend) and update VM backups on local repository, which would then be used to restore VM's on local servers updated to the same point as they were running in public cloud.

Can this be done?

Thanks

[HannesK]

Hello,
as I said, your idea is good. The point is, that platform (Hyper-V to Azure / EC2) and product changes (whatever fits best for you vs. Backup & Replication) do not allow seeding.

The only way for seeding I see is having a service provider that acts like a secondary data center.

downloading a complete VM backup from public cloud to on premise would take weeks.

You can start the "copy home" with the repository that survived directly after starting the VM in public cloud (assuming you have free disk space). For failback, you only need to transfer the daily incremental.

Best regards,
Hannes