Does Netbackup need the whole image to be available to restore a single file from Nth fragment

[manussnair]

Hi,

Im just confused about how the netbackup restore works. If I backup up a 3TB folder and the fragment size is 20GB, Netbackup creates an image ID and associate N number of fragments (20GB) with the same image ID. However, if I need to restore an 1 MB file from Nth fragment , would the Netbackup need scan all the fragments ,from 1 to last(3TB), to restore an 1 MB file? 

The situation here is , we backup and keeps the data in the cloud. But while restoring a single file, we dont find any other options than bring all the fragments back locally. It appears to be really crazy as the cloud restore cost is too high and unpredicable at time.

The response from the Symantec engineer :- "It sounds like you are wondering how to find the section of the backup image that contains the info/files you want to avoid restoring, or rather loading, the whole backup. This can not be done. The backup info is stored in the .f header file which tells NBU what files it needs to do the restore. It will have to, essentially, traverse the entire set of files to get what it needs and validate that the backup is "good". There is no way to figure out which file has the ones you want OR restore the info from just those files." 

Any thoughts ?

Manu

[RamNagalla]

the cloud work with netbackup is new to me.... so I am not going to talk about the loading the entire images locally at the time of restore..

when it come to restore....---> as per my Opining..

if you are trying to do the restore 1 MB file, netbackup identiifes the fragement info and location of the fragement that contains the required file from catalog and directly  read from that fragment and do the restore.. and it does not need to read all previous fragements.

[Nicolai]

I am with Ram

[mph999]

I have not done much with 'cloud stuff', to be honest in the UK at least we don't see many cases at all though I know some of my US colleagues have more experience in this area.

However, I just ran a backup to adv disk it took about 1 minute to write the data.

21/03/2015 09:34:00 - begin writing
21/03/2015 09:35:02 - Info bptm(pid=21793) waited for full buffer 318 times, delayed 3582 times    
21/03/2015 09:35:02 - Info bpbkar(pid=21792) bpbkar waited 0 times for empty buffer, delayed 0 times   
21/03/2015 09:35:04 - Info bptm(pid=21793) EXITING with status 0 <----------        
21/03/2015 09:35:05 - Info bpbrm(pid=21788) validating image for client womble        
21/03/2015 09:35:06 - Info bpbkar(pid=21792) done. status: 0: the requested operation was successfully completed    
21/03/2015 09:35:06 - end writing; write time: 0:01:06

I then looked in the .f file, and picked the last file in the backup ...  and restored it (remember, the backup took about 1 minute)

21/03/2015 09:49:07 - begin reading
21/03/2015 09:49:07 - Info bptm(pid=22604) waited for empty buffer 0 times, delayed 0 times    
21/03/2015 09:49:07 - end reading; read time: 0:00:00
21/03/2015 09:49:08 - Info tar(pid=22603) done. status 0          
21/03/2015 09:49:08 - Info tar(pid=22603) done. status: 0          
21/03/2015 09:49:08 - Info bptm(pid=22604) completed reading backup image    

The restore, of the last file in the backup took about 1 second.

I think this 'suggests' NBU doesn't read through the entire backup to restore a file.

I'm not aware that 'Cloud' backups work any differently, I'll have a chat with a colleague next week and check.

[sdo]

Martin, are you able to test something like... take a backup which somehow causes three or four fragments to be saved, then identify a file to be restored that lives in the last fragment, and then temporarily rename (out of the way) the second fragment file, then try the restore again (of a file known to reside in the last fragment)... and if the restore works then we know that NetBackup does not hop along opening each fragment (e.g. some fashion of full image 'construct' verification) - or if the restore fails (because the second fragment is missing), then we know that the restore process causes each fragment to be opened in some way which might go some way to determining why the cloud restore pulls down the entire backup image, because NetBackup is opening or perhaps doing an 'attribute or size find/request' on each fragment file which thus might cause a cloud based file system manager to have to retrieve every fragment - maybe.

[mph999]

Will do ...

[Marianne]

This is the same question as the one about multi tape backups : How do I know which tape to load when I only want to restore file X? The problem is that when NBU identifies media needed for restore, it will only look at header info and list media used for the entire image. Only when the restore is started will it look into .f files to find the actual fragment and request the relevant resource. So, IMHO, although media for entire image is listed, only the fragment where the file is actually located will be read during the restore.

[sdo]

