Issues with 13.1

[DaStivi]

I've just updated to 13.1 and immediately noticed two issues after the upgrade and running a backup job.
First, the VBR server itself can no longer be backed up. This worked perfectly fine on 13.0.x, but after upgrading to 13.1 I now receive the following error when the VM is being processed:

Processing SERVERNAME Error: Source data for task SERVERNAME is missing.
Error: Source data for task SERVERNAME is missing.

I've double-checked the backup job configuration and nothing has changed.
Additionally, I tried running a Quick Backup of the VBR server, which exposed a second issue: during the Quick Backup process, all other VMs displayed the message:

"XXXX is outdated and its restore points will be subjected to deleted VMs retention."

This is unexpected, as all of those VMs are still selected and protected by the regular backup job.

I'll generate support logs and open a support case shortly. In the meantime I've to update some other VBR Servers...

Edit / Additional Context:

The backup job is using Storage Integration.

For troubleshooting purposes, I created a separate backup job for the VBR server. I know some would argue that's a best practice anyway, but the server had been backed up successfully as part of the existing job before the upgrade.

Interestingly, after creating a dedicated job for the VBR server with Storage Integration disabled, the backup completed successfully.

This seems to indicate that the issue may be related to Storage Integration in combination with VBR 13.1. I'll perform some additional testing with Storage Integration enabled on the dedicated job and report back with my findings.

[Mildur]

Hi Stephan,

V13.1 follows the same process as any of our releases. Please provide a case number if you are facing a technical issue.
You may bring the issue up in our forum, but please wait for a conclusion from our Support team.

Please provide a support case ID for this issue, as requested when you click New Topic. Without a case number, the topic will eventually be deleted by moderators.

Best regards,
Fabian

PS: Support can only help if you upload logs: https://www.veeam.com/kb1832

[Mildur]

PS: Keep in mind, protecting the backup server with backup jobs is not recommended: https://www.veeam.com/kb2645

Best,
Fabian

[DaStivi]

I've tested now my dedicated backup job with storage integration enabled, and it fails too!
created a case: 08179717

[Dima P.]

Thank you for the case, investigating!

[DaStivi]

I would really appreciate seeing this positioned as a "not recommended" scenario rather than a "not supported" one.

Backing up the VBR server VM has worked reliably for years in many environments. Veeam itself is aware that the VM hosts the Backup & Replication server, as evidenced by behaviors such as the "no parallel processing" warning and other safeguards. Given that awareness, why not allow the backup while clearly stating that it is not the preferred recovery method?

A Veeam Backup Server is much more than just a configuration database. Even with the software appliance, the appliance contains significantly more than the configuration data alone. In many situations, restoring an entire VM can be much faster and simpler than deploying a new appliance, recreating user accounts, configuring MFA, and then performing a configuration database restore.

[Dellirius]

I'm facing the same issue with not beeing able to backup the VBR Server (VM). Is there any update?

[Mildur]

No update. Using unsupported scenarios is a risk, since they may work or break with each product upgrade.
Our support team will only be able to fix or assist in supported scenarios.

Changing an unsupported situation into a supported scenario is a feature request.
However, we cannot make any promises or provide an ETA for when it might change.

Best,
Fabian

[Dellirius]

Hi Fabian

Thanks for the fast response. I will take care of the configuration backup so far.

Kind regards,
Fabian

[AndreSoftTech]

I'll tag along this request, casenumber: 08195999

Having the same issue, being unable to backup my backupserver since upgrading to 13.1 with storageintegration. Same error: Source data for task SERVERNAME is missing.

[david.domask]

Hi AndreSoftTech, welcome to the forums.

Thank you for sharing the case number, however as noted in this thread, backing up the backup server with itself is not supported. While it's understood it worked previously, it's unclear if there will be a full solution here as the scenario is not supported.

Please continue with Support on technical issues as noted in the Forum Rules; technical issues should only be posted after the conclusion to the case and if there are questions / requests based on the outcome of the investigation.

As Fabian (user Mildur) mentioned above, changing the support status of backing up the backup server with itself would be a feature request.

[j.mann]

Hi All,

We are experiencing the same issue after upgrading from Veeam Backup & Replication 13.0.2.29 to 13.1.0.411.
Our support case is #08195783. Veeam Support has confirmed that R&D is aware of the issue and is investigating it.

We fully understand that the supported recovery method for a VBR server is to reinstall it and restore the configuration backup, which is already part of our recovery strategy.

However, we still consider it important to protect the VBR VM itself. In addition to the Veeam components, the server contains backup-related scripts and customizations that are valuable to preserve. Prior to 13.1, this VM was successfully protected using storage snapshots.

As this functionality worked correctly in previous releases, we view the current behavior as a regression rather than a feature request and hope to see a product fix in a future update.

We will continue to monitor this thread for updates.

Best regards,
J.Mann

[david.domask]

Hi J.Mann, welcome to the forums.

Thank you for sharing the case number, though I'm afraid there seems to be a bit of confusion in the case on the issues & the workaround.

The issue that Support is describing is NOT about the backup server being backed up, but instead about Backup from Storage Snapshot (BfSS) processing changes in 13.1. In brief, when a VM that is scheduled for sequential processing is included in the job, the new processing model for BfSS in 13.1 results in this error.

So it's not exactly about backing up the backup server, but more a result of the special handling that is included for backing up the backup server (it's always done sequentially, meaning no other parallel processing)

Issue is targeted to be resolved in 13.2; Support's workaround will help, as will moving the backup server to a dedicated job as per our KB requirements.

[MVanek]

Hi All!
Just noticed another issue with 13.1. Not found anywhere so far. Apologize if its already mentioned somewhere

Just needed to perform Instant disk restore to powered on VM. Exact case was to keep VM running and connect new SCSI 0:X disk.
During Instant Disk Recovery at the step Disk Mapping - when you select disks you need to restore and specify SCSI 0:4 in my case, which was free unoccupied slot. GUI confirms disk will be added to VM, not replaced.
When you click next - Veeam tells you warning that "VM xxx will be powered off for the duration of restore.
Proceed with restore?" - Of course not..
When I tried to proceed, instant recovery is performed correct way WITHOUT powering VM off.

Tried this in multiple 13.1 installations. All the same.
VBR servers with 13.0 or 12.3 are good.

Not sure if its just something I do not get at all, but from my perspective its kinda scary.