Backing up Replicas - Advice?

[jlehtinen]

Hiya,

I've got a very small environment - two ESX hosts, one running production servers, one for off-site DR. I need to be able to capture replica snapshots of our "main" SQL server every 30 minutes in case of failover. (And I DO want to be using replicas here, for fast failover ability. I don't have the resources on my ESX hosts to handle the instant-on feature with backups.)

The problem with this is that I need to keep at least ~2 weeks of these snapshots, and I don't have the storage on my ESX hosts to handle this. To remedy, I purchased and setup a NAS to use as storage.

Here's my backup plan:

- Every morning around 2AM Veeam will capture a new full replica of the server, stored on the offsite DR host.
- Every 30 minutes during business hours, Veeam will capture a replica incremental snapshot, stored on the offsite DR host.
- Every night around 10pm, I'll move the full + all incremental replicas from that day to the NAS for storage.
- Next morning a fresh full backup is created, process repeats.

Could I be doing this a better way? The things I need are 1.) immediate failover ability on the DR site 2.) no more than 1 replica stored on the DR ESX host (not enough space)

[Gostev]

I don't have the resources on my ESX hosts to handle the instant-on feature with backups.

Hello, please keep in mind that both replica and instant-on backup require absolutely the same resources from ESX host to run it. May be you meant something else, but what is written above does not make much sense.

Here's my backup plan:
- Every morning around 2AM Veeam will capture a new full replica of the server, stored on the offsite DR host.
- Every 30 minutes during business hours, Veeam will capture a replica incremental snapshot, stored on the offsite DR host.
- Every night around 10pm, I'll move the full + all incremental replicas from that day to the NAS for storage.
- Next morning a fresh full backup is created, process repeats.

This will not work, as replication job will fail if it does not see the replica present.

Could I be doing this a better way? The things I need are 1.) immediate failover ability on the DR site 2.) no more than 1 replica stored on the DR ESX host (not enough space)

I recommend using backup job with long-term retention (to keep 2 weeks of data in space-efficient manner), and replication with short-term retention (just for immediate failover). Thanks!

[jlehtinen]

Gostev, thanks for the reply. Sorry if my question was not very clear.

To the best of my knowledge, when you use the instant-on feature, Veeam creates a duplicate copy of your backup file and then runs off of that. In my environment I do not have the space to host both the backups AND a second running copy of each backup for each virtual machine. This is why I preferred replicas - I can keep a single copy of the most current replica of each VM, and just power them on directly in case of disaster. That's what I meant by not having the resources to use instant-on.

I'm not sure I understand why the replication job would fail - I have created new, full replicas several times already in testing and have not had issues. I think I must not have been clear in what I said.

As for your recommendation - you're saying I should use both backup and replication jobs, backing up to the NAS for long-term backup, and to the off-site ESX for just the most current replicas?

[Gostev]

To the best of my knowledge, when you use the instant-on feature, Veeam creates a duplicate copy of your backup file and then runs off of that. In my environment I do not have the space to host both the backups AND a second running copy of each backup for each virtual machine.

No, that the thing - we do not create a duplicate copy. Instead, existing backup files' content is published to ESX host, and so effectively the virtual machine runs directly from backup file. By the way, backup file itself can be located on any storage (for example, on your NAS).

I'm not sure I understand why the replication job would fail - I have created new, full replicas several times already in testing and have not had issues. I think I must not have been clear in what I said.

Are you saying you have run the replication job a few times, then deleted all replica files it had produced on target, then run the job again and it did not fail? Hard to believe

As for your recommendation - you're saying I should use both backup and replication jobs, backing up to the NAS for long-term backup, and to the off-site ESX for just the most current replicas?

That's right.

[jlehtinen]

Hmm, this is the wording in the manual that threw me off:
"When performing instant recovery, Veeam Backup & Replication creates an independent temporary copy of a VM in your VMware environment and immediately starts it (if necessary)."

I took that to mean it was duplicating the files, but what it's actually doing is 'announcing' to the ESX host that there's another VM available, and then using the existing backup as its source? Makes sense...


Thanks for the input, I'm (obviously) pretty new to this and I'm puzzling my way through the best way to get this set up.

[jlehtinen]

Aha - found it. This was the other piece I was trying to find in regards to my "not enough resources" statement.... I run the Veeam and Vcenter servers in our environment really thin (since not much space to go around).

Under the hardware requirements for the Veeam Backup Server it states - "Sufficient free space for Instant VM Recovery cache (non-persistent data, at least 10GB recommended)."

Is this necessary? I'm not really fond of the idea that the instant-on VM's are using the Veeam backup server for caching.

[Gostev]

Because backup file must remain read-only, our vPower engine needs a place to store virtual disk changes which are occuring while VM is running. There is also an option in Instant VM Recovery to specify datastore to store these changes on (instead of keeping them on Veeam Backup server).

You need enough storage to store the changes while VM is running from backup. In many cases, 1GB will be enough if VM does not do much disk writes. 10GB is safer in case you plan to run VM in such way for very long, or if you plan to run multiple VMs at once.

Have you had a chance to review sticky FAQ topic (at least its section dedicated to Instant VM Recovery)?

[jlehtinen]

Hiya,

Yep, read that and the manual. Sorry if they're newbie questions. I'm one of those people who like to get everything figured out in advance, then I only have to do the actual work once, since it's (hopefully) done right the first time.

Last one from me on this topic: If I do like you recommend, and have replication jobs set up to capture failover replicas, I still only can keep the most current replicas due to space constraints. I'm sure I can get some snapshots in there too, but eventually I'll run out of space and will have to wipe the replica+incrementals and take a full fresh one. You're saying that if I delete the files and re-run the job, it will error. Does that mean I have to re-create the replication jobs after every time I need to re-capture a full new replica?

[Gostev]

You will not run out of space, as older replica restore points will be deleted automatically. Your replica files will always take up the same disk space. Just try it - setup replication and set retention policy to 3 for example.