Questions about storage usage under ReFS

[fsr]

Hi,

I was testing the backup of a VM on an ReFS repo. The idea was to check how much of a penalty would be to use full backups instead of synthetic of forever incremental, so i did a manual full backup first, and followed by a programmed full backup. The job is incremental with an Active Full on Fridays.
After that, i was expecting to see two full backups, and twice the storage use, but the free space on the drive hardly lowered at all. I suspect that Veeam+ReFS are using the same matching blocks for the two backup files, saving a lot of storage in the process. Is that so? Each full backup had a size of around 20 GB, but with the second full backup in the disk, the free space only lowered by 3.2 GB.

Some interesting details that are showing on the logs:

First (manual) full 27/06/2019:
Data read 33,8 GB
Backup size 20,2 GB
Duration 09:41

Second (scheduled) full 28/06/2019:
Data read 33,8 GB
Backup size 20,2 GB (but in reality, free drive space only lowered by a mere 3.2 GB)
Duration 09:54

Scheduled incremental 01/07/2019:
Data read 3,1 GB
Backup size 841,7 MB
Duration 03:30

So, if active fulls are re-using the same matching blocks than already-present full backups on ReFS, from a storage point of view, it seems similar to using incrementals + synthetic fulls to me. Still much slower, as all data is readed on the source, and transferred over the network, however.

Is there any advantage on using active fulls, of forever forward incremental with the consistency checks is just as reliable?

Regards

[HannesK]

Hello,
from a disk saving perspective ReFS is only relevant for synthetic fulls. Active fulls don't use block cloning API.

Please search FAQ for backup modes, ReFS & active full.

Yes, consistency checks are reliable if you check the checkbox

Best regards,
Hannes

[ChrisGundry]

ReFS can give significant disk space savings.


It also reduced our synthetic fulls from 12-20hrs to under 1 hour in most cases. Worth considering if you ever need to put those backups on something that is not ReFS because if you do then the backups would become their full size, so in our case we would need 166TB to move this repos backups.

[ejenner]

yes, that's something I've realized recently.

In my case trying to fit Backup Copy jobs into a ReFS repo and finding no savings. They take up the same amount of space as the original backups on the first ReFS repository. I do save a lot of space on there using ReFS but probably nothing on the repository where the backup copies are directed.

[HannesK]

backup copy jobs work with REFS block cloning as long as you don't to active full backup copy jobs. I suggest to double check with support.

what Chris is talking about is doing "CTRL+C" and "CTRL+V" in Windows explorer

[jim.lowry]

Keep in mind that if you are moving to a REFS repo from a different file system, say NTFS to REFS, then you won't be able to take advantage of REFS space savings until a new active full is taken. You can also use compaction to help. The reason being you need a new block level copy that REFS can use. A file level backup on NTFS to REFS will use the old disk geometry from the original NTFS source. An active full or compaction will force the full to write blocks into the disk geometry that REFS uses. Then from that restore point going forward, REFS space savings will start to take effect. Make sense?

Some of the concepts can be found here: https://helpcenter.veeam.com/docs/backu ... l?ver=95u4

[ejenner]

Still only a one-time effect no matter what way you slice it. I get space savings with the original backup to ReFS repository. Backup Copies from that repository to another ReFS repository don't show any space savings. Not that I'm complaining... it works well for the first backup.