Object Storage just keeps getting better and better.
One real standout issue for me is how many businesses do not specify RPO/RTO (Recovery Point/Time Objectives) for their critical services. Backup infrastructure performance often gets overlooked in the never ending chase of getting the lowest $/gb as possible.
Technologies such as Tape, and deduplication appliances like HPE StoreOnce and DellEMC DataDomain often 'win' here because of massive amount of savings on storage space. They appear very cost effective.
But anyone who has ever tried to restore anything from these devices will tell you how long it takes. If you have a multiple Terabyte sized server then you can easily be looking at several days while you data is slowly rehydrated to primary storage.
Can you afford to have critical servers like that down for that long?
Step one is to define your RTO. If you can live with systems being unavailable for several days then cheap and deep may be the way to go.
If not them you need to look at your options. One option is backups to S3, but even here all Object Repositories are not created equal. AWS S3 or Azure Blob, may allow you to recover to AWS/Azure, but what happens when you have latency/performance or sovereignty requirements that simply can't be met by the hyperscalers.
Are you prepared for the time when you need to enact your DR plan?
In this case I'm assuming worst case. I have lost everything on-prem. All my infrastructure, all my performance backups. Assume that fire has taken it all, or a Ransomware attack has locked/deleted everything.
Fortunately I'm using Veeam B&R with Scale-Out repository to backup all my data offsite. Configured with Object Lock (Immutable) and Encrypted.
All I have are my S3 credentials and the Encryption Key.
Call the batphone at 3pm... Help.
Load the S3 repo into Veeam
I select the SOBR folder in the customer bucket, selecting the fact that this contains Object-Locked (immutable) data.
We're not planning on writing anything back here. Just recovering at this point
Now I import backups, prompted for Encryption Key that was used for the Capacity Tier of the original on-site SOBR.
It's now 3:13pm (and I'm writing this blog at the same time), the backups are importing.
I now have my Backups imported and restore point available
I need ad2019 back asap, so Right Click Instant restore
The restore steps just look like a normal Veeam Restore, we redirect writes and for this test do not power on. This step completed in < 2 minutes.
Did you know that Instant Restore will do VtoV conversion on the fly, regardless of whether your source was Hyper-V or VMware?
With Instant Restore we can now power on the server. The source data is still in S3 Object. It won't be as fast as production storage, but lets see if it is usable.
Powered on at 3:25pm, OK, Not the fastest to boot but I have login prompt in 5 minutes. At this point I can hand to the customer to start recover. My Domain login works.
So there we go. 30 minutes from full on site failure to powering up the VM in IaaS with no prior replication or setup. Yes, getting external access of other application failover will take some time, and a bit of forward planning will go a long way.
But we are not done.....
One last step in Veeam. The server is running, but we need to get our Instant Restore and finalize the move. We have decide that the on-prem site isn't coming back
This does a vMotion from the Veeam backup reposiroty to the primary IaaS storage. The server remains online the whole time. How long this takes is dependant on the size of your sever. Once complete we are completely running on your favorite NZ based IaaS provider.
Veeam B&R once again proving why it is the swiss army knife of backup and recovery tools.
#Veeam #Cloudian #HPE #Dell #Pure #vBridge