cancel
Showing results for 
Search instead for 
Did you mean: 

Staging space requirement for a restore from incremental copy with GRT enabled VM.

Ashfaq1
Level 2

Hi All,

I need to know how much space is required for a restore task if I am going to restore from an incremental backup of VM with GRT enabled. Full backup size is 1 TB. 4 incremental backup with each image size is 500GB. If I am to restore from the last incremental backup, how much space is required in the staging area? 1 TB or 3 TB or 5 TB? or more than that.

Thanks ahead.

Ashfaq

1 ACCEPTED SOLUTION

Accepted Solutions

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

As VMs are backed up, incrementally, as blocks and not files, it is likely that a file change operation inside a VM won't result in 100% of the blocks that make up the file being affected. Which then explains why you cannot restore a file from an incremental if the chain of incrementals back to and including the last full are also not available (as to restore the file you need all the blocks) .

This is comopletely different from file level based backups of the type that our remote agent process actions against NTFS volumes, as any change to a file results in the file itself being backed up by the incremental - as such you do have to get used to a different mindset when thinking about incrementals where block level (instead of file level) backups are performed.

 

Your staging area will therefore need enough space for the complete chain to be staged as backup images (and then we mount what we need from the chain.) which in your example could mean around 3TB if restoring from the last/4th incremental before your next full.

 

This is why it is recommended that your disk (or deduplication based backups) are used for the timescales where you believe regular individual file restores are needed (which may need more disk space and longer retention times) and the tape based backup (which is usually a duplicate of what is in disk) is intended mainly for a complete DR (with the possibility of emergency operations against single files in the knowledge that such restores will take a lot longer from tape and will use a staging area)

 

 

View solution in original post

1 REPLY 1

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

As VMs are backed up, incrementally, as blocks and not files, it is likely that a file change operation inside a VM won't result in 100% of the blocks that make up the file being affected. Which then explains why you cannot restore a file from an incremental if the chain of incrementals back to and including the last full are also not available (as to restore the file you need all the blocks) .

This is comopletely different from file level based backups of the type that our remote agent process actions against NTFS volumes, as any change to a file results in the file itself being backed up by the incremental - as such you do have to get used to a different mindset when thinking about incrementals where block level (instead of file level) backups are performed.

 

Your staging area will therefore need enough space for the complete chain to be staged as backup images (and then we mount what we need from the chain.) which in your example could mean around 3TB if restoring from the last/4th incremental before your next full.

 

This is why it is recommended that your disk (or deduplication based backups) are used for the timescales where you believe regular individual file restores are needed (which may need more disk space and longer retention times) and the tape based backup (which is usually a duplicate of what is in disk) is intended mainly for a complete DR (with the possibility of emergency operations against single files in the knowledge that such restores will take a lot longer from tape and will use a staging area)