Backup Manager failed - Cant open File

Hello Florian,

Thank you for the detailed description, that helps a lot.

The behavior you are seeing is expected in your current setup, and it comes from how the DVLS Backup Manager coordinates the backup between the two hosts.

The Backup Manager runs the backup command on the SQL Server, which means the SQL Server service account is the one writing the .bak file, while the DVLS Scheduler (or Runner for a manual "Back Up Now") is the one that reads that file back to zip, encrypt and clean it up. For this to work, the destination path must be reachable and writable from both hosts by the accounts running those services, using exactly the same path string.

Two things in your current configuration make that impossible:

First, the U: drive. Mapped drive letters only exist inside the interactive session that created them, so the SQL Server service and the DVLS Scheduler service never see U:. That alone is enough to produce the "Can't open file" error.

Second, the SQL Server service account is Network Service, and there is no Active Directory. On the network, Network Service presents itself as the SQL host's computer account, which has no identity your DVLS host or a file share can authenticate. So any UNC path you provide will also fail for the SQL side.

To make Backup Manager work reliably in your environment, we recommend:

Choose a UNC path on a CIFS/SMB share reachable from both hosts, for example \\FILESERVER\DVLSBackup\. This replaces the U: mapping entirely.

Grant "Modify" on that share and on the underlying folder to every account involved: the SQL Server service account, the DVLS Scheduler service account, the DVLS Runner service account, and, if you use web backup, the IIS Application Pool identity.

Because there is no Active Directory, switch the SQL Server service account away from Network Service to a dedicated local Windows account that also exists, with the same username and password, on the machine that hosts the share. This is the standard workgroup pattern that gives SQL a network identity the file server can validate. Alternatively, host the share on the SQL Server itself and grant the two DVLS service accounts (again as mirrored local accounts) Modify permissions on that share.

Before re-enabling the schedule, run a manual write test as each service account from each host to the chosen UNC path, to confirm the "Can't open file" error is gone.

If restructuring the service identity is not possible right now, an interim workaround is to disable the DVLS Backup Manager and schedule the SQL backup directly on the SQL Server, either via a SQL Agent job or a Windows Task Scheduler task that runs sqlcmd BACKUP DATABASE locally, then archives the .bak elsewhere in a second step. That avoids the cross-machine handshake entirely.

Reference documentation:

Backup Manager: https://docs.devolutions.net/server/web-interface/administration/backup/backup-manager

If you can share the exact error text visible in the two screenshots you attached to the forum post, and confirm your DVLS version, I can validate all of the above against your specific build.

Best regards,