[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference decwet::networker

Title:NetWorker
Notice:kits - 12-14, problem reporting - 41.*, basics 1-100
Moderator:DECWET::RANDALL.com::lenox
Created:Thu Oct 10 1996
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:750
Total number of notes:3361

565.0. "NSR A backup NSR B" by CUSTOM::STAFFORD () Wed Apr 09 1997 14:00

    
    	Can NSR server A backup NSR server B?
    	In other words can NSR server B be a client to NSR server A?
        Someone told me it cannot. I tried it and it seems to not work.
    	I have a 4 GB /nsr filesystem that would not be backed up. I
    	copied it to /nsr_bck and tried it. It still did not work.
    
    	Ther main thing we want to do is save our resource files on the
    	other server, that way if a fire or something like that happened
    	we would not loose all the confi info. I know it is stored  on the 
    	local server tapes and can be recovered, but if the tapes go 
    	bad via fire or whatever I am in trouble.
    
    	Any ideas?
    	
    	
T.RTitleUserPersonal
Name
DateLines
565.1DECWET::LENOXPass the popcorn, on with the show.Wed Apr 09 1997 14:4010
Please include full details on what isn't working, don't waste
our time and make us guess.

Any NSR server can act as a client.
Do you have the documentation?  Is the system licensed properly?
If you try to back up files that are locked and open then NSR
won't do it (see other notes in this and the old conference).
You'll probably have to shutdown NSR on system A
before backing it up to system B, and vice versa.
565.2DECWET::RWALKERRoger Walker - Media ChangersWed Apr 09 1997 14:404
	Yes a NetWorker server can also be a client.  Make sure the
	access is setup.  This may require modifing the /res/servers
	file on A to allow access by B.  Look at a client or the man
	page for nsrexecd for examples.
565.3DECWET::SDYLook out!!..Support Rookie sez...Wed Apr 09 1997 14:5223
 re: .0

   	Ther main thing we want to do is save our resource files on the
    	other server, that way if a fire or something like that happened
    	we would not loose all the confi info. I know it is stored  on the 
    	local server tapes and can be recovered, but if the tapes go 
    	bad via fire or whatever I am in trouble.
    
    	Any ideas?


This is a normal disaster scenerio, not restricted to NSR configuration files,
things that help in this scenerio are saveset cloning and utilizing off-site
storage. There are multitudes of ways to save extra copies of your res files,
some of which are dependant upon what type of system you are running (NT vs UNIX
for instance). Manual copies or clone tapes stored in a different site/room, ftp
archives as storage, if you have centralized email, you could even email them to
yourself (res files are plain ascii) and store it there.

As Amy mentioned, being a client of another server works just fine if you have
it configured properly.

steve.
565.4ps, for index infoDECWET::LENOXPass the popcorn, on with the show.Wed Apr 09 1997 15:295
An engineer here has pointed out that there are
.nsr directive files in the index area so unless
you specifically call those files out, they won't
get backed up.
565.5Resolution to problemCUSTOM::STAFFORDTue Apr 22 1997 12:1735
    
    
    
    	I would never think of wasting your valuable time (see .1). I would
    	not fo a moment have you waste time assisting people less 
    	knowledgeable of NSR, people in the field, people that the customer
    	has paid to have on site and make all HIS PROBLEMS go away.
    
    	Now what isn't working is the backing up of files in the /nsr
    	file system. It will backup the directories (example
    /nsr/index/<client name>), but will not back up the .nsr readme and
    db files. 
    
    	After reviewing the man pages and specifically man page for save,
    	I determined that the problem was from the .nsr files in each
    directory. Since the .nsr is ascii (thanks note .2) I typed it out to
    	see that it say to skip .nsr README and db.
    
    	To correctly backup the NSR filesystems we do the following.
    
    	At 11:30 am NSR is stopped on server A. The /nsr filesystem  is
    then vdumped to /nsr_bck and NSR is restarted. This is accomplished as 
    a cron task.
    
    	At 20:00 Server B starts a group that has server A as the only
    client. In the client definition of A there is a definition for the 
    backup command called save_nsr_bck.sh that assists in the backing up of
    server A /nsr_bck file system.
    
    Thank you for your assistance.
    
    
    
    	
    
565.6ok, ok... be cool...DECWET::EVANSNSR EngineeringThu Apr 24 1997 18:35114
re: wasting time... let's move onwards..

re: backing up /nsr

  umm, why do you need to backup .readme file?? it's mostly put there
  by Legato to keep the average person from doing something in that
  directory that would come back to ruin their backups (like delete
  the db file!)

  the db file needs to be backed up by a special ASM (nsrindexasm), not
  the regular uasm.

 did that fail?? I mean, did the nsrindexasm fail?


Oh... wait a minute - I re-read .0 and of course, you are trying to backup
 server A using Server B. OK. Lessee. .3 had a good idea, in that
 you do your backup on Server A, clone those tapes, and take those off
 site.
   .4 said to cull out the .nsr files, which is another way to have
 Server B back up the files. Another way is to issue (via cron)
 a 

	server-B-prompt> save -i -s <server-A> /nsr

 here's what happened when I did it to my server:
-----------------------------
root@mrcofe> save -i -smrcofe /nsr
/nsr/res/nsr.res
/nsr/res/nsrjb.res
/nsr/res/nsrla.res
/nsr/res/servers
/nsr/res/
/nsr/logs/daemon.log
/nsr/logs/messages
/nsr/logs/summary
/nsr/logs/
/nsr/index/mrcofe.zso.dec.com/db
/nsr/index/mrcofe.zso.dec.com/.nsr
/nsr/index/mrcofe.zso.dec.com/README
/nsr/index/mrcofe.zso.dec.com/
/nsr/index/sumatra.zso.dec.com/db
/nsr/index/sumatra.zso.dec.com/.nsr
/nsr/index/sumatra.zso.dec.com/README
/nsr/index/sumatra.zso.dec.com/
/nsr/index/decaf.zso.dec.com/db
/nsr/index/decaf.zso.dec.com/.nsr
/nsr/index/decaf.zso.dec.com/README
/nsr/index/decaf.zso.dec.com/
/nsr/index/apocal.zso.dec.com/db
/nsr/index/apocal.zso.dec.com/.nsr
/nsr/index/apocal.zso.dec.com/README
/nsr/index/apocal.zso.dec.com/
/nsr/index/sumatra/
/nsr/index/sucasa.zso.dec.com/
/nsr/index/roadrunner.zso.dec.com/
/nsr/index/coyote.zso.dec.com/
/nsr/index/jittrs.zso.dec.com/
/nsr/index/orcas.zso.dec.com/
/nsr/index/pluto.zso.dec.com/
/nsr/index/donald.zso.dec.com/
/nsr/index/brackish.zso.dec.com/
/nsr/index/sinclair.zso.dec.com/
/nsr/index/orion.zso.dec.com/
/nsr/index/dsomax.zso.dec.com/
/nsr/index/nowory.zso.dec.com/
/nsr/index/nsrwst.zso.dec.com/
/nsr/index/farwst.zso.dec.com/
/nsr/index/
/nsr/mm/.nsr
/nsr/mm/mmvolume
/nsr/mm/.cmprssd
/nsr/mm/
/nsr/tmp/res.lck
/nsr/tmp/nsrmmdbd.lck
/nsr/tmp/.nsrim
/nsr/tmp/bwe.lck
/nsr/tmp/.nsr
/nsr/tmp/secure/300105
/nsr/tmp/secure/400105
/nsr/tmp/secure/
/nsr/tmp/
/nsr/cores/nsrd/.nsr
/nsr/cores/nsrd/
/nsr/cores/nsrmmdbd/.nsr
/nsr/cores/nsrmmdbd/
/nsr/cores/nsrindexd/.nsr
/nsr/cores/nsrindexd/
/nsr/cores/nsrmmd/.nsr
/nsr/cores/nsrmmd/
/nsr/cores/ansrd/.nsr
/nsr/cores/ansrd/
/nsr/cores/nsrjb/.nsr
/nsr/cores/nsrjb/
/nsr/cores/nsrexecd/.nsr
/nsr/cores/nsrexecd/
/nsr/cores/savegrp/.nsr
/nsr/cores/savegrp/
/nsr/cores/asavegrp/.nsr
/nsr/cores/asavegrp/
/nsr/cores/nsrck/.nsr
/nsr/cores/nsrck/
/nsr/cores/nsrim/.nsr
/nsr/cores/nsrim/
/nsr/cores/
/nsr/applogs/
/nsr/nsr8
/nsr/ssc/
/nsr/
/

save: /nsr  45 MB 00:01:34     82 files
root@mrcofe>