Sophos Anti Virus affecting incrementals?

[CraigMcGill]

Hello.

Does anyone know whether scans by Sophos Anti-Virus (V7.6.7 on W2K3 R2 EE 64-bit) can interfere with incremental backups? We're finding that incro backups for a system with SAV on it are picking up much more than they should, dozens of GB more in fact, and this is killing the WAN used for those backups.

Some AV products have a switch or registry setting which effectively says "Sure, go ahead and do your scans, but DON'T change any file attributes or dates". This then returns incro backups to normal.

Anyone know if SAV has such a setting and where I can look to see if this is why our incro backups are so big?

Thanx!

 

[CraigMcGill]

Addendum: Interestingly, none of the thousands of files on the big disk in question on this server have the archive bit set. We're using the File System agent's default behaviour of using the change journal and not the archive bit, but I still expect to see all files with an "A" next to them. They don't.

So although this bit isn't in itself affecting our incro backups, it sure points to something weird going on. I wonder who's clearing this bit? And what's hitting the files? Sure sounds like an AV product to me.

 

[Commvaultdude]

had this problem with Symantec as well, got a reply from a user on this forum which is below, now this is for Symantec but I am sure there is something similar for sophos


We had the same issue with SEP where it modifies the change journal that commvault uses to check whtat files to backup. THe note below refers to SEP 11.0 but if you have older versions chech the symantec site


Question/Issue:
You configure backup software to run an incremental backup job that is based on USN change journal entries. After Symantec Endpoint Protection runs a manual scan or a scheduled scan, the backup software performs a complete backup job instead of an incremental backup job. Similarly, DFS (Distributed File System) replicated shares are based on USN change journal, and running Manual or Scheduled Scans against the shared folders will trigger unnecessary replication traffic.


Solution:
The following setting suppresses file modifications for attribute updates, last access dates, and security descriptors.


To fix the problem on 32-bit versions of Symantec Endpoint Protection client, create the following DWORD value and set it to 1:

HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\AV\NoFileMod
To fix the problem on 64-bit versions of Symantec Endpoint Protection client, create the following DWORD value and set it to 1:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Symantec\Symantec Endpoint Protection\AV\NoFileMod

 

[CraigMcGill]

OK I'm pretty sure now that it wasn't the Sophos anti-virus product causing the problem. It seems that someone on site has been switching the old backup product on and off - good old BE has been running and I'll bet that it has been clearing the archive bit on files when it's successfully backed them up, which of course "modifies" the file and puts it into the change journal, making Simpana pick everything up in an incremental backup. Grrrr!

So an (obvious) word of advice for the newbies: don't run two backup products on the one system, especially where incremental or differential backups are concerned (and definitely not on databases like SQL or Oracle - they backup and then truncate transaction logs).

Thanks Commvaultdude for your pointers.