Skip to main content
  • EN

Requirement with Deduplication in windows where if you restore OS files it will not work and throws the error “The revision level is unknown”.  Seems to be with the mount server OS versus the backed up VM OS along with having the deduplication turned on.

Check this article for more information - KB2776: Guest OS File restore fails with ‘The revision level is unknown’ (veeam.com)

 

Thanks for sharing.
For me, that’s more a requirement as a bug.

It‘s the same for restoring data from a server with refs disks. For an example, A mount server with windows Server 2012 should never be able to mount a server 2019 backup, because the refs Drivers are to old.


We had this situation with a Exchange 2016 server with refs disks. The backup server was an old server 2012 back then. It wasn‘t able to read the content of the backup. No item level restore was possible from the console on the backup server. We had to add a new managed server with the same or higher level of the refs driver.

 

My personal recommendation, use a mount server on the same or higher os level as your production vms. Same for the sql staging server.

 

Thanks for sharing.
For me, that’s more a requirement as a bug.

It‘s the same for restoring data from a server with refs disks. For an example, A mount server with windows Server 2012 should never be able to mount a server 2019 backup, because the refs Drivers are to old.


We had this situation with a Exchange 2016 server with refs disks. The backup server was an old server 2012 back then. It wasn‘t able to read the content of the backup. No item level restore was possible from the console on the backup server. We had to add a new managed server with the same or higher level of the refs driver.

 

My personal recommendation, use a mount server on the same or higher os level as your production vms. Same for the sql staging server.

 

Yeah I will modify the post as a requirement versus bug.  Thanks for that.

Oh, this could be a bigger problem.

So, the Veeam mount server for a Windows repo with deduplication has to be at the newest Windows version….

As far as I understand the KB article this applies for file level restores only. Correct?

 

We will have to begin planning the update of our backup (mount) servers to Server 2022….

 

Edit:

Mhh, just read the other comments…. So, this is the same as with ReFS. Ok… Perhaps not that dramatic then….

 

 

Edit:

Mhh, just read the other comments…. So, this is the same as with ReFS. Ok… Perhaps not that dramatic then….

Veeam mounts the backup file with it‘s content under the following path:

C:\VeeamFLR

The Mount Server needs to understand the deduplication (version) or reFS version of the mounted disk from the vm/agent. If the mount server is to old, it cannot read the content.

For the reFS situation, you find the limitations in the guide:

https://helpcenter.veeam.com/docs/backup/vsphere/guest_restore_before_you_begin.html?ver=110

 

 

Ok, I was not clear enough.

The ReFS requirement was there since it exists and is supported by Veeam.

And it is rather logical this this applies to FLR, too.

I thought  at first sight of the KB that this is a new bug…

Thanks for sharing.
For me, that’s more a requirement as a bug.

It‘s the same for restoring data from a server with refs disks. For an example, A mount server with windows Server 2012 should never be able to mount a server 2019 backup, because the refs Drivers are to old.


We had this situation with a Exchange 2016 server with refs disks. The backup server was an old server 2012 back then. It wasn‘t able to read the content of the backup. No item level restore was possible from the console on the backup server. We had to add a new managed server with the same or higher level of the refs driver.

 

My personal recommendation, use a mount server on the same or higher os level as your production vms. Same for the sql staging server.

 

That’s a good personal reccomendation, I didn’t had yet a case with similar error, but nice to know a prior.

Thanks for sharing.
For me, that’s more a requirement as a bug.

It‘s the same for restoring data from a server with refs disks. For an example, A mount server with windows Server 2012 should never be able to mount a server 2019 backup, because the refs Drivers are to old.


We had this situation with a Exchange 2016 server with refs disks. The backup server was an old server 2012 back then. It wasn‘t able to read the content of the backup. No item level restore was possible from the console on the backup server. We had to add a new managed server with the same or higher level of the refs driver.

 

My personal recommendation, use a mount server on the same or higher os level as your production vms. Same for the sql staging server.

 

fully agree! completely logical that this can not work

Comment


Terms & Conditions