Yes, I have looked at and tried these features (The variables you mention).
They do what they are supposed to. The biggest problem I have is a slow
jukebox, not the size of my hard drives. It takes 50%+ of the day to
transfer the days backups to tape. If (for any reason such as running out
of tape one day) the transfer does not happen, the next day's transfer is
100%+ of the day. Where does my clone fit into this schedule? It doesn't.
It fails. Since my company requires me to have a clone every day, I must
kill the staging process, and leave an aborted save set on the jukebox tape.
NW7 seems to deal with this better than NW6.0 did, but it would be MUCH
better if I didn't have to. Either a way to halt the staging process, so
the clone could run, without aborting, or allowing the clone to interupt the
staging, and then continueing would be the prefered method. ALSO..... if my
staging takes 1.5 days to catch up, that is 1.5 days with NO space recovery
happening. That means that my file device is filling up fast! Consider: 2
days of normal backups, then a 3rd day with no space recovery equals 3 days
worth of backups stored on the file device. It's getting mighty tight
spacewise by now.... Again, I am forced to kill the staging with the
consequent aborted save set on tape, and otherwise manually administer this
function.
THE ANSWER:
1. Consider this......... I used the nsrstage command extensively in
scripts with NW6.1.1 so I know how it works. I used a script to pass the
save sets to the NSRstage command one at a time. The script did a NSRSTAGE
-S (save set 1), then a NSRSTAGE -S (save set 2), then NSRSTAGE -S (save set
3). In between each of these nsrstage commands, the save set was deleted
from the hard drive. This freed up space so my next nights backup <<had
enough room>> to run without me haveing to kill the staging script, leave an
aborted save set on tape, manually free up space, etc, etc, etc.....
2. Next point in favor of this option. Every time NSRSTAGE finished one
save set, it released the tape drive and file device for about 30 seconds.
During this time, the (waiting) clone would take over the file device and
proceed to clone the backups. Then the NSRSTAGE process was the one that
was waiting for NSRCLONE to finish! Once the clone finished, NSRSTAGE
resumed opperations. Result? Cloneing was NOT blocked while stageing was
in operation. I could let staging run for as long as it took for all the
tapes in my jukebox to fill up. Then, I could refill it and let it continue
until everything was staged.
How much programming would this take to accomplish inside NW7.1? I did it
with 3 lines of shell scripting and a temporary file. I'm sure your
programmers could insert the equivalent code in a few hours of work, and the
functionality improvements would be well worth it to everyone.
Thanks for the ideas in your post, and I will continue working with these,
but my overriding problem with the slow jukebox reduces the functionality of
most of these to "slim to none".
-----Original Message-----
From: Patrick Terry [mailto:pterry AT LEGATO DOT COM]
Sent: Tuesday, 27 May, 2003 10:45 AM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] Initial Report on Functionality improvements in
NW7 using Adv _Fil e devices
The list has responded well to this topic, and I think most everything has
been touched on in later messages, but here is info I have put together.
Have you adjusted the variables in your staging policy? Specifically, you
could adjust the file system check interval, the max storage period, and the
low and high water marks away from the defaults in order to kick off the
staging more frequently. These are hidden attributes. This would more
effectively take advantage of a key feature within adv_file device that
allows you to stage and back up at the same time. This means that staging
can now begin immediately after your first save set completes.
Now, the default for the above mentioned variables are 3 hours for the
system check and 7 days for the max storage period.
Of particular interest in your case may be the Max Storage Period variable.
In the 6.x versions, this period was adjustable from 1-1000 days. In 7.0,
you can select hours instead of days.
Similarly, for the file system check and recover space interval, you can now
select down to minutes as opposed to only hours previously.
These adjustments were made specifically to enhance the disk to disk to tape
strategy.
Assuming you are using the default values, you are not taking full
advantage. If you were to reduce your file system check interval from the
default of 3 hours to say, 30 minutes, and your max storage period from 7
days to 7 hours (or even less), then your staging operation would be
triggered every 30 minutes. At this point, NetWorker will look at the Hi/Low
water marks on the filesystem and also the Max storage period and move the
save sets that meet that criteria. This should also help eliminate your
worry of running out of space over the weekend, though you may need to
adjust your recover space interval as well.
Your experience of everything being moved all at once leads me to believe
that you would benefit from adjusting these variables. The default of the
variables work well for one of the uses of staging, which is keeping files
available on disk for a couple of days (for easy restore) prior to moving
them off to tape. For your goal, you'll want to make some adjustments.
Now, reading your more recent post, I see that you really want to maximize
the time that your savesets can remain in staging for easy recovery, which
is of course one of the main goals.
Really, the biggest limitation you have in your environment is the
small(ish) disk. Your explanation of what will happen when it fills is
pretty good. Notification will be sent, old (retired) savesets will be
removed. Also, however, the opportunity is there to grow the disk/and disk.
In an "ideal" environment, adv_disk will use big disk/disk array/NAS
devices (see http://portal2.legato.com/products/networker/diskbackup.cfm )
for a link to a couple of whitepapers on these.
This is not to say it is not suited for what you are trying to do, but it
may require more configuration/effort when you have the limitations you have
brought up (small disk particularly). As other posts have noted, in some
environments, multiple, smaller disks may be more ideal, and this too is
supported.
I'll read your wish list for both posts again. On first read sounds like
these are good suggestions. If you are not engaged with a Legato rep and/or
don't know how to make *official* requests for enhancement and our
interested in doing so, drop me a mail and I'll get the right folks in touch
with you.
Cheers
Patrick Terry
LEGATO Systems, Inc
Senior Technical Marketing Engineer
LCNS, LEGATO Certified NetWorker® Specialist
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
