On Thu, Oct 09, 2008 at 12:44:57PM -0400, George Sinclair wrote:
> Hi,
>
> I have a question here on the use of the '-N' option with the save
> command. What is the real value of using this? Does anyone have any
> advice, admonishments or bad experiences they care to share?
I think you understand all the technical aspects. It's just a settable
field. I assume most will have no use for it, but it is available for
some of those odd cases at the price of having to drive over to
Hackville.
It's the only user-settable field that you can query in mminfo. So it
is possible to stick data in there and be able to find it relatively
quickly. I can't think of any other way to do that.
> It seems kind of cool in some respects. For example, if you had a
> directory named '/3/exports/data001', you could back it up numerous
> times using 'save -N data001', and at some point in the future, you
> could move 'data001' to another file system, or maybe even to another
> server, and still have the same save set name (data001) show up in
> mminfo for all the various instances. So for reporting purposes, I can
> see that this might make things easier, and, of course, it does allow
> you to query on that symbolic name. *BUT* it kind of bothers me that the
> real path name isn't also listed. There could be times when you might
> want to see the real path name to know where that directory or entity
> lived on the client at the time of the backup.
Potentially, you could keep the path there and add bits to it as well.
> NetWorker recorded both. As near as I can tell, however, the symbolic
> name is not used for anything other than the save command itself. When
> using nwrecover and command line browsable recover, I still see the real
> path. The man page for recover doesn't indicate any way to specify this
> symbolic name, so recovering by save set still requires the ssid with an
> optional full path name, and still reports recovering files within, say,
> '/' to target_dir and not recovering files within 'data001' to
> target_dir.
In my fuzzy memory I think I wrote some tools that messed with name for
storing data to query later. But that was in '98-99, and I can't
remember the details.
> Perhaps if you have very specific directory name(s) that would not be
> used anywhere else then this might make mminfo queries slick, but if
> you're using a specific pool for the backups, wherein only those save
> sets write to that pool, you could simply query based on that pool, and
> parse the save set names for the directory portion of the path. Wouldn't
> that achieve the same thing?
Only if there were some unique thing that you could see. Imagine using
it not to find a specific location (which wouldn't be too difficult
without it), but a backup at a specific time (or range of times).
Without it, all I have to go on for identifying which backup is needed
is timestamps (and given enough effort, filenames in the saveset). I
might have to keep a separate timeline to know which backups were which.
But with 'name' I might append a project release name to it. So for a
certain date range, I could see 'blue' backups, and for another date
range I see 'canton', or 'denver'. Then I don't have to go and find the
date range separately to know what the last 'canton' release backup
was, even though it's the same filesystem.
That's the only thing I ever thought of using for, anyway.
--
Darren
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
|
