ADSM-L

Re: [ADSM-L] Need some support for snapdiff RFE's

2012-02-14 20:58:30
Subject: Re: [ADSM-L] Need some support for snapdiff RFE's
From: Grant Street <grants AT AL.COM DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 15 Feb 2012 12:53:14 +1100
The reason I raised the RFE was that, to me, anything less than
certainty is an incomplete backup ....

If I need to do a regular full JIC then that, is a lack of certainty.

So I suggested the following
1. For "Include/exclude changes", "delete backup" or "policy changes" to
force a create new base eg delete the TSM created snapshot.
2. For "File skipped" or "file excluded for file set" Delete the newer
TSM snapshot, rather than the older one so that the problem can be
corrected and the files backed up on next run while still using
snapdiff. It just means that the snapshot may be a little older.

This will mean that there will be certainty in your backup that is not
reliant on additional schedules.

It will have a downside of more non-scheduled full backups as a full
backup will be triggered by anything listed in (1) on next incremental
backup. Another downside is that the TSM snapshot may be larger until
anomalies are resolved.

The downsides in a stable system would would be about the same if not
less than the current situation.

Hope that explains my thinking

Grant




On 15/02/12 05:08, Pete Tanenhaus wrote:
Actually this really isn't correct, a snapshot differential backup will
detect deleted files and will expire them on the TSM server.

Periodic full progressive incremental backups are recommended because "less
complete" backups such as snapdiff,
incremental by date, and JBB can never be as comprehensive as a full
progressive given that a full progressive examines
every file on the local file system and every file in the TSM server
inventory.

Note that "less complete" implies that changes processed by a full
progressive might be missed by other "less complete"
backup methods, and this is the reasoning behind recommending periodic full
progressive incrementals.

JBB is somewhat better in that in makes every attempt to detect conditions
which indicate that the change journal is out of
sync with what has previously been backed up and to automatically force the
full progressive incremental backup instead
of requiring the user to manually schedule it.

For reasons that require a very detailed explanation (let me know if you
are interested), the current snapdiff implementation
doesn't have the robustness or resiliency that JBB does and therefore
really requires manually scheduling full progressive
incremental backups via the CreateNewBase option.

Hope this helps ...

Pete Tanenhaus
Tivoli Storage Manager Client Development
email: tanenhau AT us.ibm DOT com
tieline: 320.8778, external: 607.754.4213

"Those who refuse to challenge authority are condemned to conform to it"


|------------>
| From:      |
|------------>
   
>--------------------------------------------------------------------------------------------------------------------------------------------------|
   |Paul Zarnowski<psz1 AT CORNELL DOT EDU>                                     
                                                                             |
   
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
   
>--------------------------------------------------------------------------------------------------------------------------------------------------|
   |ADSM-L AT vm.marist DOT edu                                                 
                                                                             |
   
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
   
>--------------------------------------------------------------------------------------------------------------------------------------------------|
   |02/14/2012 07:12 AM                                                         
                                                                      |
   
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
   
>--------------------------------------------------------------------------------------------------------------------------------------------------|
   |Re: Need some support for snapdiff RFE's                                    
                                                                      |
   
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
   
>--------------------------------------------------------------------------------------------------------------------------------------------------|
   |"ADSM: Dist Stor Manager"<ADSM-L AT vm.marist DOT edu>                      
                                                                             |
   
>--------------------------------------------------------------------------------------------------------------------------------------------------|





Grant,

The time stamps are not updated, because a snapdiff incremental does not
deactivate deleted files.  You need to do periodic 'createnewbase' to do
this, which walks the file system and updates the time stamps.

..Paul

On Feb 14, 2012, at 12:32 AM, "Grant Street"<grants AT AL.COM DOT AU>  wrote:

Hello

Just thought I would plug two snapdiff RFE's(Request For Enhancement)
that I created on the IBM developer works site.

I am trying to garner some support for these in the hope that they will
be implemented in the future.

I have seen that some of you have had experience with Netapp snapdiff
backups and you may have similar beliefs.

"Define snapdiff and other snap options on a per filesystem basis rather
than per backup command"
When running an incremental backup be able to define the snapdiff or
other snap option on a per filesystem basis rather than for the whole
backup incremental job.


http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=12858

"Snapdiff to update last backup fields in filespace data"
Could you please update the TSM snapdiff client to update the lastbackup
information of filespaces when a "query filespace f=d" is issued. This
would be the obvious behaviour and would be inline with the documented
meaning of the columns


http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=13145

TIA

Grant