New backup strategy, opinions?

[tomhkr]

I've been using Veeam for 3 years now, backing up my production vSphere SAN to a deduping Dell DR-appliance.
It has worked well but recently I thought I'd evolve this closer to the 3-2-1 rule.

Here's what I can utilize:
1. vSphere SAN, throughput 600-800MB/s to my Veeam Proxy. Enough free space to hold at least 1 copy of the VMs I want to make backups of.
2. Dell DR deduplication appliance, write about 400MB/s and read (rehydrating penalty) about 200MB/s.
3. NAS storage, 1 GB ethernet only which means throughput about 100MB/s at most. Can be placed off-site.

I'd appreciate your input on this setup:

1. Primary backup job that creates and keeps 1 restore point (latest daily) from SAN to SAN.
This has the advantage that both backup and restore from latest point is very fast.
We still have not experienced a hardware fault at the SAN level in 6 years (it is active-active replicated between two sites, anyway), all restores have been due to software/users errors at VM level.

2. Backup copy job that creates desired number of restore points at the DR deduping appliance
This has the advantage of being able to store many restore points and still being quite fast.
If the SAN breaks completely the latest points are also available here.

3. Backup copy job that creates periodical restore points to the NAS.
This would be an offsite NAS. For that extra layer of security.

[Mike Resseler]

Hey,

You are indeed in compliance with the 3-2-1 rule at that moment. Actually you will have 4 copies of your data (Production, Primary backup job and 2 BCJ), 3 different media and 1 offsite so that is always good in my book

From what I see, this seems like a solution that can work very well but what you really should do is ask yourself some questions: What is the SLA I agreed with my customers (whether it are customers or internal with the management remains the same ).

When we look at statistics, we see that 90% of restores come from backups taken the last 7 days. So when you agreed with management that you can recover very quickly (as in minutes) you might want to think of 1 full + 6 incrementals per VM on your primary (and then in the weekend another full... you know where I am going). However, if you agree that the restore from the dedupe appliance is good enough in terms of RTO then of course this is not that relevant.

And this type of questions you have to ask yourself (and the customer) what is expected. If the boss comes in and says: I need to recover file X that I deleted 30 days ago, is he agreeing on a delay because it comes from the NAS or not.

That would be my 2 cents

[tomhkr]

Thanks Mike.

We don't have any SLAs so I really have nothing to relate to but I always try to improve RTOs.

Basically we have two types of restores:
Entire VMs; most often due to system administrator or software error. 99% of restores are done from last restore point.
User data; lost or corrupt files. Can be anything from last restore point to two years ago.

I could improve restore times quite a bit for the VMs if I had the VMs backup up first to the SAN storage. Instant VM recovery would, I guess, be quite fast this way. I tried it from the deduping storage some years ago but the rehydration process is severely impacting latency, thus making it faster to restore the machine in traditional way and then starting it.

[tomhkr]

Speaking of Instant recovery, I just noticed there is an option to "Redirect virtual disk updates" which wasn't available then I last tested.
This should dramatically improve an Instant recovery since I can choose to make the updates to a fast low-latency SAN volume and not to the high-latency deduping appliance.
Got to test this..

[Mike Resseler]

Yes, but this makes Storage vMotion not possible for ESX(i) 4.x and earlier so if you are still in that boat, be aware (but please do test )

[tomhkr]

True, not a problem since we have only 6.0 hosts, soon updated to 6.5

Tested the Instant recovery and I am impressed.
When the VM backup resides on the fast SAN, it is up and running in 55 seconds. Counting from when I click "Finish" on the Instant Restore dialogue to when Windows displays the login prompt. Add 60 seconds for me to click through the choices (2 minutes total). It's about 7 times faster than our current restore time (for a full restore of a typical Windows server VM) which is around 15 minutes.