The backup size as reported in Windows Explorer or Finder will be the total size for the set, not the actual amount of disk space it consumes. So my guess is that the space savings benefits are there but you're not looking in the right place.
A simple test:
1) run a backup
2) check the amount of free disk space
3) immediately run a new backup
4) check the amount of free disk space --> you'll see that it did not decrease provided that nothing was changed in the db between the backups
5) use Finder or Windows Explorer to ask for the size of the new backup --> it will be the sum of all files in the backup set, but that's obviously not what it occupies on the hard disk
There are more technical ways to see the hard-linking in action if you are interested.
Hmm... that's interesting. Thanks Wim.
Is that the case whether or not FMServer is using Progressive Backups? That externally stored files are always hard-linked in backups, and not duplicated within each backup?
It is independent of Progressive backups. All backups in FMS use hard linking.
But keep in mind that it is only within the same backup schedule. The progressive backup sets only do hard linking among themselves, not with other backups.
If you have 8 separate backup schedules, one for each hour then each schedule would occupy disk space for the full set and there would be very little hard-linking benefit. If you have one backup schedule however that runs 8 times a day then each set of that one schedule would keep efficient hard linking and you'd safe a lot of actual hard disk space (and get a backup speed boost).
Great. Thanks Wim!
Another benefit with External Secure storage is that duplicate files (the same file stored in the same container field on multiple records) are actually stored only once and only deleted once the last record 'owning' the file is deleted.
At least I'm under the impression based on my own tests that it works this way with External Secure storage opposite to embedded container fields.
I would be happy being corrected if it's not the case.
It'd be very easy to prove; look at the file in the OS while exposing the hard link counter.
That and watching the disk space usage did make me believe it does work this way.
As long as the same file is uploaded multiple times in the same table, the number of hard links stays the same and disk space usage shows no difference. Uploading the same file in a different table however does create a duplicate hard link _1, _2, etc and disk space used increases as well.