ADSM-L

Re: AW: DSM.OPT override question.

2001-04-27 11:25:28
Subject: Re: AW: DSM.OPT override question.
From: Andy Raibeck <Andrew_Raibeck AT TIVOLI DOT COM>
Date: Fri, 27 Apr 2001 08:26:00 -0700
If you are essentially asking whether there is a way to dynamically load a
new options file, then the answer is "no". But even if you could, you do
not want to use INCLUDE/EXCLUDE statements to include these files for
selective backups in one options file, but exclude them for the incremental
backups in another options file. If you try to do this, you will find that
the backups taken with the selective backup will be expired via the EXCLUDE
statement during your normal incremental backup. However, here are a couple
of suggestions that might be useful and do not require a new options file:

1) If you want to combine the selective backup with your regular daily
incremental backup, you can include your pre/post schedule commands to stop
and restart the database in your regular dsm.opt file. In the special
management class you created for the database's files, set the copy group's
MODE to ABSOLUTE (normally it is set to MODIFIED). The ABSOLUTE mode will
tell TSM to back up the files regardless of whether they have changed. Then
set up your include/exclude list so that the database's files are bound to
this special management class. The only drawback that I can think of is
that depending on how long it takes to perform the scheduled backup of the
machine, the database will be down for that time (as opposed to the time it
takes to back up just the database files). Otherwise this is the easiest
solution.

2) Create a batch file on the TSM client machine that does the following:

Issues the shutdown command for the database.
Issues a DSMC SELECTIVE backup for the database's files.
Issues the restart command for the database.

To prevent the regular incremental backup from also backing up these files
(in case they change between the selective backup and the incremental
backup), set up the management class for these files so that the copy
group's FREQUENCY parameter is set to a non-zero number like '7'. This will
prevent the regular incremental backup from backing them up unless it has
been at least 7 days since the last backup. As long as you do the daily
selective backups, the 7-day criterion will not be met, so incremental
backups will not try to back these files up.

Here is a simple batch file example:

  @echo off
  echo -------------------------------------------
  echo Starting command on %date% %time%
  echo -------------------------------------------
  cd /d c:\tsm\baclient
  dsmc s dsm.opt
  echo -------------------------------------------
  echo Ending command on %date% %time%
  echo -------------------------------------------

You would, of course, have to wrap your shutdown and startup commands
around the "cd" and "dsmc" lines.

The schedule definition could include these settings (this is for a
scheduled command on Windows 2000):

  action=command
  objects="c:\tsm\baclient\mycmd.cmd >>c:\tsm\baclient\mycmd.out 2>>&1"

This will cause the output from "mycmd.cmd" to be appended to a file named
"mycmd.out". You would have to implement some mechanism to handle the
growing output file (i.e. to prune or delete it periodically).

Regards,

Andy

Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
e-mail: araibeck AT tivoli DOT com
"The only dumb question is the one that goes unasked."
"The command line is your friend"


Alan Davenport <alan.davenport AT SELECTIVE DOT COM>@VM.MARIST.EDU> on 
04/27/2001
07:58:48 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:  Re: AW: DSM.OPT override question.



Thank you Andy. Our group is under the impression that the vendor is
thinking about the old-style (non-*SM) type of incremental backups where
an operating system utility is used to take a full backup then
incrementals throughout the week.  In this scenario files that were
deleted throughout the week could get restored if the full then all
incrementals are restored. This could of course be a source of problems
for some apps. In this case the vendor has a valid point. Of course *SM
does not behave this way and a point in time restore can be done without
restoring deleted files.

What I'm doing is looking for ways to accommodate them if in fact, we
must. IS it possible to specify a different client options file for a
particular backup schedule? If this is the case there is no real
problem. If not, then I have to look at trying something as ugly as
defining two separate *SM nodes on the server. ):

            Al

andrew_raibeck AT tivoli DOT com wrote:
>
> From: Andrew_Raibeck AT TIVOLI DOT COM
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: Fri, 27 Apr 2001 07:33:48 -0700
> Subject: Re: AW: DSM.OPT override question.
>
> If the product's vendor is making a recommendation about how to back up
(or
> how not to back up) their product, it's probably a good idea to heed that
> recommendation. You do not want to be in a position where you need to
> restore, and the vendor can not help because you did not follow their
> recommended backup procedure.
>
> That said, it would be a good idea to ask the vendor why they make that
> recommendation, so that you can evaluate its technical merits. In this
> case, the vendor may have a very good reason for recomending against
> incremental backups; on the other hand, perhaps they do not understand
what
> is meant by "incremental" backup, so again, a discussion as to why they
> make the recommendation is a good idea, so that all parties understand
the
> issues.
>
> Regards,
>
> Andy
>
<Prev in Thread] Current Thread [Next in Thread>