File Backup Set Catalog Sharing Violation – intermittent problem solved

[JoeK]

File Backup Set Catalog Sharing Violation – intermittent problem solved

 

Culprit: Comcast (McAfee) Security Suite “Local Archive†option turned ON.

 

Software & Hardware config:

I use a dedicated partition on 2nd internal HD as backup device (not over network)

Retrospect Express V 5.6.132 run on Windows XP 2002 SP 3 (it’s an old system).

 

Symptoms of intermittent problem using a File Backup Set:

New backup set would work fine for several days or weeks, then consistently give errors:

“Can’t access backup set (name), error -1020 (sharing violation)†when trying run backup.

“Couldn’t open Catalog, error -1020 (sharing violation)†trying to verify or repair backup set.

But CAN browse the affected Backup Catalog using Configure/Backup Sets/Properties tool to see the list of Snapshots, Sessions and files (Catalog is contained within the Backup set).

Problem affected some, not all, file backup sets.

Sometimes an affected file backup set would start working again for no apparent reason.

 

Important clue it’s NOT Retrospect software problem: Windows OS refused to delete (move to recycle bin) the affected Backup Set file, saying it was in use by some program even when Retrospect was not running.

 

Solution: Open McAfee security suite > Configure > Computer & Files > turn OFF “Local Archive†option. Option says: “Local Archive protects your files and folders by allowing you to back up to and restore data from CD, DVD, USB, network, and external hard drives.†I starting using the Comcast/McAffee suite for virus protection several months ago but never used this software to back up any files. It’s default source folder is “C:/.../MyDocuments†, not my backup partition on 2nd HD used for Retrospect backup sets. But apparently the McAfee “Backup & Restore†program in the suite scans all internal HDs and somehow sets some bit (or does not properly close) the RExpress Backup Set file so that WinOS and RExpress thinks the file is in use.

 

Thanks to Robin Mayoff for previous posts on sharing violations that helped steer me to find the culprit, especially checking that WinOS refused to delete the backup set file.