Yes. Staging.
You turn on the automatic stageing under customize > staging.
I have been working with the high/low water mark, and it has several quirks
to be aware of...

1. If you set high water mark to 50%, and low water mark to 49%, anytime the
amount of files on your file device goes over 50%, it "should" stage to tape
the same amount of files every day, thereby keeping the file device 50%
full.  However in practice if you have one or more LARGE file sets and they
are included in the file sets to stage, your stage group can vary by as much
as the size of this large file. That means my stage can be 50GB up to 125GB.
(My exchange backup is 75GB)  The variation from 50GB to 125GBs during daily
staging operations can throw your scheduling out the window if you have a
slow jukebox (like me).

2. The staging operation is checked every X minutes, or X hours... Whatever
you set it to.  HOWEVER, in reality this means what?  I am not sure at this
point if it is X hours past midnight or X hours past the time you configure
and start the automatic staging.  If it is past midnight and you set it to 5
hours, and it checks and starts staging at 5AM, 10AM, 3PM, 8PM, does the
next staging happen at 1AM, or does it start over at 5AM again?  My problem
is I don't want the staging to start untill the cloneing is done, or it will
block the cloneing from finishing.  If the staging happens at different
times each day it will be useless for me.  I haven't found a difinitive
answer to this in the manual yet.  Anybody?

2. Even when it doesn't have this problem it sometimes seems to calculate a
much higher number than it should.  Yesterday, it calculated it needed to
stage 200GB of data instead of the 50-125 I was expecting.  I had to kill
the staging process and run the recover space option to clean up enough
space to allow the nightly backup to work.  If it had only staged it's
expected 50-125GB of data, It would have worked OK for me.

3. I experimented on 6.1.1 with multiple file devices, but they simply
multiplied the complexity without resolving any of the issues with 6.1.1
file devices.  I gave up on them and went to a single file device. I have
not experimented with 7.0 multiple file devices, but I don't think it will
prove that useful.  If the files are backed up on disk A, and the stageing
happens from disk A and the cloneing trys to happen from disk A, the fact
that you have a disk B won't help.  In fact, when you set up Adv_File
device, it creates a RO copy of itself for you to use.  IE, you will see TWO
devices with the same name, only one of them will be marked RO.  This is the
device that staging and cloneing happen from.   The main device does the
backups at the same time.

4.  Adv_File has an interesting new feature that I am going to experiment
with. Sounds VERY promising!
If your Adv_File device gets full on backup, it will halt for 10 minutes and
try to free up space. If there are a bunch of expired save sets on the
device, it will remove them automatically and then continue the backup as if
nothing ever happened.
        What this means is if you backup 50GB a day (like me) and have 300GB
of space (like me) and set the retention time to 3 days, 150GB of data will
be guaranteed to be available for recovery and the other 150GB will be
there, but when NW needs more room, it will automatically delete the expired
save sets to make room for the new saves.  Neat huh?  If you do automatic
cloning of EVERYTHING, you will have a copy on tape, and a copy on the file
set at all times. Even better HUH?  I haven't figured out if I would also do
automatic stageing in this instance, but I expect to find out during
testing.


Has anyone else tried this yet?

Calvin E. Thomas
UNIX System Adminsitrator
NACA Logistics






-----Original Message-----
From: Robert Maiello [mailto:robert.maiello AT MEDEC DOT COM]
Sent: Thursday, 22 May, 2003 09:06 AM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU; calvin.thomas AT NACALOGISTICS DOT COM
Subject: Re: Initial Report on Functionality improvements in NW7 using
Adv_Fil e devices


Presuming we're all heading in this direction (ie..backup to disk, stage
to tape) ...  can you explain a little bit about staging for those of us
that aren't doing it yet?

Namely, are you automatically staging older data to tape or data of a
certain level (full backups etc)?

The interference with cloning sounds a bit troubling.  Are you doing your
cloning via scripts?  I guess I can see a confict if nsrclone asked for a
ssid but its been nsrstaged to tape when it thought it was on disk..

Robert Maiello
Thomson Medical Economics


On Wed, 21 May 2003 12:10:10 -0700, Thomas, Calvin
<calvin.thomas AT NACALOGISTICS DOT COM> wrote:

>My reasons for posting this are to stimulate some comments from other's
>about NW7.0 and it's new features.  If you aren't interested in NW7, stop
>here.
>
>I adopted NW7 for Tru64 last month, and after the initial glow has worn
off,
>here is what I find.
>
>First a few stats:
>I use Adv_File staging on the server.  My current staging drive is 300GB.
>My jukebox is 140GB and it only copys at 1MB/sec.  My daily backups are
>about 50GB.
>
>One problem I had with staging previously is fixed.  If the system is
>staging to my jukebox, my backups still run.  Successfully.  Big
Improvement
>here.
>
>Now to the down side.
>
>1. NW7 can now stage, and backup at the same time, but it can not stage and
>clone at the same time. When my backups finish, the automatic cloneing
waits
>for the staging to finish.  Since this may take up to a day on my jukebox,
>the clone doesn't start until the stageing is done.  When the clone isn't
>done in a timely manner, it SEVERLY limits the functionality of the backups
>+ staging improvement.
>
>2.  Automatic staging creates a list of files to stage, and then stages
them
>ALL at once.  After staging ALL the files to tape, it then deletes ALL the
>files at the same time.  Sounds logical right?  True, but not very
>functional.  I was using a script previously (on 6.1.1) that staged files
>ONE by ONE to tape, and then deleted the files ONE by ONE from the file
>device.  This was much superior to the ALL at once way.  What I find is if
>my jukebox is full (like over a long weekend,) and the file device gets
>full, when I put in new tapes after the weekend, the staging will stage ALL
>the files at once.  In my case that can be 200GB, and it takes 36 hours to
>stage all the files.  This causes the automatic cloneing to fail since the
>next backup started before the file device was freed up.  It also caused
>concern on my part because I only had 20GB of space left for the nightly
>50GB backup.  Even though 175GB had been staged to tape, I could not free
up
>the space for the next nightly backup.  I was forced to kill the staging
>process, and manually start the "recover space" process to get enough room
>to do the nightly backup.
>
>The Wish List:
>It should be a relatively simple programing change for legato to change the
>staging process from an ALL (save sets) at once process to a ONE (save set)
>at a time process.  I was able to accomplish this feat with a simple script
>on NW6.1.1.
>
>My first script ran just like NW7.0's does. It created a giant file of
>SSID/CLONEID's, and passed this to a single nsrstage command with the same
>problems I have with NW7.0 now.
>
>My second script was much better.  It simple used AWK to run the nsrstage
>command once with a single ssid/cloneid number as input.  Once the nsrstage
>command finished the single save set, it deleted the save set file from the
>file device, and then AWK would run the next nsrstage command. This allowed
>the gradual reduction in size of the files stored on the file devices, and
>it allowed backups, and clones to run (though it had to wait until after
the
>current nsrstage command finished).  It was kludgy, and temperamental, but
>it worked.
>
>
>What do you think?  Comments everyone?
>
>--
>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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=