Change repository block size

[perjonsson1960]

Folks,

Someone, who probably wants to be anonymous, made a mistake when we originally set up our backup repositories... We use ReFS, and the block size was set to 4K, which is the default, while the recommended block size is 64K. We have noticed some strange performance issues when the servers are writing to disk, and the block size is the probable cause.

My question is, if I move all the files from a repository to someplace else, format the now empty repository with 64K blocks, and then move the files back again, will the repository work as before, including its membership in a scale-out repository?

Regards,
Per Jonsson
Sweden

[jmmarton]

Overall it should work ok though to be safe you should rescan the repo after moving everything back. However, one thing you'll lose is block cloning. In other words after moving all the backups back all restore points including synthetic fulls will require full space usage rather than being pointers. Going forward after the reconfig, new synthetic fulls will leverage block cloning.

Joe

[perjonsson1960]

This doesn't sound good... Does this mean that we lose all deduplication? In one of the repositories we have this status:

Capacity: 91 TB
Free space: 45.6 TB
Used space: 173.2 TB

Do you mean that when I move all the files from that repository to another, which also use ReFS and dedup, then the files will physically take up 173.2 TB?

[jmmarton]

Correct. The only way block cloning is used is when specific APIs call it, so when you copy everything off you will need at least 173.2 TB of space available.

Joe

[perjonsson1960]

Okay, so this is an impossible project, then, because we don't have that kind of space anywhere. So either we need to send loads of GFS policy data to the bitbucket, or continue to live with 4K blocks and poor performance. Thanks for your reply!