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.

PC

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.

My proceeding

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_section ns/server/$server/module/bixindex
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!

I often have to migrate mailservers therefore it’s important for me to have a tool like imapsync.

Imapsync, as the name suggests, is used to sync a source and a destination imap mailbox. It’s highly customizable and can be scripted using the powerful command line interface.

I don’t want to write a full tutorial (see here, here or here) but instead give you a short overview.

Requirements

• Perl
• Mail::IMAPClient (get it using cpan or direct download)
• imapsync

Simple usage overview

imapsync --host1 imap.truc.org --user1 foo --password1 secret1 --host2 imap.trac.org --user2 bar --password2 secret2

For further information see the man page.

Problems

This is the most important part of this posting. Here I will list problems that I encountered.

imapsync quits in the middle of a synchronization

This is most likely caused by a broken Mail::IMAPClient library. Try to download a (newer) version here and include it using perl’s “-I” command line parameter

“xx BAD Command Argument Error. 11” is printed

I had this problem once using an Exchange 2011 as the destination. It means that the current message exceeds the maximum message size. See this post for how to fix it.