ADSM-L

Re: Directory path backed up again and again ...

2005-03-08 10:48:36
Subject: Re: Directory path backed up again and again ...
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 8 Mar 2005 10:47:56 -0500
On Mar 8, 2005, at 10:16 AM, Andrew Raibeck wrote:

Hi Arnaud,

As Andy says it in his excellent web page : A normal Incremental
Backup
will *not* back up directories whose timestamp has changed since the
last backup.

This statement is wrong. I'm not certain you are referring to me (I
don't
have a web page) or another Andy, but it would help to know the
context of
this information. If the directory timestamp changes, I would expect
it to
be backed up.

Try running "dsmc query backup" for the problem directories, and use
the
-detail and -dirsonly options. What does that output show? Do you see
any
differences in the timestamps?

Hi, Andy -

I think platform distinction makes a difference here...
My experience (verified by experiment) is that Unix (AIX at least)
directories do not get repeatedly backed up as their file complements
change and their timestamps thus change. In the Unix environment, a
directory timestamp is a trivial thing - too trivial to warrant another
backup of the directory, where a restoral would be changing the
directory timestamps anyway. In Windows, with its larger data set in
the structure of the directory info, I can see that the directory would
be backed up again when changes occur.

In Unix, directories will likely get backed up afresh where the
Incrbydate option is used, where there is no referential data for the
client to consider when performing the backup. Another cause of
directory backups in Unix is less common, and often "invisible": the
use of Access Control Lists on the directory, as via the aclput
command. (Using the -e option of the ls command makes the existence of
the ACL apparent, where its contents can be listed via aclget.)

Beyond that, I don't have an explanation for Arnaud's experience.
Review of the file system area and the client backup log might yield
clues.

   Richard Sims