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
