Restore Windows 2019 guest file dedup

[sandeweg]

Hi guys,

The answer should be somewhere but I can't find it. I have a single B&R server on a Windows 2016 server v1607. The repository is on a ReFS volume at the same server and the deduplication feature is installed.
When I restore guest files to a Windows 2012R2 server with dedup active there is no issue. But when I try to restore guest files to a Windows 2019 server with dedup, I got the warning code 1305, The revision level is unknown.

Is it possible to restore single files from my current server or do I need to upgrade the Windows to 2019 to get it working?

Thanks for your answers in advance!

[Egor Yakovlev]

Hi Sven,
to restore files from a Windows-deduplicated guest volume, Mount Server should be of equal or higher edition. So you have 2 options:
- upgrade Veeam server to Windows Server 2019 (default mount server)
- run File Level Restore from remote Veeam standalone console installed on a Windows 2019 machine
/Cheers!

[sandeweg]

Hi Egor,

Many thanks for the quick reply! I gonna try the second option first.

[Niksavoy]

Hi Sven,
to restore files from a Windows-deduplicated guest volume, Mount Server should be of equal or higher edition. So you have 2 options:
- upgrade Veeam server to Windows Server 2019 (default mount server)
- run File Level Restore from remote Veeam standalone console installed on a Windows 2019 machine
/Cheers!

Hi there.
I have a similar case and I have already tried everything ....
I want to do a File Level Restore from a backup of Win2019 with 2 disks C: and F:
I have activated deduplication of F:

After starting the FLR task, the explorer shows only disk C: disk F: IS MISSING !!!

I have the same result if I start FLR from backup or replication

I tried a new Win2019 with enabled deduplication as a mount server, as a repository - no result

I tried Veeam Console from the same Win2019 - no result
I made a brand new backup on the same Win2019 - no result

Apart from Ticket, any other suggestions?

[Gostev]

No other suggestions. To be clear, it is only the mount server that should have the deduplication feature enabled for FLR from such volumes to work, but you already tried that.

[Mildur]

It may be a stupid question from me.
If your win2019 server is a vm, is this drive F a virtual disk on the hypervisor and not an iscsi connected disk?
And you are sure, that it is not excluded in the backup job?

When I‘m doing backups of disks with deduplication, they show up in the Veeam FLR explorer, but they are empty because they are not readable without the deduplication feature on the mount server. If I remember this correctly. I would need to test this in my lab next week to be sure.

[Niksavoy]

Yep the win2019 it`s a VM on Vmware 6.7 U2 and i double check :
- all disks are Dependand
- all disks are Thin provisioned
- Not excluded by the veeam job ( i see the actual data size ), i`v made new jobs ....
- if i start FULL job it shows that second disk F: is processed in the details , and i get stats by the size read / processed / compressed e.t.c.
BUT ..... FLR job does not show it ...

[Mildur]

Thanks, then the best way to get it solved is a support case.

[Niksavoy]

All right
It's been a long time since the last update, but better late than never:

well there is no short version:
We raised a ticket # 05213790
The engineer from Veeam support joined the session
At the end of the session we did Instant Recovery on the productive machine from an up-to-date backup
It also started with a missing F: disk
Then we actually realized that the productive machine has some hidden problem
And we don't have any valid points - no replica, no backup, no backup copy from which to restore it if necessary
After the session, the Veeam support engineer said it would escalate
We decided that we needed to act immediately to have at least one more copy of the working machine.
Logically we decided to make Vmware VM Clone on running VM
a few minutes later the cloning of Vmware returned an error with VM quessinc and a few minutes later the productive machine crashed and the shares and also
After logging in to the machine we found that the second data disk is RAW format

After 15 years of experience with Virtualization, this is the first such case I come across.

After a lot of effort I finally managed to restore a valid backup - copy but from 70 days ago in which disk F: read

With a lot more effort, I was able to recover 300GB of data from drive F: 15 minutes before the productive machine crashed
thanks to GetDataBack - Portable 4 Mb

We compared the two virtual disks and synchronized the data.
Fortunately, data loss was minimal.

Conclusions:

The engineer from Veeam support found many logs for disk problems at the OS level - many IO latencies and VSS errors, the latter coincided with the time of the crash
According to them, it broke down 3-4 months ago, according to the logs
We finished the case with Feature Request
It turned out that Veeam can check the format of the virtual disk at the OS level (fat 32, NTFS, ReFS or RAW) but only if it restores .......
Well, you could think about how to compare it with the previous task and check that there is a difference and raise a simple alarm "Well, check your machine" ..... or in VeeamONE another Warring alarm!
Naturally, we are already doing tests with Surebackup tasks
But the disappointment remains that we have relied on the green statuses of the software!