I just tested this. Yikes!!! It appears that the files do not get
backed up. The save command returns "0 files" after the save. Looking in
saveset recover window, the file pathname has no instances. It's blank.
If I remove the entry from the .nsr file, or if I run the save with the
'-i' option, it works. HOWEVER, I can run the save against DATA with no
problems. This works without having to use -i or removing it from the
.nsr file. Any ideas why?
George Sinclair wrote:
>
> Hi,
>
> If I have a .nsr file under something like /3/exports/data that looks
> like this:
>
> skip: data1.dmp
> skip: data2.dmp
> skip: DATA
>
> and I have no other .nsr files further down, and I then manually launch
> a save on one of the data files, say /3/exports/data/data1.dmp as:
>
> save -s server -b pool_name -l full /3/exports/data/data1.dmp
>
> or I launch a save on the DATA directory as:
>
> save -s server -b pool_name -l full /3/exports/data/DATA
>
> then shouldn't everyhing get backed up even though there's a .nsr file
> there? It's my understanding that when you explicitly specify the path
> of a file or a directory at the level or below where the .nsr file
> resides, as I've done, then the .nsr file would not get used. But it
> will get used if I ran something like:
>
> save -s server -b pool_name -l full /3/exports/data
>
> or anything above that, and it will also get used any time a save on
> /3/exports/data or above gets executed from the server. Am I right? The
> reason I'm concerned is that I've seen cases where we'd backed up a
> symbolic link to a file system, rather the real pathname, not realizing
> that it was a link. So we mioght have had something like /home ->
> /raid/home, and we ran something like: save -s server -b pool -l full
> /home/fname.
>
> In this case, NetWorker grinds away at it just like it was the real
> data, and you don't know about it until you go to recover it. At recover
> time, it will take just as long to read through it (why, I don't know),
> but nothing will ever be recovered which makes sense since it was just a
> link. I'm concerned that this might be happening here, too, wherein we
> think the data is getting backed up but maybe it's not? We frequently
> create these .nsr files to prevent the data from getting captured by the
> nightly backups, but we've been assuming that we were capturing it when
> we ran a one-time full against the full pathname of the affected
> file(s).
>
> Thanks.
>
> George
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listmail.temple DOT edu or visit the list's Web site at
> http://listmail.temple.edu/archives/networker.html where you can
> also view and post messages to the list.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
