When I've had issues with restores what I've done is a procedure similar
to the following:
1) Use bpimmedia to determine backupids used for the backup:
bpimmedia -L -policy <POLICY OF THE BACKUP> -d MM/DD/CCYY hh:mm:ss -e
MM/DD/CCYY hh:mm:ss
Where -d = Start date/time of the backup and -e = End date/time of the
backup. (Doesn't have to be exact - just a range that would get the one
you want and not incorporate others.)
2) Use bpflist to get the files in the backup into a file:
bpflist -backupid <backupID> -d MM/DD/CCYY hh:mm:ss -e MM/DD/CCYY
hh:mm:ss
-rl 999 >filename
Where: backupID = one of the backupIDs produced by step 1 (this is
typically in form of clientname_############.) - Do this for each
backupID
-rl = directory levels (999 is max you can set this to - this makes sure
it gets /, /usr, /usr/lib, /usr/lib/firefox etc...)
filename = a name to be used later for bprestore.
3) Compare the restored files to the list files you created in step 2.
>From my experience the files are restored in the same order they are
listed. You should therefore be able to delete from top of the list
down to the first file that wasn't restore.
In practice I actually leave in both the last partially restored file
and the one above it - I then remove those from the restored files -
I've seen issues where even though the file above the partially restored
one appears to have been completely recovered it has caused issues if I
don't delete it too.
Your resulting list(s) should only be those files that are NOT on the
target.
4) Start a bprestore using the list created above. (Start a separate
one for each list if there is more than one.)
bprestore -R <changefile> -L <restorelog> -C <client source of the
backup> -D <client dest of the backup> -S <NBU master> -s MM/DD/CCYY
hh:mm -e MM/DD/CCYY -f <filename>
Where changefile is a file you use for renaming the files if restoring
to an alternate path - not necessary if you're restoring to original
location. You would first have to create change file to use it.
Restorelog overrides default log location - not required.
-D destination not required if your restoring to original client.
Filename = the list file you created above.
-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Len
Boyle
Sent: Wednesday, May 12, 2010 9:47 PM
To: A Darren Dunham; VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Trying to perform a restore with specific
events/scenarios
Good Evening,
You can generate a list of files to restore in a file and pass that file
as input to the netbackup restore command.
I believe this feature as listed below is basically the tsm -ifnewer
option .
I wonder if the netbackup folks would accept this new feature requrest.
len
-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of A Darren
Dunham
Sent: Wednesday, May 12, 2010 4:33 PM
To: VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Trying to perform a restore with specific
events/scenarios
On Wed, May 12, 2010 at 03:03:55PM -0400, gbkyle wrote:
>
> I have listed below our current scenarios and actions we would like to
take in the event of this scenario. I was wondering if this is possible
with NetBackup, or possibly even an existing tool or script.
>
> Scenario \ Action
> 1 0kB File on location to restore to \ Overwrite File
> 2 File on Location to Restore to Has newer modification date than
that is on Tape \ Do Not Overwrite
> 3 File on location to Restore to has older Modification date than
that is on the Tape \ Overwrite File
> 4 File Does Not Exist \ Write File
Possible, yes. Not sure how easy or efficient it would be.
All the information needed to make that decision can be found from
bplist/bpflist (both can show mtime from file at time of backup) and by
scanning the actual filesystem. You could have a script look at the
catalog and the filesystem and create a list of files that you want to
restore, and make the restore overwrite unconditionally.
That part seems reasonable, but parsing the stuff from the catalog would
take a bit of work. The thing I don't know is how well NBU would deal
at the end with a restore request and a file listing with *lots* of
files. Assuming that part is fine, this is doable.
Good luck!
--
Darren
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
----------------------------------
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
