Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Differential restore issue NW743

Status
Not open for further replies.

femorgan

MIS
Mar 17, 2003
3
US
Hi. I am running NW743 and have a situation where I need to do a redirected Full restore of 1.5 TB of 26 million files to a new server and then a week later a diffential of changed files only. Seems simple but when you select a directory structure a differential takes you back to the last full going through all 26 million files which consumes as much time as the full did. I remember when I used to run veritas when you selected a differential that was what you got only. A diffential on this server is about 70k files so poking through thousands of directories is a bit tedious. Any ideas?
 
Actually, you do noty have much of a choice, but this also depends on the client type. If it is Windows, you can of course ask the Change Journal.
 
Another related question then on the same restore. It appears that prior to the restore launching the recover action is initializing and a part of this is evidently using a piece of ram per file as overhead prior to the recover launching. The issue is that you run out of ram and the recover just stalls or hangs with no error message. Does the entire recover request have to be totally in RAM prior to recover or is there a way to have it buffer up to a resonable amount of memory than recover/restore that portion then move on to the next segment? I had to break the recover commands into a input list document of subfolders before I could get to the recover to begin. Kind of makes any restore of any significant amount of files complicated. It also appears that 2 GB is the limit in RAM where a hang occurs even when you have 3 out of 4 GB of RAM available. Any input is appreciated.
 
I don't know the effect you describe. However, i guess i know what you want to mean.

If you want to recover and you select a directory to browse, two things happen:
1. The file names will be retrieved from the index and sent to your computer. This takes a moment, depending of the number of files in this directory.
2. Then NetWorker hashes the filenames internally before it releases the GUI and returns control to you. With the file numbers you initially stated, this may take minutes - if you really have a huge file number, it may even take hours. During this period, you will see the RAM usage increasing.

Once 'NW is back', you will be able to select the files for recovery and run this process without problems - it is the browse phase which will take so long. By the way, this is not a GUI problem - it will even happen when you use the command line.

Can you avoid this? - yes, but not from the browseable recovery. In this case you must use the save set recovery or the 'direct recovery' (recover -S ssid -a file(s)).
 
Thanks! I will give that a shot the next time I have this situation.
 
There might be a workarround :
mount a Share ( Nfs or Cifs depending on your os) of ther new Server to your old one.
The connect to your "old" server where you backupd the data an initiate a saveset recovery of your differential backup.
Relocate the restore to your mounted share an select "Overwrite" existing data.

Now you can avoid restoring your 20 or more miollion files.
Of course you have an I/O-penalty on your server.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top