To say this is not pretty would be an understatement.
We've run something similar, and thankfully we've purchased some new
hardware and are getting away from this model. My tips would be as
follows.
1 - Separate "Site" Storage Groups so you don't run backups across the
wan.
2- "c:\Program Files\VERITAS\Volmgr\bin\vmphyinv" -rn 0 -verbose
This command will physically mount each tape, and scan the header
information to update your volume configuration. It takes about 20
minutes, but its accurate.
At least this way your backups will run, but the local operator still
has to physically label each tape with a slot - tape comparison.
Perhaps you can automate a report and email it to them.
We had one site like this that was a nightmare. We eventually made that
site a master, and then later purchased a ATL w/ barcode reader.
-Jonathan
-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Lee Anne
Pedersen
Sent: Thursday, February 23, 2006 10:21 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] New to Windows media servers
(Windows 2003 Standard, NetBackup 5.1 MP4, HP ProLiant ML570 G3, HP
StorageWorks 1/8
LTO3 autoloader)
For the 4 years that I've worked with NetBackup, my experience has been
confined to a single master/media server with direct or fibre attached
barcode-reader-enabled robotic tape library.
This past week I was tossed a new server and an 8-slot, single-drive,
non-barcode-reader-enabled autoloader, and was told that I had a week to
get it up and running as a media server for deployment to a remote site
where there will be non-technical people handling the tape inject/eject.
Thus far I've gotten it installed as a media server as near as I can
tell (with incredible throughput compared to my existing servers), but
I'm on the steep learning curve of logically separating master from
media server inside my head.
I'm looking for any suggestions as to how best handle this new
configuration:
1. Should media be viewable on the master or media server? (all
currently on master)
2. How can I automate the exchange of media to make it the least painful
for the onsite operators?
On our existing servers, tape is all handled dynamically with expiry
going to the scratch pool. But our remote sites have only ever dealt
with defined Monday tapes, Tuesday tapes, etc.
3. Onsite operators will not have access to the server. Besides simply
scheduling vmphyinv to run, I'm stuck on how to ensure that media is
properly ejected and injected via NetBackup. There is no 'media access
port' to speak of on this autoloader.
4. What's the best configuration for policies, schedules and pools? I'm
considering defining pools for each day of the week with pre-assigned
media, but I'm concerned that the media will just be shuffled off to the
scratch pool instead of staying in its own pool.
5. Should I be barcoding the media even if it doesn't have a barcode
reader? I'm thinking of future usage, but I also don't like the idea of
having a media label of AAA123 but a physical label of Monday Week 1.
Initially I have made the description read Monday - 1, etc. while I try
to figure this out, so I can use that in any reporting. I will have
added all the tapes prior to the deployment.
I'm comfortable doing some very basic Perl scripting on Windows, so I
expect to generate daily reports for the operators to tell them of
backups run, errors, which tapes were used, etc.
I'd appreciate any quick wins that I can incorporate before the server
is shipped offsite next Monday.
Thanks,
Lee Anne
Lee Anne Pedersen MCP
LAN/Server Analyst
Restructuring & Government Efficiency
DCS Delivery Team E
Ph: 780-427-2504
LeeAnne.Pedersen AT gov.ab DOT ca
This communication is intended for the use of the recipient to which it
is addressed, and may contain confidential, personal and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communication received in error, or subsequent
reply, should be deleted or destroyed.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