It looks like the same question, but it's actually different.  What if there is something about NetBackup disk based storage units which is causing NetBackup to skip along fragment files?  Martin's test will reveal that.  Which might then explain why the OP found that a restore pulled down an entire image from the cloud.

[mph999]

I'll try and test later, I'm not on today/  tomorrow but will see what I can do.

I did try last night but my adv disk pool is down and won't come up, I've got a script running for a case and it's maxing my server out so I think this is reason, hopefully once the script finishes all well be good.

[mph999]

OK, my script finished and my diskpool is back up ...  yay ...

OK a restore from a backup that took about 30 mins ...

I picked a file near the end of the .f file, and reduced the frag size to 20M, so lots a frags and this file is in one of the later fragments as it was written right near the end of the .f file ...

23/03/2015 15:27:19 - Info tar(pid=16950) Restore started           
23/03/2015 15:27:19 - connected; connect time: 0:00:00
23/03/2015 15:27:19 - Info bpbrm(pid=16946) bptm pid: 16951          
23/03/2015 15:27:20 - Info bptm(pid=16951) start            
23/03/2015 15:27:20 - started process bptm (16951)
23/03/2015 15:27:20 - Info bptm(pid=16951) reading backup image          
23/03/2015 15:27:21 - Info bptm(pid=16951) using 256 data buffers         
23/03/2015 15:27:39 - begin reading
23/03/2015 15:27:39 - Info bptm(pid=16951) waited for empty buffer 0 times, delayed 0 times    
23/03/2015 15:27:39 - end reading; read time: 0:00:00
23/03/2015 15:27:39 - Info bptm(pid=16951) completed reading backup image         

Once again, it's pretty much instant.

When I'm back in the office I'll check with my colleague about cloud, maybe it works differently, though I'm not aware that it does.

[revarooo]

question is, why would it work differently with cloud? Do we change the way NetBackup interrogates files for restore in image fragments? Possibly, but unlikely.

[sdo]

Martin - did you remove/rename a fragment file e.g. second one?  I was hoping we could test whether NetBackup skips along fragments files?

[manussnair]

Well, I have explained the cloud scenario just to let you guys know the pain of restoring a file from a large backup. Otherwise, the Netbackup has nothing to do with the cloud, because the cloud gateway appliance sitting on-premise will bring the required fragments to its local disk(which is presented as the STU to netbackup) upon request. Hopefully Martin's test will unveil the mystery around it. The tests I performed showed that the Netbackup was trying to scan through to make sure all the fragments were present.

[sdo]

Exactly my thoughts too.  I'm wondering if a restore process performs some kind of fragment "presence check" - along the lines of when a tape is whizzing along and reporting "file markers"... and here I could be horribly confusing... but did you know that 'fragments on tape' are actually, in ANSI terms, known as a "tape files" and that they have "tape markers" spaced in between them, so my guess is that when a tape is spinning along it reports back the "tape mark position", and yes we know that the tape data within these fragments is not read, but I suspect this feature of tape "tape marker position" reporting (i.e. the act of passing over the "tape mark" which exists between any two "tape files" aka NetBackup fragments)... might also be happening in disk land... so, if something similar happens when running along a backup image residing upon a disk storage unit, i.e. NetBackup could be reporting "fragment presence" which could simply be a request to the file system of "does file 'n' exist" i.e. requesting "does fragment 'n' exist" - which might not necessarily open the file - but might be causing the "cloud engine" which sits behind a wispy disk storage unit to have to fetch the fragment file (in order to be able to report its presence).  Hope not.  But that's the purpose of a test such as this "does NetBackup notice a missing disk fragment test".  It will confirm whether NetBackup is testing for the presence of a fragment file.

[mph999]

Ahh, no, but I can do ...

[mph999]

OK, I renamed the first fragment file (the .img file), the restore still worked.

[mph999]

Good theory sdo ...

With tape backups, the FRAG line for each fragment had an offset value, showing the starting position, relative to the beginning of the tape.  so as expected, each fragment has a higher offset than the previous.

For disk backups, the offset for each fragment is 0 - there is no need of course as a fragment on disk is simply a data file, and by filename, we can go straight to it.

If we want to check each fragment is there, no need to read through them, just check the file exists, which will take virtually no time at all.

[mph999]

Could you let me know the case number ...

[sdo]

Thanks for testing it Martin.

[mph999]

Don't know ... Clearly manussair is having some issue do it would at least appear something is happening. I can't see why it would be different though, makes no sense, unless there is something I'm unaware of and therefore don't understand.