Can we think again from idea/design/code reuse point of view. Most of us
know how the client is performing backup - first it creates list of files
to backup and then starts transferring them. So lets think in same manner
about (I)TSM DB - it first creates list of DB pages to be backed up and
the last completed transaction in the log. Later all those pages are sent
somewhere and log is cleared up to that last transaction.
Now back to filesystem backup - we can ask ourselves what to do if were
unable to find a window without file activity. Answer is
backup-whatever-enters-in-this-session and the rest (modified during
current backup session) will be backed up in the next scan. Again making a
parallel to TSM DB - all *transactions* completed before DB backup is
started will be noted and backed up. All transactions in progress and
everything happening during/after DB backup will be in the log (of course
if roll-forward is enabled) and will be backed up next time.
On the end - if you are not satisfied with level of protection regular
(daily) file backups provide you should go to some high-availability
solution. This might be two disk subsystems in separate sites with each
write synchronously performed to both (ESS with PPRC or XRC for example).
Same analogy - if you need to protect *each* backup (completed
transaction) in TSM you should have some (very) high-available hardware
for DB and Log.
But this would be a solution at Disaster Recovery Tier 5 or Tier 6. Not
every company/organisation needs it (and is ready to pay its price).
Zlatko Krastev
IT Consultant
Matt Simpson <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
06.11.2002 17:40
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Safe to backup DB while client backups running?
We're trying, usually in vain, to get our TSM environment under
control. We have daily scripts that perform backups of our database,
one onsite and one offsite. The scripts check to see if any backup
sessions are active, and if they are, they reschedule themselves to
try again in 10 minutes.
It's getting more and more difficult to find any time during the day
when backups aren't running. We keep spreading backup schedules out
to try to get stuff to run successfully. Our offsite tapes are
supposed to be sent offsite by 8 AM, but sometimes they're not
getting completed until mid-afternoon.
Ideally, I know it would be safer to backup the database when it's
not being updated by backup processes. But it seems like there's no
way we're going to be able to reach Nirvana. If I want my DB backups
to run at any kind of predictable time, it looks like we're going to
have to allow them to run while client backups are running. Am I
setting myself up for major trouble if I do that?
Actually, I'm not 100% sure it's not already happening. I know we
don't start the database backup if any client backup sessions are
active. But I'm not sure if there's anything in place that prevents
a client backup from starting after the DB backup starts. If that's
true, are we just wasting time spinning our wheels waiting for a
window when no backups are running to start the DB backup?
--
Matt Simpson -- OS/390 Support
219 McVey Hall -- (859) 257-2900 x300
University Of Kentucky, Lexington, KY 40506
<mailto:msimpson@;uky.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.
