Recovering the Veeam Backup Server Itself -- Configuration Backup and Full Recovery from Scratch
Most Veeam environments have a solid plan for recovering every VM in the infrastructure. Almost none of them have a tested, documented plan for recovering Veeam itself. The backup server is the one thing that has to come back first before anything else can be restored, which makes it the single most consequential failure point in the entire protection architecture. This article covers how to protect VBR correctly using the built-in configuration backup, why encrypting that backup is not optional, where to store it so it actually survives the failure you are trying to recover from, and the complete procedure for rebuilding VBR from scratch.
Why You Should Not Back Up VBR with a Regular Backup Job
The natural instinct is to add the VBR server to a backup job the way you would any other VM. It is a Windows server, it runs on a hypervisor, Veeam can back it up. The problem is that Veeam explicitly recommends against this, and there is a specific technical reason documented in Veeam KB2645.
When Veeam creates a VM snapshot as part of a backup job, the VM pauses briefly during snapshot creation and commit. For most VMs that pause is harmless. For the VBR server, it causes the VBR service to disconnect from the configuration database and from remote Veeam components during that pause. When the snapshot commits and the server resumes, those connections have to re-establish. In a busy environment this produces job failures, proxy disconnections, and repository access errors that look like infrastructure problems when the real cause is just the backup of VBR itself running at the wrong moment.
The correct approach is Veeam's built-in configuration backup, which exports the configuration to a BCO archive file. No snapshots, no service interruptions, no side effects.
What the Configuration Backup Contains
An encrypted configuration backup captures everything Veeam needs to rebuild its operational state, including things people do not realize are in there until they need them:
Infrastructure inventory: every vCenter, Hyper-V cluster, Nutanix cluster, backup proxy, backup repository, WAN accelerator, virtual lab, and tape device added to VBR.
Job definitions: every backup job, backup copy job, replication job, and CDP policy with all settings, schedules, and VM selections.
Backup and replica metadata: the records VBR uses to know which restore points exist and where they are stored, so a restored VBR server can immediately see and work with existing backup chains.
Credentials: all accounts stored in the Credentials Manager, so you do not have to re-enter passwords for every proxy, host, and repository after a restore.
Encryption keys: the keys VBR uses to access encrypted backup data.
Session history: job run history and session logs.
This is the most important thing in this article. An unencrypted configuration backup does not store credentials, encryption keys, or certificates. Veeam explicitly states that if the configuration backup is unencrypted, credentials and encryption keys will not be included, and access to encrypted backup data will be unavailable after a configuration restore. In other words, an unencrypted config backup restores your job definitions but leaves you unable to connect to your infrastructure or decrypt your backup data.
An encrypted configuration backup stores all of it. If you have created any passwords in the Password Manager, Veeam will actually disable configuration backup entirely until you enable encryption. Always encrypt the configuration backup. Store the password for the config backup encryption in a password manager or secrets vault that is accessible without VBR.
Configuring Configuration Backup
- 1In the VBR console, go to Main Menu > Configuration Backup.
- 2Check Enable configuration backup to the following repository.
- 3Select a target repository. This decision is covered in detail in the next section.
- 4Set restore points to keep. The default is 10. Keeping 7 to 14 gives you enough history to roll back a configuration change that caused problems without wasting storage.
- 5Set the schedule to daily. Configuration changes happen more often than people realize: new VMs added to jobs, retention policies adjusted, credentials rotated. A weekly config backup can be missing significant changes at exactly the wrong moment.
- 6Enable Encrypt configuration backup and set a strong password. This is not a nice-to-have. As explained above, without encryption the backup does not contain credentials or encryption keys.
- 7Click Save, then run the job manually once to confirm the BCO file appears in the target repository and the job completes without errors.
Configuration backup settings. Encryption is required for the backup to include credentials and encryption keys.
Where to Store the Configuration Backup
Veeam defaults to storing the configuration backup on the default backup repository. That default is wrong for recovery purposes, and Veeam's own documentation says so. If the VBR server fails and the backup repository lives on the same server or in the same failure domain, the configuration backup fails alongside the thing it is supposed to help you recover.
The configuration backup must live somewhere that survives whatever takes down the VBR server:
A separate backup repository on different hardware. A standalone Windows or Linux repository server, a NAS device, or a remote network share. Physical separation from the VBR server is what matters.
A Veeam Cloud Connect repository. If you use a cloud provider or MSP with a Cloud Connect endpoint, their repository is an excellent config backup target. It is completely independent of your local infrastructure, offsite, and accessible over the internet from any machine you reinstall VBR on.
A network share on a different server. Simple, reliable, and works. A UNC path to a share hosted on a different machine is a legitimate target.
Even if the config backup repository is on a separate server, consider also copying the BCO file to a location outside your primary datacenter. The file is small (typically a few hundred megabytes) and contains everything you need to rebuild VBR from scratch. A copy in cloud object storage, on a remote repository, or even on an encrypted USB drive at a physically separate location costs almost nothing and covers the scenario where a site-level failure takes both VBR and its config backup repository simultaneously.
Recovering VBR from Scratch
The procedure assumes the VBR server is gone and you are starting from a bare server or fresh VM. The configuration backup is available at a location accessible from the new server.
- 1Provision the new server. Build a Windows server with equivalent specs to the original. The same hostname simplifies reconnecting components that reference VBR by name, but it is not required.
- 2Install the same version of VBR. The version must match what created the configuration backup. Check the Veeam downloads page for the specific installer. Installing a different version can cause compatibility issues during configuration restore.
- 3Do not configure anything. After installation, do not add any infrastructure, create any jobs, or change any settings. The configuration restore will overwrite anything you do here. Open the VBR console and go straight to the next step.
- 4Launch the Configuration Restore wizard. Go to Main Menu > Configuration Restore.
- 5Browse to the BCO file. Point the wizard at the repository or file path where the config backup lives. If the repository is not yet added to the fresh VBR server, you can browse directly to the file path. Click Analyze to validate the backup file.
- 6Enter the encryption password. If the config backup is encrypted (which it should be), the wizard will prompt for the password at this step. This is why you documented it somewhere accessible without VBR.
- 7Choose Migrate mode. Migrate mode restores all configuration data to the new server. Restore mode is for rolling back the configuration database on the same server to a prior state. For a full recovery to new hardware, Migrate is correct.
- 8Review and restore. The wizard shows what will be restored. Confirm and click Restore. VBR restores the configuration database and restarts the VBR service.
- 9Verify infrastructure connectivity. Open Backup Infrastructure and confirm that hosts, repositories, and proxies are showing as connected. Some components may need credential re-entry if service account passwords changed, or if the new server has a different name that requires certificate re-trust.
- 10Rescan repositories. Right-click each repository and select Rescan. After the rescan, existing restore points should appear under Home > Backups and be fully usable.
If your VBR server runs on Linux, there is no GUI wizard for configuration restore. The restore is initiated by running the configuration restore component from the command line under the root account, using an answer file that specifies the backup location and restore options. Alternatively, if you have Veeam Host Management available, you can initiate the restore through that interface. The Veeam documentation for Linux VBR covers both methods in detail. The key point is that the GUI wizard is Windows-only.
Test This Before You Need It
The configuration backup and restore process has enough moving parts that you should test it in a non-production environment at least once before a real failure forces you to figure it out under pressure. You do not need to destroy your production VBR server to do this. Spin up a test VM, install VBR on it, point the Configuration Restore wizard at your config backup, and verify the restore completes and your infrastructure shows up. This exercise will tell you whether your BCO file is accessible from a fresh server, whether the encryption password works, and whether the restored configuration can actually connect to your infrastructure.
Run this test when you first set up configuration backup, again after any major VBR upgrade, and after significant infrastructure changes. It takes about 30 minutes and it is the only way to know with confidence that your recovery plan actually works.
What You've Completed
- Understood why backing up VBR with a regular backup job is explicitly not recommended: VM snapshots cause VBR service disconnections from the configuration database and remote components during creation and commit.
- Enabled configuration backup with encryption on a daily schedule to a repository that is physically separate from the VBR server. Encryption is required for the config backup to include credentials and encryption keys. Without it, you cannot connect to your infrastructure or access encrypted backup data after a restore.
- Understood what the encrypted config backup contains: all infrastructure, job definitions, backup metadata, credentials, and encryption keys. The password for the config backup encryption itself must be stored somewhere accessible without VBR.
- Recovered VBR from scratch: install same version, run Configuration Restore in Migrate mode, enter encryption password, verify infrastructure connectivity, rescan repositories.
- Noted that Linux VBR recovery uses a command-line answer file or Veeam Host Management rather than the GUI wizard.
- Scheduled a test recovery in a non-production environment to validate the full procedure and confirm the config backup is actually accessible and usable before a real event requires it.