BUG: ImageManager not correctly cleaning up multiple offsite drives

We have many clients who rotate more than one offsite USB drive.  In a number of cases recently we've found that the replication is failing because the offsite drive is full.  On inspection it turns out that the drives contain old daily and weekly consolidation files that have been removed due to retention policy.

Looking into this it appears that ImageManager is deleting these files from the NAS then only removing them from only the currently connected offsite USB drive.

I've written some scripts to compare files on the connected USB drive with the primary backup location and remove consolidation files that no longer exist.  In several cases the scripts have cleared over 1TB of wasted space from the replication drive, enabling replication to continue successfully.

ImageManager happily replicates to multiple USB drives, surely it should also remove retired images from multiple drives?  Currently it appears to track the deletions and mark them as actioned once the file has been removed from a single USB.  For those situations where multiple USBs are involved we would benefit from an option to never retire the deletion record.





Seems to be working


We have the same setup and ours seems to be ok.

Are you on the latest version of IM?

Are the correct setting applied on the folder?

we see "21-Mar-2017 07:56:20 Removed file(s)" in the IM log. for the USB drive.



Backup & Disaster Recovery in the UK.


Yes, problem persists...

Hi James,

yes, we use ImageManager 7.1.0 for our clients.  This is currently the latest available.

Replication settings for the folders are configured with "Replicate all consolidated files" and "Files moved or deleted by ImageManager are deleted on the destination" which should cover this.  We are also using continuous incrementals, which is where this bug has the largest impact.

To be clear, the files ARE being deleted, but only from a single one of our replication drives.  Three drives in rotation means three copies of each CD file, and only one of those three copies is being deleted when the original is removed due to retention.

If this is not happening to you I would be incredibly surprised as after some investigation it appears that ImageManager uses a database to store the list of deleted files and marks them as deleted from the replica once done.  Once marked as deleted from the replica ImageManager does not attempt to delete them again.  You can test this by taking a copy of a CD file that is about to be deleted by ImageManager (check the retention rules), do the post-retention replication and then restore the copy of the image to the retention drive.  ImageManager will happily leave the file there forever, secure in the knowledge that it has already deleted the replica.

If this is not the behavior you are seeing then please tell me how your replication jobs are configured.

Meanwhile I'm having to script to clean up these damned things.


What version of ImageManager are you using?

Hi Corey,

First off, I'll confirm that I have indeed observed this issue also.

Secondly, what version of ImageManager are you using?  I have not yet verified it personally, but I heard a rumor that this is no longer an issue in newer versions of ImageManager.

Thirdly, the way that I have gotten aroudn it in the past is as follows:

  1. On the backup server, create a scheduled task with "run a program" as the action.
  2. Select "robocopy.exe" as the application to run.
  3. Enter /<path to root backup folder> /<path to replica root backup folder> /MIR in the arguments field
  4. Schedule to run daily at whatever time.
  5. Configure the task to run even if no one is logged in.

Because the task contains all the arguments in the task properties (as opposed to doing this via a batch file), it will run successfully even if you're not logged into the backup server.  I have seen issues with robocopy batch scripts not running if you're logged out.  The robocopy /mir switch will remove any files on the destination which aren't also present on the source.  It won't re-copy existing files to the destination, so it runs very quickly.

I hope this helps!


StorageCraft Certified Engineer

Terms and Conditions of Use - Privacy Policy - Cookies