Windows 2019 (REFS and dedup) as repository

[supradiz]

Hi,

Windows 2019 is GA. Is it valide for a repository REFS and dedplication activated ? What are the limitations or risks ?

Best regards

[foggy]

Please note that Windows Server 2019 support is coming in Veeam B&R 9.5 U4, so using it as repository with the current version is not recommended at the moment.

[Rick.Vanover]

Welcome to the forums, @supradiz - Foggy has it right. Just for background - Veeam takes platform support very seriously - and WS2019 testing is underway from a product perspective. The expectation for Veeam in the market is what I would call full and complete WS2019 support, which will include:
-Installing Veeam console on (WS2019)
-Installing components (proxy, repository, WAN Accelerator, etc.) on
-Hyper-V 2019 for backup & replicas
-Guest VMs on VMware and Hyper-V backing up and replicating
-REFS as you indicate as well is a scenario to check thru

Theses are just some of the situations off the top of my head. It is all underway but it is a comprehensive matter and the expectation we have given to key partners like Microsoft and VMware is that Veeam would support the newest platforms within 90 days of their release.

[supradiz]

Thank you for the answers.

[DaStivi]

Any news regarding server 2019 deduped refs volumes ??

I guess dedupe will definitely save some more bytes as fastclone alone, as when you just imagine using perVM Backup the Core Operating System Files still get backued multiple times...

The only question is if there is still the 1tb dedupe filesize limit, as this would make it useless for backups again.. (as long Veeam don't split perVM in per disk backup files, even then it's not say'd that there isn't ah big single disk with more then 1tb )

[Mike Resseler]

Hi DaStivi,

We will have experimental support for it in Update 4, by using a registry key to enable this functionality. Those details will included in the What's New document.

Thanks!

[B.F.]

The only question is if there is still the 1tb dedupe filesize limit, as this would make it useless for backups again..

"Microsoft actually supports looking at the first 4 TB of a file for Deduplication on ReFS." Reference comment by Dave Kawula

[Regnor]

Hi DaStivi,

We will have experimental support for it in Update 4, by using a registry key to enable this functionality. Those details will included in the What's New document.

Thanks!

What does experimental stand for?
Supported and stable, or unstable and don't use it?

[gpomanti]

That would be awesome if 2019 supported up to 4 TB for a file for dedup. I'm curious if I enabled dedup on my backup repository, does it cause issues with files over 1 TB (or 4 TB) or does dedup just skip files that are that big? I don't particularly care if it skips those files, but I'm missing out on a lot of space savings for files under that size and it would be nice to enable dedup if possible. I can't seem to find a clear answer on this anywhere.

[foggy]

Yes, Windows Deduplication skips larger files.

[gpomanti]

Great, thanks! So just one last question then for clarification, I can enable dedup on the Windows volumes without doing anything other than the defaults? There is no special configuration needed for dedup to skip the large files?

[gpomanti]

Oh, and this would be for Windows 2016 and NTFS. Still not comfortable with ReFS and dedup combined or 2019...

[Regnor]

What does experimental stand for?
Supported and stable, or unstable and don't use it?

May I quote my own question?

[DonZoomik]

Yes, Windows Deduplication skips larger files.

Larger files are not skipped. Files are processed up to 4TB limit. For example, if you have a 6TB file, first 4TB will be deduplicated and the rest will be left as-is. So it's not so bad.

[Mike Resseler]

Hi Regnor,

Experimental in this case means that is has gone through testing (and a lot of testing) but it hasn't been deployed in many production environments. While we did a lot of testing on it, the technology is still rather new and we don't have every existing configuration in the world .

[Mike Resseler]

Hey @gpomanti

@DomZoomik is correct. Files will be done until the 4TB and left for the rest as is. Also, the default setting after enabling is not ideal. You should change the usage type to backup when you want to store backups.

[DonZoomik]

Maybe someone who has already tried, can post their results? I haven't updated any of my Veeam servers to WS2019 yet but I'm planning to.
If I understand correctly, this new Dataport API should allow fast merges with deduplication enabled. Maybe not as fast as with non-dedupe ReFS but somewhere in between? Sounds like the both of both worlds (fast merges from ReFS and space savings from NTFS without NTFS buffer space required).

[DonZoomik]

I'd like to ask about an edge case.
For example I have a 10TB VBK full backup.
First 4TB will be deduplicated and during synthetic full (or merge) cloned with Dataport API.

Will the rest of the file still be block cloned (using basic ReFS functionality) during synthetic full? My concern is that the following 6TB might be skipped from ReFS processing resulting in significant wasted space, if it wasn't cloned.

[Mike Resseler]

Hey DonZoomik,

I don't believe this can be the case. The block cloning API we use will look at the full backup and the different incrementals (no matter how much there are). It will "compose" the new synthetic full by creating pointers to the different blocks it need. X amount from the full, a couple from the first incremental and so on... But they are just pointers. So no matter if these blocks are deduplicated or not, it is just a pointer to "somewhere"

Makes sense?

[DonZoomik]

I guess.
I thought this new "Dataport API" for deduplication was used somehow but after looking over it again, it seems to have different usage scenarios.
I guesst I'm just overthinking the issue and regular ReFS Block Clone API works transparently on deduplicated data.

[Paxx]

Is it supported now with Veeam Backup & Replication v.10?

[foggy]

It is still the same level of support from our side. Please see another existing thread for more details on this matter.