Azure Backup Passphrase lost

Hello Viknaraj Manogararajah

Could you please share us the below details?

1. Is the original disk from the corrupted server still accessible?
   Even though the OS was reinstalled, can the old disk be mounted or attached to another machine to recover files?
2. Is the OnlineBackup.KEK file available? Can you check if the file exists in the MARS agent scratch folder (C:\Program Files\Microsoft Azure Recovery Services Agent\Scratch) on the original or recovered disk?
3. Was the passphrase saved anywhere else? For example, in a password manager, shared drive, documented in any internal IT records, or emailed to anyone during the initial MARS agent setup?
4. Was the passphrase stored in Azure Key Vault? Did you configure the MARS agent to save the passphrase to Azure Key Vault at any point?
5. Is Enhanced Security enabled on the Recovery Services Vault? This will determine the registration flow if the KEK file workaround is attempted.

The Azure Backup encryption passphrase is not stored in Azure, it exists only on the on-premises server. Microsoft does not have any copy of the passphrase or the encryption key, so it cannot be retrieved from Azure.

However, before considering the data unrecoverable, please check if the original disk from the corrupted server is still accessible (even if the OS was reinstalled).

If so, please look for the OnlineBackup.KEK file in the MARS agent scratch folder, typically located at C:\Program Files\Microsoft Azure Recovery Services Agent\Scratch.

Additionally, check if the DPAPI encryption key folders are intact under %USERPROFILE%\AppData\Roaming\Microsoft\Crypto and Protect or under C:\Windows\System32\Microsoft.

If the OnlineBackup.KEK file is recoverable, there is a possible workaround:

1. Set up a new machine with the same FQDN as the original server.
2. Install the MARS agent and place the recovered OnlineBackup.KEK file in the scratch folder.
3. Register the server to the vault.
4. Once a new passphrase is set, you can perform a restore from the existing backup data.

If the OnlineBackup.KEK file is not recoverable and the passphrase is also lost, unfortunately there is no way to decrypt or restore the backup data, as it is encrypted with AES-256 encryption.

To avoid this situation going forward, we strongly recommend saving the MARS agent passphrase securely in Azure Key Vault.

You can refer to this documentation for setup: Save and manage MARS agent passphrase securely in Azure Key Vault.

Thanks,

Suchitra.

Nope - for Azure Backup using the Microsoft Azure Recovery Services (MARS) agent, the encryption passphrase is never uploaded to Azure and Microsoft cannot retrieve or reset it. The passphrase is generated and stored only locally unless you explicitly backed it up elsewhere. The backup data in the Recovery Services vault is encrypted with a key derived from that passphrase. Without the original passphrase, the recovery points in Azure are effectively unrecoverable.

Your recovery options are limited to finding an existing copy of the passphrase or recovering it from remnants of the original system. Typical places to check include exported .txt passphrase files, password managers, documentation systems, administrator notes, backup software repositories, secure shares, USB exports, or printed records. If the failed server disks still exist, you may also attempt forensic recovery from the old OS volume or from system state backups.

If the original server is partially recoverable, you can also look for the MARS agent configuration and credential remnants. You might want to check:

C:\Program Files\Microsoft Azure Recovery Services Agent\
C:\Program Files\Microsoft Azure Backup Server\
C:\Windows\System32\Config\

However, the actual passphrase is not stored in plaintext by Azure Backup, and there is no supported method to extract or decrypt it from Azure itself. So unfortuantely, if no copy of the passphrase exists, the data stored in the Azure Recovery Services vault cannot be restored.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin