Feature request:ReFS 3 without Align backup file data blocks

[jb238]

I'd like the checkbox "Align backup file data blocks" to be user configurable even with ReFS 3. Preferably in GUI but possibly with a registry key.

The block aligning costs 10% space penalty (with 64K blocks) and is necessary for Fast Clone. There are situations where ReFS3 makes sense (checksumming, auto repair with Storage Spaces, scalability) but using Fast Clone does not. Fast Clone tends to badly fragment the disk, which negatively affects restore performance and also copy performance (e.g. to external USB disk). Backup servers tend to have few big disks, which results in large capacity but poor IOPS. Preventing the disks from getting fragmented helps as does minimizing the random IOs.

I use weekly active full backups with incremental. Additionally daily backup copies with monthly full and "Read the entire restore point from source backup" checked. This gives me sequential file operations with very few random IOs. It also results in very little fragmentation. So I use ReFS for the checksumming, do not use Fast Clone, but still pay the 10% penalty.

[Andreas Neufert]

There is a way to disable block cloning if you like.
HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\
RefsVirtualSyntheticDisabled
Type: REG_DWORD (0 False, 1 True)
Default value: 0
Description: By default, Veeam Backup & Replication uses Fast Clone for all backup repositories that meet the specified requirements. You can disable this option with this value.

[Gostev]

We have a registry for everything that there is even a slightest chance someone may want to disable

[jb238]

Yes, there is a registry key to disable fast cloning. However there is no way to disable "Align backup file data blocks" if the file system is ReFS3. I opened a case with Veeam and was told this.

[Gostev]

That is not correct. This particular setting is stored in the configuration database (as a part of other job settings) and can be easily modified by support. UI has this check box disabled, but it does not mean they cannot change it directly in the database for the given job.

[veremin]

Alternatively you try to change this setting via PowerShell (it might not necessarily have the given limitation):

Code: Select all

Asnp VeeamPSSnapin
$Repository = Get-VBRBackupRepository -name "Name of your Repository"
Set-VBRBackupRepository -Repository $Repository -AlignDataBlocks:$False

Thanks.

[jb238]

Thanks for the feedback. I tried

Code: Select all

$Repository = Get-VBRBackupRepository -name "Copy"
Set-VBRBackupRepository -Repository $Repository -AlignDataBlocks:$False

but got an error:

Code: Select all

Set-VBRBackupRepository : Unable to change data block aligment settings. ReFS repository is used as a repository
At line:1 char:1
+ Set-VBRBackupRepository -Repository $Repository -AlignDataBlocks:$Fal ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Set-VBRBackupRepository], Exception
    + FullyQualifiedErrorId : System.Exception,Veeam.Backup.PowerShell.Cmdlets.SetVBRBackupRepository

[Gostev]

So it's properly blocked in PowerShell as well - good job by QC

[Deon]

Dear Gostev, can we rely on your experience that this change will be harmless for the production infrastructure?
There is likely a good reason why QC blocked this, and there is no official documentation that suggests that it is supported.

[foggy]

Yes, there is a registry key to disable fast cloning. However there is no way to disable "Align backup file data blocks" if the file system is ReFS3. I opened a case with Veeam and was told this.

If you disable FastClone, alignment will also be disabled.

[Gostev]

@Denis yes, it is totally safe. The code fully expects to encounter unaligned files and will work with them normally, without using block cloning functionality. There are many valid scenarios when unaligned files may appear in ReFS 3.1 repository, so this has been thoroughly tested and is fully supported.

QC made sure it is blocked in PowerShell because it is blocked in UI, with the latter implemented based on my request I just did not want users to be able to easily mess up block cloning without realizing they do, making the following few synthetic fulls overfill their backup repository as the result.

[kubimike]

IMHO would rather want fast disks/controller and block cloning FTW. I can do a fast clone of 11 TBs in 8 mins.

[Gostev]

Agree. Not only performance, but also disk space consumption (periodic fulls will no longer be spaceless with fast clone disabled).

So in the end, it is a simple choice of capacity vs. performance. You can buy lots of slow fat disks and then deal with fragmentation slowing them down even more by disabling fast clone (but that's OK because you have lots of capacity for those periodic fulls). Or you can buy a faster storage and don't worry about fragmentation at all (and it can be a few times smaller as you don't need those periodic fulls any longer).

Keeping in mind all the advanced stuff Veeam can do from backups, for the primary backup repository I prefer the latter - and this is what we are recommending in our reference architecture as well.

[kubimike]

cant slow disks also impact restore time? Most forget about that too

[Deon]

cant slow disks also impact restore time? Most forget about that too

@Kubimike
Indeed, especially if you consider that the restore is likely to trigger a lot of random read operations on the storage, and random read is always slower, especially if the data is deduplicated.

@Gostev
Thank you for the clarification. I am the kind of a guy who always double-checks stuff before suggesting it when I hear it from someone, even as experienced as you. I appreciate the response a lot.

[jb238]

Our history that lead to disabling fast cloning and no align data file blocks:

The backup server has its OS on a SSD and repository on a Storage Spaces RAID10 consisting of 24 4TB 7k2 SAS3 disks.
It is connected via 10Gb Ethernet and hast 128GB RAM.
The repository disk was formatted with ReFS and 4K blocks in December 2016 (when 4K blocks were still recommended). Data integrity is turned on.
Full backups are around 7TB, incremental backups around 330GB.

I configured weekly synthetic full backups and daily incremental (7 generations kept).
On the same disk is a repository for copies (monthly full, 28 days incremental).
The jobs were configured so we have a weekly full to export to USB disks and still keep a longer range of backups without too much disk space usage.

The first weekly backup took only 2.5h (compared to 2h for an incremental), so fast cloning seemed really cool.
During the next 1.5 months, the synthetic full backups took longer and longer. The last weekly synthetic ran for more than 14h and the server got real problems, login was no longer possible and it had to be hard reset. Exporting a full backup to 2 USB3 disks also got slow, so the bottleneck was with the backup server instead of the USB disks.
It seems the disk got badly fragmented with time (certainly the data, probably the meta-data too).

I then reformatted the repository volume with ReFS and 64K blocks (too keep the number of blocks down) and switched back to weekly full backups. The copies use active copy from source instead of forever incremental.

So now we have sequential IO for backups. Since we no longer use fast cloning, I wanted to disable block alignment to save the 10% space.