Brian,
We have DRM implemented here on one of our ADSM servers. My main
problem was integrating the offsite tape rotation with the current
courier schedules.
We have 2 23GB disk primary storage pools and two tape primary storage
pools (one for each 3494 library) that are defined to DRM (set
drmprimstgpool). We also have four copy storage pools. Only two of
those pools are defined to DRM (set drmcopystgpool). The other two are
onsite availability stgpools.
We run full db backups each day (6GB). We have set series expiration to
6 days (set drmdbbackupexpiredays).
Each night we backup the primary storage pools to all of the copy
storage pools.
Once a week we move all mountable DRM volumes - these are ejected from
the library (this is run with a script that is kicked off by the
scheduler). This script also generates a list of all volumes needing
retrieval (q drm * wherestate=vaultretrieve), and volumes which should
have been returned by the courier (q drm * wherestate=courierretrieve).
The script also "moves" the vaultretrieve tapes.
The tapes are removed/inserted and the operaters run two additional
scripts. One to checkin the returned media. The other to move the
notmountable media to vault when the courier has left with the tapes.
The reclamation is 100 on the offsite storage pools and the delay period
is 6 days (cooresponding to the dbbackup expire). When ptf 12 is
available and applied on my server I am going to reclaim the offsite
volumes periodically. This will cause little utilized tapes to come
back onsite and new, fuller tapes to be sent offsite. Haven't done this
yet, but I think it will work.
If you think about this, each week I am sending tapes from the
copystorage pools offsite and they never return (the files don't expire
fast enough). Over time, I could have as many as 52 little used volumes
offsite. That is why I want to do the reclamation periodically.
I generate the recovery plan each day to a mirrored jfs directory which
is then ftp'ed to a remote site.
I am sure there are other ways. We have tested the individual
components of this strategy, but so far have not had to restore after
the server burned.
David Hendrix
dmhendri AT fedex DOT com
|
