Recently I installed Archiware’s PresStore at a local university and had a very strange problem.
First of all I want to give you an overview
Mac Pro & Quantum Superloader 3
The Mac Pro is the main component of the backup and archive workflow. It is used to configure all the jobs and saves them to LTO5. During my tests I used a file based library.
The PC is used to produce audio files. The problem is that on the PCs multiple backup copies of an unchanged file are created while using PresStore’s backup feature.
Reading the support documents
First I search around in Archiware’s knowledgebase and found the article titled “Why does PresSTORE sync or backup a file once more?”
With the help of this I enabled logging – then created the following workflow to reproduce the problem:
How to reproduce
On the local drive D: I created a new folder and on the Mac Pro server I added a new backup job (including a new file based library as destination) for this folder.
Whenever I added a file to the folder and started the job the new data was successfully copied – everything worked as expected.
But if I started the same job again without modifying the folder (not even touching it) the file gets copied again – therefore a lot of space on the tapes is wasted.
Here’s the interesting part of the log:
[13/Apr/2012:16:30:05][3764.10f4][-fwlkt:10f4-] Dev: BcxIndex: NEW entry /D/test/file.zip
[13/Apr/2012:16:31:23][3764.9f0][-fwlkt:9f0-] Dev: BcxIndex: UPD ctime (1334327405 > 1334327400) /D/test/file.zip
What’s going wrong
At first I thought that a third party application is changing the file so I used Process Explorer to capture all events. – But to my surprise no access to the file was captured!
Possible solution 1
In the end I gave up and contacted the support. They replied very fast and reported that this problem is caused by a “feature”.
Windows does not have a real ctime file information – sometimes when a file attribute is changed the modification date is not updated but the archive flag is set. Therefore a file with a set archive flag is backed up twice!
To work around this behavior you have to enabled “Scan files before backup” in the “Additional options” of the specific backup job.
Here’s a video of this solution
Possible solution 2
The support also told me about a second possibility: disabling the ctime check on the server.
This is done by adding the following lines to the configuration file /usr/local/aw/conf/lexxsrv.8000
ns_param testInodeChangeTime 0
As this change disables the ctime check completely on all clients there are some sideffects. Therefore the following changes will NOT trigger an incremental backup:
- extended attributes are changed (Mac)
- POSIX and ACL permission change (Mac)
- file attributes (Windows)
- streams (Windows)
- permissions (Windows)
Full backups and content changes still backup the file!