I am surprised to see many answers to this thread not commenting the
standard TSM functionality sufficient to achieve the goal:
- HSM client sends the data in a storage pool. That storage pool can be
backed up to a copypool. If this is a storage hierarchy within the server
(diskpool migration to tapepool), backup the diskpool first then backup
the tapepool to same copypool. Voila.
- management class for HSM client has parameter migrequiresbkup
(defaulting to yes). Thus if MIGDESTination of the class and DESTination
of the backup copygroup point to different pools - you again can have two
copies. Plus the copypool one can be even more.
- usage of HSM client does not prevent filesystem to be backed up using
B/A client. Restore of HSM-enabled filesystem is even a bit faster - TSM
is smart enough and can restore only the stubs thus improving system
recovery times. Again backup destination pool can be backed to a copypool
and handled as all other nodes (which Matt assumes are "working fairly
well").
How afterwards off-site tape management is to be done is just another
story solvable in many ways - through DRM, AutoVault, TSMManager, etc. (or
Post-It notes :-).
Zlatko Krastev
IT Consultant
Matt Simpson <msimpson AT UKY DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
20.02.2003 21:46
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Need ideas for offsite copy of HSM tapes
We are using TSM and the HSM client to replace a system which used
Unitree and Cam backup software. The system provides two major
functions. One is server/workstation backup. We have that part
working fairly well (ignoring the usual TSM headaches).
The second function, which has me scratching my head for answers (and
begging all of you for advice), is a nearline storage capacity.
Basically, we provide what looks like a huge disk farm (really disks
migrating to tape libraries) that users can FTP files to/from for
storage. The understanding with this system is that we provide no
"backup" of user files in the nearline storage, meaning that if a
user deletes a file, it's gone, and he can't get it back, or can't
restore an older version of an existing file. We do want offsite
copies for disaster recovery, so if the whole system burns up through
no fault of the users, we can restore their current data.
With the old Unitree system, all tape storage was in an STK 9310
silo with 9840 drives, managed by ACSLS. As data was migrated to
tape, 2 copies were made, and one copy sent offsite on a daily basis.
With TSM, we have added a 3584 LTO library, and want to use the LTO
tapes for offsite storage (denser tapes means fewer cartridges to
shuffle). We have it working fairly well for the regular TSM
server/workstation backups: backups go to a disk pool which migrates
to a 9840 storage pool; 9840 pool is regularly copied to an LTO
copypool, and we use the TSM DRM facilities to handle tape movement
between the LTO library and the vault.
The nearline storage facility gets a little more complicated.
Essentially, the users ftp to/from a machine running the TSM/HSM
client (which happens to be the same one running the TSM server).
The ftp users directory is a space-managed directory which migrates
to a 9840 tape pool for onsite storage. Our initial setup was to
back up the ftp users directory to an LTO pool to go offsite. But we
seem to keep running into gotchas. DRM doesn't handle primary
sequential storage pools, so it wouldn't move the backups of the ftp
users stuff. So I thought instead of backing it up, let's just
define an LTO copy pool, and copy the HSM primary tape pool to it.
That would probably let us get copies of the HSM tapes offsite, but
it appears that not everything in a space-managed directory gets
migrated to tape, so those tapes alone would not be sufficient to
recover from a disaster.
The simplest option seems to be continuing our strategy of backing up
the directory to an LTO pool, and then copying that to an LTO copy
pool for DRM. But that doubles our tape usage.
Does anybody see a reasonable solution to our problem? Have I done a
reasonable job of explaining what the problem is? To summarize: we
want to use the HSM client to provide nearline storage, and we want
tapes offsite that will allow us to accurately restore that data if
the onsite facilities are destroyed, and we would prefer to have not
more than 2 copies (one onsite, one offsite) of the data.
--
Matt Simpson -- OS/390 Support
219 McVey Hall -- (859) 257-2900 x300
University Of Kentucky, Lexington, KY 40506
<mailto:msimpson AT uky DOT edu>
mainframe -- An obsolete device still used by thousands of obsolete
companies serving billions of obsolete customers and making huge obsolete
profits for their obsolete shareholders. And this year's run twice as
fast
as last year's.
|
