>> On Thu, 10 Aug 2006 12:10:09 -0500, Dave Mussulman <mussulma AT UIUC DOT
>> EDU> said:
> 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?
Migration begins for a particular node or collocgroup, and then
completes for that node or collocgroup ("node-ish") before moving to
the next one.
If that node-ish has backed up more stuff since the last backup
stgpool completed, then the uncopied data will get migrated too.
Said from another direction, TSM doesn't worry about selecting only
backed-up data from a stgpool when it's migrating, it takes whatever
is there.
Defining a copystgpool for the destination of the migration is
advertised to help with this: It's claimed that data will be
simultaneously written to the target primary pool and the copy pool.
I have not been able to elicit this behavior myself, and am somewhat
grumpy therefore.
> 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?
Your recordkeeping problem is too complex to do by casual inspection,
even if you separate the classes as you suggest. Work out queries
against the database that satisfy your auditing notions, and trust
them. Oh, and run them. ;)
You will inevitably end up needing more "Primary" tapes when all
you've got on hand will be labeled for "Reverse thudpucker" use or
some such; Then you'll cross your own lines, and after the first time
it gets easier and easier....
Reminds me of the first time I checked all of the volumes in a
copystgpool out of my library. "Just this once", I thought. But once
you're there in the back seat.... Uh. Digression.
> 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?
Having an extra drive outside a library isn't exactly a _bad_ idea,
but unless you're trying to write a different format I'd expect you to
get more value out of adding it to the library.
The purposes for which we'd like external drives are mostly what are
called "backupsets", intended to be used independant of the TSM
Server, written in media formats accessible to drives directly
attached to the clients.
If you really, really want to do this, I'd suggest:
- Define all of the drives to be "in" the library. set the one which
is physically outside to usually be offline.
- When you want to use the external drive, set the interior drives
offline, the exterior online. Run the job, mount, dismount, etc.
- When you're done, re-set to normal operations.
Personally, I'd much prefer checkin and checkout of desired volumes to
this. And get a quote on how much the next bigger step of library is,
and count the amount of time you spend screwing around with inadequate
library space. That way you can demonstrate to the folks who are
hoarding the beans when they start losing money because they didn't
cough up a library at the outset.
TSM is tremendously economical with tape and drive resources compared
to other backup products. Feed it well; feed it hardware instead of
your time.
> 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.
In proper consultant fashion, I'll tell you the time with your watch.
You minimized the "time the backup took", and then found that this
minimization squoze out, maximizing another part of your workflow.
Now, if you were me, you'd try to develop a theory of copystg
utilization workflow, and solve it for a minimum. But I suggest you
just twirl the knob to the other end, and see if you like that
tradeoff better.
So 'backup stg' with only one process, accept that it'll take longer,
and see if that's quick enough.
If you can get a little bit of offsite reclamation accomplished in
most of your rotation cycles, then you're doing pretty well.
> 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?
You should consider data which has expired to be Gone, except for
heroic measures.
If you Really Need data which expired out of the database in the last
week or so (a common period for retention of DB backups) then yes, you
can do a complete DR scenario, and consult the as-yet unreused tape
volumes for the data. Icky squicky.
> (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?)
It's sufficicently easy to set your retained versions foolishly high;
I don't even consider the "We don't do that" to be a BOFH-style
answer.
It's usually an answer like 'You messed this up last month, overwrote
it every week and didn't notice until the first of this month, and
have waited until NOW to ask me to get it back? No, it's gone.".
- Allen S. Rout
|
