Hello,
Forgive the laundry list of questions, but here's a few things as a
newbie I don't quite understand. Each paragraph is a different
question/topic, so feel free to chime in on just a few or any that
you're comfortable answering. Thanks!
I'm using Operational Reporting with the automatic notification turned
on for failed or missed schedules. I have a node associated with a
schedule that no longer exists (not powered on,) just to test failures
and notifications. However, I never get notifications about failed or
missed schedules from it (not the email or mentioned in the daily
report.) In the client schedules part of the report, it's always in a
Pending status. At what point does pending turn into failed or missed?
How can I configure that so I get notifications about systems that
missed their scheduled backup?
I'm using an administrative schedule to backup my DB to a FILE class
twice a day, and then I do full backups of the DB to tape right before
my offsite rotation. I read somewhere that since I'm using DRM, I
shouldn't use 'del volhist' to remove old db backups. However, I don't
think the DRMDBBACKUPEXPIREDAYS configuration setting is applying to my
FILE backups. Is that normal? Should I be running both drm and 'del
volhist'?
I do my backups to a DISK pool that has a 85/40 migrate percentage and a
tape next storage pool. If everything (my disk and tape pool) is synced
up to my copypool before a backup runs, and the backup only goes to
disk, the 'backup stg' for the tape has nothing to do. I understand
that. If I backup the disk pool and manually migrate the data from disk
to tape, and then backup the tape pool, it has nothing to do. (Since
that data was already in the copypool.) I understand that. But, if
during a backup the tape pool starts an automatic migration, the next
time I do a 'backup stg' for the tape pool, it has data to copy to the
copypool. So, what's happening? Since the migration is going on, does
TSM automatically route data from the node directly to the tape? (My
maxsize parameter for the disk pool is No Limit, so I would guess no.)
Or is TSM migrating from the disk pool the newest data that wasn't
already copied to the copypool? In that case, why doesn't it migrate
older data that's already copied? What's the selection criteria for
what gets migrated? .... Or would best practice say to manually migrate
the disk pool daily to minimize the chance of this condition?
Best practice-wise, do you try to define different private groups and
tape labels for onsite, archive and offsite storage? Or do people
really just make one large 'pool' of tapes and not care if tape 0004 has
archive data on it and stays for years, 0005 goes offsite, 0006 has a
two week DB backup on it, and 0007 is a normal tape pool tape? Since
there's not one (standard) unified view for volumes (DB backups, offsite
backups, checked in scratch volumes, not checked in scratch volumes) I
worry a little about keeping track of and 'losing something' if they're
all in one group. How do sites handle that issue?
I have a LTO3 tape library and an external LTO3 drive. In our Networker
environment, we found it a pretty good practice to have a drive outside
of the jukebox for one-off operations (old restores, etc.) as well as
some sort of fault tolerance if the jukebox or that SCSI bus went south.
How do I setup that environment in TSM? It looks like I cannot use the
same device class across two libraries. Doesn't that hinder me if I
want to use the external drive in the same way as the jukebox drives,
sharing storage pools, etc.? My jukebox isn't very large and I
anticipate having to use overflow storage pools, which is where being
able to mix the manual library (external drive) and SCSI library would
be nice.
Consolidating copypool tapes for offsite use. I had my reclaimation
threshold for my copypool at 40%. I used 'backup stg' with maxpr=[# of
drives] to minimize the amount of time the backup took. However, it
left me with many under-utilized offsite drives, that as soon as I moved
offsite, were then reclaimed (which then sat until the reusedelay
expired.) That seems inefficient - that I move a larger than necessary
number of tapes each time I do an offsite rotation (right now, weekly)
and as soon as they're offsite, they're reclaimed. To fix this, I put
the reclaimation threshold back to 100%, and set it down just before my
offsite rotation. I've also taken a look at the to-be-offsited tapes
and do some 'move data's as required to try to minimize the amount of
offsite tapes. Is that standard practice? I feel like I'm fighting the
natural way TSM works, given that it makes so many other decisions just
fine without my direct intervention. (And that's a compliment - I can't
say that for Networker.) Is there something I'm missing to make offsite
tape usage more streamlined? So my offsite rotation procedure is
starting to look like:
- expire inventory
- backup all the local storage groups to copy groups
- reduce copypool reclaimation threshold to 40%
- wait for offsite reclaimation to finish
- raise the copypool reclaimation threshold to 100%
- do a series of 'move data' commands for volumes to try to minimize
number of to-be-offsited volumes (not sure how I'd script this)
- do a database backup
- move drm the copypool tapes and take them offsite
One of the selling points for me to switch from Networker to TSM is it
gave me MacOS backups "for free." I'm seeing more Intel based Macs, and
I've heard the 5.3.3 client doesn't support them. Does anyone know the
status of an Intel Mac working client?
I'm believe I understand the way a DR scenario should work with
copypools and a complete DB restore from an offsite tape. (We're not
production with TSM yet, and that's still on my list to test/learn.) I'm
not as confident about the scenario where the database is intact, but I
want to restore some data that still exists on copypool tapes but has
been expired from the active database? Do I have to create a full DR
scenario to get that data back, or is there a way to 'merge' a DB backup
containing data about a certain node or timeframe into a live, working
system? Networker had tools to do this, but I don't think I've found an
similar practice for TSM. (Or is the standard BOFH answer "We don't do
that." and adjust the copygroups so that the revisions they need are
kept on the server, or fall back to archives or backupsets?)
Phew! I think that's it -- for now. Thanks again,
Dave
|
