Mirror - Support Topics

Backup for Workgroups can maintain a duplicate copy of your backup data at a second location, which is called the Mirror location. When files are backed up, the Backup Server stores the files at the Primary Storage location.  If you have defined a Mirror location, the Backup Server will copy the backup files from the Primary Storage to the Mirror location.  The process of Mirroring the backup data is near-real-time; the Backup Server prioritizes receiving backup files from the Clients and storing to the Primary Storage, but soon after it will copy the new backup data to the Mirror.  The delay between updating the Primary Storage location and the Mirror is due to load.

For more information about using the Backup for Workgroups Mirror, please read the topics below:

• Why is the storage space consumed on the Mirror different than the storage space consumed on the Primary Backup media?
• How do I add storage to the Mirror location?
• How do I use the Mirror to replace a primary storage location?
• Can I restore a file from a Mirror?

Why is the storage space consumed on the Mirror different than the storage space consumed on the Primary Backup Media?

There are many reasons why the storage space consumed on the Primary Backup Media and the Mirror Media are different. So, when you see that these numbers do not match, you need to think a little bit more about this and do not assume this indicates a problem. 

Let's look at some basic information first.  Look at how much space is being consumed on your Primary Backup media.  To do this, go to the computer running the BFW Backup Server, and look at the Storage Panel. The Storage Panel shows you the size of the storage drive and the amount of free space so you know how much working space you have.  When you subtract the free space amount from the storage drive amount, you get the amount of space consumed.  Please remember that this is the space consumed by ALL files on the drive - meaning all the files for ALL applications storing data on this drive, of which BFW MAY be sharing the drive with other applications. 

Repeat the computation for the Mirror by subtracting the free space of the Mirror from the Mirror drive size.  Generally, the space consumed by the Mirror should be close to the space consumed by the Primary Storage.  These numbers may be a little different due to differences in the way the drives are formatted, cluster size, etc. So don't expect the numbers to be identical, but they should be reasonably close.  Please keep in mind that if you have different sized drives, for example, a 2 TB Primary Storage drive and a 1 TB Mirror drive, and you think, "I'm only backing up less than 1 TB of data" - the free space on these drives will be significantly different, but the amount consumed should be similar. So don't just look at the free space, you need to look at the amount of space consumed.

Do you feel the space consumed at the Mirror is significantly higher or lower than the space consumed at the Primary Backup location?  If so, follow the most appropriate option:

• My Mirror space consumption is significantly lower than the space used on the Primary Storage.
• My Mirror space consumption is significantly higher than the space used on the Primary Storage.

My Mirror space consumption is significantly LOWER than the space used on the Primary Storage.

In this case, there's a couple of reasons why the Mirror could be consuming less space than your Primary (Backup Storage).  The first reason is there may be other things stored on the Primary drive - things that are not related to Backup for Workgroups.  For example, if the Primary Storage drive is holding data for other applications in addition to the BFW backup data, the total drive space consumed is higher than the Mirror. 

Another reason why your Mirror may be consuming less space than the Primary Storage drive is BFW is trying to purge old data (from the Primary Storage drive) and is prevented from doing so.  We see this when you are using a Linux-based NAS as the Primary Storage and you have configured the NAS to retain deleted files.  In this case, when BFW deletes a file, and BFW "thinks" it has deleted the file just fine, the Linux NAS has instead simply moved the file to a Recycle Bin, which Linux calls "the Trash Box."  From BFW's perspective, the file is gone.  But from the NAS's point of view, the file still exists, it is just in a different location; it is in the Trash Box.  So the NAS keeps "growing and growing."  From the Mirror's point of view, BFW tells the Mirror to delete it's copy, and the Mirror deletes the copy.  As a result, the NAS and the Mirror's space consumption looks different due to how the deleted files are handled.  To fix this situation, you need to use the NAS Administrator program to review your settings for the Share that you are using and make sure deleted files are getting purged, not retained.

In some cases, the significant difference can point to a problem with the Mirror drive. You may need to look at the access rights you have to the Mirror drive and make sure you are not running into any space limitations on the Local System Account.  Backup for Workgroups runs under this Local System Account, and if the Mirror has a restriction on this account, BFW may not be able to write to this drive.  Or, the Mirror drive could be showing signs of NTFS file system errors or the drive itself is starting to fail.  Run a Check Disk on the Mirror drive to verify file system errors and drive integrity.

My Mirror space consumption is significantly HIGHER than the space used on the Primary Storage.

When your Mirror space is much higher than your Primary Storage space consumption, it is commonly due to other things stored on the Mirror drive - things that are not related to Backup for Workgroups.  For example, if the Mirror drive is holding data for other applications in addition to the BFW backup data, the total drive space consumed is higher than the Primary Storage. 

Another reason why your Mirror may be consuming more space than the Primary Storage drive is BFW is trying to purge old data (from the Mirror drive) and is prevented from doing so.  We see this when you are using a Linux-based NAS as the Mirror and you have configured the NAS to retain deleted files.  In this case, when BFW deletes a file, and BFW "thinks" it has deleted the file just fine, the Linux NAS has instead simply moved the file to a Recycle Bin, which Linux calls "the Trash Box."  From BFW's perspective, the file is gone.  But from the NAS's point of view, the file still exists, it is just in a different location; it is in the Trash Box.  So the NAS keeps "growing and growing."  As a result, the Mirror's space consumption looks different due to how the deleted files are handled.  To fix this situation, you need to use the NAS Administrator program to review your settings for the Share that you are using and make sure deleted files are getting purged, not retained.

In some cases, the significant difference can point to a problem with the Mirror drive. You may need to look at the access rights you have to the Mirror drive and make sure you are not running into any space limitations on the Local System Account.  Backup for Workgroups runs under this Local System Account, and if the Mirror has a restriction on this account, BFW may not be able to delete files from this drive.  Or, the Mirror drive could be showing signs of NTFS file system errors or the drive itself is starting to fail.  Run a Check Disk on the Mirror drive to verify file system errors and drive integrity.