Feature Request: Restore entire tape set

[rayruest]

We have a requirement to test our tape restores on a regular basis. I would like to be able to load a set of tapes from a given restore point, and restore the entire tape contents to the repository. Support has informed me that I should be able to do this using powershell, but it would be great if it were an option in the UI.

[david.domask]

Hi Ray,

I'm not quite sure I get your workflow in full, but if I understand it correctly you want to:

1. Confirm which tapes are needed for a restore point and load them to the library
2. Test the tapes for restorability by dumping the contents to a repository

Am I correct?

The Entire Tape restore feature I think is exactly what you're looking for. Simply load the necessary tapes, then you can initiate the entire tape restore.

Similarly, why not consider Tape Verification? Functionally should be the same, just it will not dump the tape data to repository and instead just validate that the backups on tape are in a good state. I can understand though that you may prefer to see actual data on disk for your test, but consider Tape Verification.

Will this work for your purposes? Can I ask why the focus on validating specific tapes that host a given restore point and its dependent backups instead of just checking per tape?

[rayruest]

Hi David,

1. It looks like that restore files option is for file-to-tape jobs (unless I'm interpretting it wrong). It also states that encrypted files are not restored. All of my VM backups are encrypted.

2. I absolutely will use tape verification, thank you! That may satisfy some of the requirements. The only data I won't get an accurate read on is how long an entire tape restore would take. Verification won't tell me how long it would take to transfer all of the data to the datastore if something catastrophic requires a full environment reload from tape. Verification time would be a best-case scenario, minus the latencies of getting the data to the repository. I could estimate that by restoring several VMs, and interpolating that restore time and data size to the full data volume on the tapes. That should get me pretty close to a worst-case restore time.

My goal is to:
a) Test the integrity and restorability of the tapes. #2.. done.
b) Be able to provide the business with an estimate of a worst-case disaster recovery time of the entire environment for the DR and business continuity planning. I would likely perform this testing only once or twice a year as the environment changes to ensure no large swings in time-frame. As mentioned above, I think I could just use my total tape set size and my average restore speed from tape to get the information I need.

Thoughts? I think this would get me what I need easily, but am always up for new ideas.

Thanks!

[david.domask]

Hi Ray,

You're very welcome for the suggestions! To address your points:

1. Partially correct -- Entire Tape Restore just copies the contents on tape to the target destination, so it will work fine for tapes written to by Backup to Tape jobs (including those in Tape GFS Media Pools)

Encryption is something I was afraid of, and regrettably it's a limitation at this time.

2. Glad that this will work for you partially. I do agree that it will be difficult to get a "specific" time as there are a few factors that may impact restore from tape processing time. Biggest one I can think of is Restore to Infrastructure which allows for direct restores from tape to a production host, and has a few considerations as noted in the User Guide. You will see similar patterns depending on how the backups are split across tapes, but I think it's best as you write to just do a manual test periodically and set it as a base line.

I think that this combination works best and puts the least stress on the tape hardware/tapes, so I would start with this. Consider for your restore testing creating a simple restore plan that has set servers and a given period you must restore from. For example, consider a simple Windows based environment that has Domain Controller, several SQL nodes from an Always on Cluster, Exchange, and a file server. Then test from most recent restore points and archival restore points (GFS) and just check your process and the restore time. I think that should help you set reasonable baselines to judge if the restore is taking longer than usual. Test a few points also because as noted in the above User Guide link, certain factors can impact the restore time.