Incremental duplicate erase "all" files first

[LeifC]

After upgrading from Panther Server (10.3.9) to Tiger server (10.4.7) we now have problems with incremental Duplicates.

 

Retrospect 6.1.126 (driver update 6.1.6.0.0) are duplicating a Data volume to a Backup volume (internal disks on server which are also running Retrospect locally).

 

 

Somehow the Duplicate script thinks "all" (almost) files are changed and need to be replaced.

 

We have a second script backing up to tape from 3 folders on the Backup volume.

 

When the folders are replaced Retrospect can't find 2 of them (I guess the third folder isn't replaced).

 

I now (temporarily) have to change the tape backup script to use the "same" 3 "subfolders" on the Data volume instead of on the Backup volume.

 

This will probably work OK but I'm curious why the Duplicate script thinks "all" files are changed (and the Duplicate will take longer replacing more than 40 GiB each nigth)?

 

ACL's are turned on for all server volumes (the Backup volume isn't shared) and it didn't seem to make any difference for this problem when I turned ACL's off on the Backup volume.

 

I changed the Duplicate script to duplicate the whole Data volume to a folder on the Backup disk bacause I now also want backupsets and settings duplicated to the Backup volume (two other folders).

 

Any idéas?

[CallMeDave]

You seem to be describing two different issues. The first sounds pretty straight-forward; Retrospect is not Matching files on the Destination that are unchanged on the Source.

 

This has been discussed on some other threads here in the past. I've seen it myself, but actually stopped trying to hunt it down when I stopped trying to use Duplicates as a backup strategy (it was simply taking too long to scan _two_ complete volumes, and it also makes me nervous anytime I allow software to delete files as a matter of course).

 

I've complained before that Retrospect uses Matching criteria that is not visible to the user (with the "Get Info" dialog boxes that are available for that purpose). One poster suggested turning off "use attribute modification date when matching" from the backup's Options/Matching panel.

 

The second issue, related to the first, is unclear on my first reading. But remember that Retrospect doesn't copy or duplicate folders, but instead creates them on the fly when necessary. It has always worked that way. So if you have configured the program to see a folder in a Source, but then that folder is deleted/re-created with a new one, Retrospect will not be able to find what it needs (note that Retrospect does not keep track of items with only their path, but also uses unique file ID so that it's not fooled by changed names).

 

Dave