ADSM-L

More answers

1995-03-10 22:55:07
Subject: More answers
From: "Jacquelyn B. Reith" <jreith AT VNET.IBM DOT COM>
Date: Fri, 10 Mar 1995 19:55:07 PST
On March 10 Joe Farrachio said:

>  I've been patiently waiting to hear more answers about this
>  problem, but I'm not sure if the questions have even been
>  asked

>  Basically it comes down to the fact that this system is
>  INCREMENTAL in nature. I've had all my users turn on
>  COMPRESSION.

> So if I tell all my users to turn off COMPRESSION for any
> further backups until they install the fixed client software,
> then will all files be backed  up now that compression is off?
> Will ADSM skip backing up any files that
> haven't changed, including the 'buggy' ones?   Do I need to
> have my users do
> something out of the ordinary, say like re-labeling their
> volumes, to force
> an full backup (with compression off)???


 ***> Hi Joe.  You have a variety of options you can consider, and they
      depend on how you run your installation so the choice is yours.

 1.  If you accept the risk that the exposure is small, get our new clients
     ASAP and continue as normal.  Log when users start using the new clients
     so when our analysis tool comes out you can eliminate any files found in
     the analysis that are newer than xxx date/time.  Take corrective action
     with the analysis tool.

 2.  If you do not accept the exposure, then you should prioritize which clients
     to fix first.

     Get the new clients (available today from the internet server
                        ibmstorysys.ibm.com ---> Scott verify and fix this)

     Force a full backup for those clients (with compression on).  You can do
     this in a few ways:

 A. Turn the compression function off for all clients.
    This can be done as follows:
    a. List all nodes and note those with compression turned on
    b. Update the definition for these nodes to set compression
       off
 B. Re-backup critical data
    To ensure that you have valid backup copies of your critical
   data, re-initiate the backup process for those clients
    a. Create a new policy domain for your critical client nodes
    b. Define these critical client nodes to the new policy
       domain.
    c. Update the default management class to specify the
       absolute backup option (MODE=ABSOLUTE)
    d. Initiate the backup process manually or wait for the next
       scheduled backup process to run.
    e. Once the backup process has completed, reassign these
       clients to their original policy domain and management
       class.
   Once the fixes become available, follow these steps:
   1. Apply the PTF to the client
   2. Turn the compression function back on.

 3.  If you want, you can do this without the new clients, but with compression
     off.

 4.  You could do as you suggest, change volume lables.  This would start a
     new series of backups for those users, and once you had enough versions
     of data stored just go and delete the data for the old volumes.
     This would probably generate about the same amount of data traffic as
     other options, plus give you a very clean slate to work from.

 One thing to remember is that this basically comes down to a full backup.
 ADSM, with its progressive backup mode, has attempted to elimiate the need
 for any full backup as other backup products require.  This situation may
 require full backups just to flush the system out of old data if you are
 unwilling to wait for the analysis tool.


 Paul


<Prev in Thread] Current Thread [Next in Thread>