Unsolved

This post is more than 5 years old

2 Intern

 • 

146 Posts

1849

March 28th, 2016 11:00

VM 'Incremental Forever' with scheduled clone

Hello all,

Ive had a slight moment of panic, as I believe I have made a mistake and lost data as a result. Here is what I have been doing for several months........

I back up all of our VM's (1400 or so) using the Incremental forever schedule. I back these up into a media pool called "VM_backups" lets say.

Then, once per month, I have a scheduled clone job, and I select the same pool "VM_backups" in the saveset filtering, so that on the 7th of each month, an automated tape clone of all data written within that last 1 day to pool "VM_backups" goes to tape, and then offsite for 7 years.

Here's my concern, based on what EMC states about a Forever Incremental. Forever Full Incremental - Every VBA backup is a full backup. There is no need to restore from the last full and subsequent incremental backups to reach the desired recovery point. After an initial full backup, only the incremental backups are sent to the VBA. The VBA will keep track of all the incremental backups and sends the proper data back to the server during restore. In essence, the process of restoring the incremental data becomes completely transparent and mimics the process of restoring a full backup. This feature is further enhanced through NetWorker’s use of Changed Block Tracking APIs offered by VADP.

It sounds to me that this description is referring to the process where you are always backup up a VM environment to the same place, so that a fully restorable backup can be processed and "built" each time a restore is needed. But, if I am sending "Incremental forever" data to a tape via cloning, I dont see how that data can be re-hydrating itself into a full saveset as it clones to tape. In other words, if I recall a tape and attempt a restore a full VM from it, will I only see a ton of partial pieces (the incremental backups) of the savesets.

Thanks,

Todd

4 Operator

 • 

14.4K Posts

March 29th, 2016 04:00

VBA requires DD disk backup.  If you move it (nsrclone -m) it will (or should) rehydrate backup and you should get much bigger ssid on tape, but at this point I'm not 100% sure if this is the case (I would assume so, but I do not use it).  Same I would expect to see from clone.  Since some people reported some issues with this, it might be wrong assumption,  Actually, if for VBA restore you require VBA backup and this one in return requires DD - it might be that tape part is not working by design.  I really don't know as I don't use it, but it would be nice to hear someone who has been there...

0 events found

No Events found!

Top