|
Re: [Networker] Question regarding NetWorker's recovery strategy
2013-07-25 13:09:12
Thanks for all the responses. :-)
Yes, I was thinking that doing something like this would probably
involve having to maintain a static hostname for whatever server (maybe
a virtual server) would be running the backups and possibly using NFS to
keep things as abstracted as possible. I can certainly understand the
need for security. It just seems like it would be a nice feature if the
product could support backing up, say an archive, in the most abstract
manner possible wherein hostnames, ids, etc. are moot, and recovering
the data is not a security issue but perpetuity is. In other words, you
might want anyone to be able to recover this data in the future, just
like a tar archive but to minimize the work involved in doing that, e.g.
not having to know what host, id, etc. was used to back it up. How that
would be integrated into the product without compromising the current
security model where folks do want (most of the time) the restrictions,
I don't know. Maybe it could be an add-on, module, or possibly a
separate product all together.
As was pointed out, using uasm could work, but I guess it would need to
be used in conjunction with something like dd to actually get it to/from
tape? But this presents a problem if this was a daily process and not a
one-shot deal or an ad-hoc manual process. I think you'd have to
dedicate a drive for this. Otherwise, you might end up overwriting a
normal NW tape. Seems choreographing this with other operations that
might be going on in the library could get tricky, not to mention
keeping track of where on the tape you last left off in order to avoid
overwriting, and, of course, spanning tapes, and cloning. But I guess NW
could recover the data, even if dd was used to write it to tape, as long
as uasm was used to package it first? That right? Would save set recover
still work the same?
On 2013-07-23 16:34, Clark, Patricia A. wrote:
On 7/23/13 4:05 PM, "Tim Mooney" <Tim.Mooney AT NDSU DOT EDU> wrote:
In regard to: [Networker] Question regarding NetWorker's recovery
strategy,...:
I'm not sure how to phrase this question, but my experience with NW has
always been host based. In other words, if you want to recover a file
from some host from long ago, and that host no longer exists, then you
have to clown around a little bit to recover it to another current host.
In other words, having the physical tape, a drive that can read it, the
NetWorker software and knowing the ssid for the save set is not enough.
It seems there was always some mischief with having to create an NSR
client resource having that same client name and clientid in order to
recover it, maybe even to another host? Is that right? I'm not talking
about a browsable recovery. For that, I believe what I mentioned is the
case. Instead, I'm only talking about a save set recovery, so I may have
my information wrong there?
Pretty much all true, yes.
Here's my question: I want to be able to back up specific directories
on a
given client, and I don't care about the client.
This doesn't fit NetWorker's security model at all, so you're going to
have a difficult time here.
Think about it: in the vast majority of the cases, admins actually *do*
care about what host the data is on. /var/lib/mysql on hostA isn't
generally going to be the same as /var/lib/mysql on hostB, and unless the
NetWorker admin specifically configures it, hostB should not be able to
recover hostA's data.
In other words, even though NW will
record the client name in the media database, is there a way to recover
the
save set (save set recover, not browsable recover) without having to
know
anything about the client that backed it up (particularly in cases
where the
client is long gone) or having to play any games with making NW think
there's
such a client or named resource or having to know the clientid?
I've never tried to do this (again, you're really off the beaten path
here) but it's possible that you could skip the client creation process
entirely and just use uasm, possibly in combination with dd or some other
command.
Tim
--
Tim Mooney Tim.Mooney AT ndsu DOT
edu
Enterprise Computing & Infrastructure 701-231-1076
(Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
I find this to be typical for storage devices where you don't want to do
an NDMP type backup and don't really want a client per se as the owner.
While not ideal, my networker server used NFS mounts and acted as the
client for the backups. My server was not too busy to successfully manage
it all and it kept the management of the data under my control including
upgrades and migrations. If not your actual backup server, perhaps a
dedicated client that can be a surrogate? Possibly a virtual machine.
Patti Clark
Linux System Administrator
Research and Development Systems Support Oak Ridge National Laboratory
--
George Sinclair
Voice: (301) 713-3284 x210
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -
|
|
|
