Hi all,
We’ve had a few questions about how our Single Instance Store works in our File Replication Engine, so I thought I’d describe how it works. The trick is because it’s transparent, it can *seem* like it’s not working, but it is possible to verify that it is working.
Side note: For those who aren’t familiar with our File Replication Engine – you can think of it as Robocopy on steriods. It backs up your file system by copying files, and provides “snapshots” of your file system every time the backup is run. See our one page Fact Sheet for more details:
http://www.backupassist.com/downloads/factsheets/factsheet-filereplication_web.pdf
Basically, if a file doesn’t change from one backup to the next, then it won’t be copied over. Instead, the previous version of the file is used, and that file is only stored once on the hard drive. It’s simply linked to in the new backup. However, if the file does change, it will be copied over, and occupies more space on the hard drive. Files are deemed to have changed if the contents of the file changes (thereby modifying the modification date), or if the file’s attributes change (eg. read-only flag) or if its parent directory changes.
However, because each backup looks exactly like a full backup (refer to the Fact Sheet), if you go to Windows Explorer, select the directories and right-click > Properties, Windows will give you an inaccurate byte count because it counts each file multiple times. However, if you go to the drive, right-click > Properties, you will see how much space is occupied on the disk itself.
For example, if I back up 10 gig five days in a row, and nothing changes, then using Windows Explorer on your backup directories will report 50 gig of disk space used, but on the drive itself it will report a little more than 10 gig (which includes a small overhead for the directory table).
The Media Usage Reports in BackupAssist will clearly show how much space each successive backup takes, and how much space was saved by the Single Instance Store.
