Networker

Re: [Networker] Some issues. GUI only backs to "default" and some

2009-05-18 05:50:57
Subject: Re: [Networker] Some issues. GUI only backs to "default" and some
From: Preston de Guise <enterprise.backup AT GMAIL DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Mon, 18 May 2009 19:40:08 +1000
Hi Neo,

On 18/05/2009, at 18:44 , NEO wrote:

Mmm.. .I have tried it in the GUI and that works fine. But to better explain what I want to do. I work with TV-productions and in our file based workflows when we move an TV-episode from one suite to another suite we use something called EDL's. It's a text file with the names of the clips used in the edit. There are no paths or so in that file. So my hope was to parse that file so what's left is the filenames only. Then use something like "recover -a -I od.ep01.txt" to search the database and retrieve the files I need. But seems like "recover" needs the whole paths to what I want to recover?

And can't find any "search" command in the Unix Command Reference either. If there had been one I could maybe have fed that with the text file with my files and then store the results of the search in another file and use that as a source of the recover. Does it sound confusing? =)

No, you do need to tell NetWorker the full path to the file you wish to recover in that sort of scenario.

Finding the full path is possible via using a combination of nsrinfo and mminfo - mminfo to determine the saveset and nsavetime, and nsrinfo for listing the files and their paths. (While not wishing to use this list for promotion of sales, if you dislike scripting the company I work for does have a suite of utilities that includes a "search" utility for NetWorker indices - find-files. Rather than posting more on that topic, search my blog (link in sig) for "IDATA Tools" if you're interested. That being said, finding full path detail from nsrinfo is quite easy.)

Referring to your comment that you were finding the backups were non- browsable, you had also previously said that you had "deleted tapes from indexes" ... this would be the cause; media has to be kept in place the media database in order to be browsable.

What I'm sort of reading from your various posts is that you're sort of wanting to use NetWorker to achieve some sort of HSM or archive solution - it's not really designed for that. However, these days indices are much more robust than in earlier versions of NetWorker, so while storing indices for lots of backups will eventually use up a lot of space, it's not a major hassle given the price of disk these days.

If you're really wanting to go down the archive or HSM path, at minimum I'd suggest purchasing the archive module so that you can use a "forever" retention time - however. However, that isn't HSM (hierarchical storage management); if this is data that you're going to be periodically recovering, you may find that HSM is a better solution to archive - that's where data is periodically (or manually) pruned in such a way that it's written out to tape or other non- primary storage, but a stub is left behind so that if the file is to be read from, the file is automatically recovered for access.

Cheers,

Preston.

--
Preston de Guise


"Enterprise Systems Backup and Recovery: A Corporate Insurance Policy":

http://www.amazon.com/Enterprise-Systems-Backup-Recovery-Corporate/dp/1420076396

http://www.enterprisesystemsbackup.com

NetWorker blog: http://nsrd.wordpress.com


To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER