https://login.veeam.com/en/oauth?client_id=nXojRrypJ8&redirect_uri=https%3A%2F%2Fwww.veeam.com%2Fservices%2Fauthentication%2Fredirect_url&response_type=code&scope=profile&state=eyJmaW5hbFJlZGlyZWN0TG9jYXRpb24iOiJodHRwczovL3d3dy52ZWVhbS5jb20va2IyNzc2IiwiaGFzaCI6IjE1NWZjZjZjLTQyNjQtNGRjYi1hNjVjLWY3NmNjYzQ1NzBiYyJ9
1-800-691-1991 | 9am - 8pm ET
EN

‘The revision level is unknown’ upon Guest OS File restore

Challenge

A Backup contains a VM with Windows 2016 (or 2019) as the GuestOS and Deduplication is enabled for some (or all) of the drives. The Backup completes without Warnings or Errors, but when performing a Windows File Level Restore, you receive the following message:

Failed to transfer C:\VeeamFLR\VMName_index\Volume#\filename. The revision level is unknown.

Clicking ‘Continue’ skips the file.

User-added image

If you navigate to C:\VeeamFLR and the locate the same volume, the file will be seen, but it won’t be restorable, producing the error: Error 0x80070519: The revision level is unknown.

User-added image

Cause

As part of the File Level Restore workflow, disks of the VM are first mounted from the backup file to the machine on which the Veeam Console was used to start the restore process. If the "Copy to..." restore method is used the files are copied to the selected location from the mounted filesystem on the server where the Veeam Backup & Replication Console is running. However if the "Restore>Overwrite" or "Restore>Keep" restore options are selected an additional mount point is created on the Mount Server associated with the Backup Repository where the backup files are located. (This is why a possible related issue could be seen where "Copy to..." works but "Restore>Overwrite" fails.)

Both the machine where the Veeam Backup & Replication Console launched and repository Mount Server need to understand deduplication volumes format of the server that was backed up in order to perform the restore successfully. This means that the OS and Deduplication feature sets of the server that is backed up and the servers where the backup is being mounted must match. If the server that was backed up was running Server 2019 with Deduplication enabled, so too must the server where the Veeam Backup & Replication Console is launched, and depending on the restore option used the repository Mount server as well. 
 

Solution

If possible upgrade the OS of the Veeam Backup & Replication server and Mount server to one that matches or is newer than that of the OS that is contained in the backups, and then enable the Deduplication features.

As a workaround, the Veeam Backup & Replication console and the repositroy Mount server can be installed on a separate server which is running the compatible OS and feature set. This will allow the Veeam Backup & Replication server OS to remain unchanged.

To workaround this issue, please do the following:

  1. Install remote Veeam Backup & Replication Console on the same or newer OS with deduplication feature enabled:
    https://helpcenter.veeam.com/docs/backup/vsphere/install_console.html

  2. Change mount server for the repository where the backups are stored to a server running the same or newer OS with deduplication enabled:
    https://helpcenter.veeam.com/docs/backup/vsphere/repository_mount_server.html

After making these changes, restores should be successful.
 

KB ID:
2776
Product:
Veeam Backup & Replication 10, Veeam Backup & Replication 9.5, Veeam Backup & Replication 9.0
Published:
2018-09-26
Last Modified:
2020-12-30
Please rate how helpful this article was to you:
5 out of 5 based on 1 ratings
Thank you for helping us improve!
An error occurred during voting. Please try again later.

Couldn't find what you were looking for?

Below you can submit an idea for a new knowledge base article.
Report a typo on this page:

Please select a spelling error or a typo on this page with your mouse and press CTRL + Enter to report this mistake to us. Thank you!

Spelling error in text

Knowledge base content request
By submitting, you agree that your personal data will be managed by Veeam in accordance with the Privacy Policy.

ty icon

Thank you!

We have received your request and our team will reach out to you shortly.

OK

error icon

Oops! Something went wrong.

Please go back try again later.