The actual space savings depend on the change rate of the source data and the types of chains that are used on the ReFS repository.It is not generally considered a good idea to have deduplication for the primary backup chain as this effects performance and increases RTPOs.Instead it would be better to use a primary repository configured with ReFS and then have a secondary location configured with Windows Deduplication (Compression should be off instead of auto).It is not a good idea to target the primary and backup copy job to the same repository as this negates the 321 rule and if an issue was to occur on that repository the primary and secondary copies of data would be lost.There is a time growth feature for you to set as well as your expected change rate so that will help answer your question. Make sure you check the refs/xfs box as this will give you the space savings effect you are seeing with multiple fulls. I would suggest setting it to backup copy job (I understand you are not doing a backup copy job in veeam, but this calculator does not seem to have the latest v10 changes where you can use gfs in a main backup job and so this gives you similar results and let's you configure gfs settings) One/some of their engineers created and maintain this I believe. But still only unique blocks are ever going to be sent to capacity tier.įor space figuring, you could try using this Eventually there are less similar blocks as the months and years go by so it may grow larger down the road. So your bucket is only going to grow similar to the size of your incremental backup sizes for a while. It is not dedupe but a way of preventing duplication in the first place. It works similar to the refs/xfs block cloning feature in those file systems.
Object storage in veeam is offloaded in incremental forever manner.
0 kommentar(er)
