Why is it backing up the EXACT same file?

[MrPete]

Yikes. I'm new to Retrospect 15, although was a long time user of early versions.

Unless my memory is failing me, Retrospect has always been quite smart about avoiding needless copies of the same file content. The same binary file content only stored once for multiple copies of the original file (even with varying ownership and attributes), for copies on the same or different computers.

So, imagine my surprise and actually horror, to see the following on three successive backups:

a) Day 1, G: drive, 2TB of files stored

b) Day 2, G: drive, nothing new needs to be stored

c) Day 3, G: drive, the SAME files are stored again.

I checked. The stored file information says the same files, with the same timestamp, were backed up on two separate occasions.

What causes this, and how do I eliminate it? Yes, it is using up Real Disk Space. I don't have THAT much backup space!

 

Any hints much appreciated,

Pete

[Scillonian]

Is "G" drive an internal or external drive? What is stored on "G" drive?

Check to see whether the option to backup file and folder security information for workstations (not near Retrospect at present so can't say exact wording) is enabled in the backup script options. If this is enabled this can cause this kind of behaviour.

[MrPete]

It is an internal drive.

Yes, file and folder security info is being backed up. If that causes this, it's an obvious bug:

* Retrospect is supposed to save metadata separately, so that it doesn't save duplicate copies of files from different clients, just because they have different metadata

* In this case, none of the files on the drive have been touched. It is a large photo archive.

 

[Lennart_T]

What else happened between day 1 and day 3?

Any Windows update? That might cause metadata to change and that causes the file to be backed up again. The reason for that is that there is no way for Retrospect to really know the files are really identical, as it does not perform a byte-for-byte comparison of the contents. All it sees are two files with similarities in SOME of the metadata (such as size and probably dates), but not in other metadata. In order to prevent data loss (if the files indeed were different), the file is backed up again. Backing up is all about preventing data loss. :) 

[MrPete]

Tech support has been very helpful.

It turns out the Backup Script "Options" settings do not do what they say. I don't think I could have guessed most of these without a ton of trial and error.

Here's an Approximation of Reality

1) Macintosh Client "Use attribute modification date":
- Actually applies to BOTH Mac and Windows!
- It is not discussing FILE modification date but potentially a change timestamp on any file attributes.
- SAFEST to leave this unchecked for all Windows backups

Windows Security "Back up XYZ security information from XYZ"
- These do NOT control whether file/folder security info is backed up! File/folder security info is ALWAYS backed up, whenever contents are backed up.
- These control whether the info is *compared* to decide if a new backup copy is needed.
- Thus, changing any of this will tend to force a new backup of a file/folder. Even going from "on" to "off."
- Except for exceptional circumstances, it ought to be safe to leave these turned off because the security info is backed up anyway.

Since we want the ability to successfully do bare-metal restores, I had turned on "Back up file security."

So: Now, I have File security backup OFF, and Mac client "Use attrib mod date" OFF. ...

...And everything is working as I would have expected in the first place.

(I also asked if there is any diagnostic allowing us to see the attributes that are stored... to verify that change-comparisons are actually working correctly. Sadly, not yet.
 

[Lennart_T]

Thanks for posting the explanation.