commvault.com commvault.com
  • EN
Solved

aux copying incremental VM backups to tape

  • 5 October 2021
  • 7 replies
  • 293 views
downhill
Rank
Userlevel 2
Badge +7

Can someone confirm from Commvault that in the case where DASH fulls are ran along with incrementals and the tape copy is synchronous, does the aux copy job (from disk to tape) essentially make it possible to restore any VM to the point it was last backed up, regardless of whether a full or inc happened last? Meaning it does not have to stitch together all sorts of incs. but rather takes the guesswork out of it so similar to restoring from disk, whenever you tell it to restore “to” those incremental jobs seen in the tape copy are essentially “fulls”? This is what I see when browsing media and comparing full jobs to inc’s - same exact file sizes and content for each VM. I didn’t think the intelligence was in there but at the rate the tapes are being consumed, it does indeed seem like every inc is basically converted to a full before writing to tape.

Is that observation correct? If so, that is perfect.

thanks

icon

Best answer by Scott Moseman 5 October 2021, 18:33

View original

7 replies

Scott Moseman
Rank
Userlevel 6
Badge +18

I cannot speak for your job sizes, but for a full VM restore you will need the latest Full (or Synth Full) job and whatever Incr jobs are necessary to meet the PIT of the request.

If an Incr job is ever “converted” to a Full, it will report as a Full job. You may want to investigate why your Incr job sizes match your Full job sizes. Very high change rate VMs?
 


Thanks,
Scott
 

Commvault Enterprise Success
Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

@downhill , are you referring to the restore itself?  As in, will the restore be able to grab all of the files the point in time (of the Inc) needs and run the restore without needing to restore each inc on top of the full?

If that is the question, then yes.

https://www.linkedin.com/in/michael-struening
downhill
Rank
Userlevel 2
Badge +7

Ok, yes, the job sizes for the inc’s are small but the individual file sizes shown when browsing the backup copy directly for each VM aligns with a full. So I think the answer is, the UI shows what will be restored, the last full plus inc’s to PIT, and, coming from tape could take a lot of time to stitch together. This to me seems like not a very good solution in the end but I’m going to run a test restore to see how bad it really is.

thanks

Scott Moseman
Rank
Userlevel 6
Badge +18

Are you asking about a full VM restore to a certain PIT, or only specific files?

Thanks,
Scott
 

Commvault Enterprise Success
downhill
Rank
Userlevel 2
Badge +7

I’m talking about the case where the disk libraries and all other sources are toast, and restoring entire VMs to PIT, not the last full.

Scott Moseman
Rank
Userlevel 6
Badge +18

For restoring a full VM, it will start with the latest Full job. However, thanks to our indexing, it will only apply the Incr jobs which are necessary. Depending on what’s changing across the Incr jobs, it may or (more likely) may not need to apply all of the Incr jobs.

e.g., If a file changes every day, it will be in every Incr job, but we will only need to restore the file from the latest Incr job because we don’t need the previous versions.

Thanks,
Scott
 

Commvault Enterprise Success
downhill
Rank
Userlevel 2
Badge +7

@Scott Moseman Yep, got it, tested that theory out. I would say restoring VMs from tape seems to be a non-starter, especially when 100’s are blended into each job, and, even with mux’ing off, it has to seek endlessly to stitch things together. Anyone else have similar observations? I did this test even with media only containing full backups, didn’t seem to make much diff. If a “job” has lots of clients in it, isn’t there a way to “serialize” the aux copy to tape so those machines are laid down 1,2,3,4,etc instead of what appears to be a scatter shot all over the tape?

Reply


Terms & ConditionsCookie settings