[Bug]: Linux backup path is incorrectly passed to remote Windows SQL Server

[billy-shang]

Hi,

I'm running DBackup in Docker on a Synology NAS and trying to back up a remote Microsoft SQL Server running on Windows.

My architecture is:

Synology NAS
└── Docker
└── DBackup
│
│ Direct MSSQL connection (TCP 1433)
▼
Windows Server
└── Microsoft SQL Server

The database connection works correctly.

However, when using the local file transfer mode with the default server backup path:

/var/opt/mssql/backup

SQL Server receives this Linux path and attempts to use it relative to its Windows backup directory, resulting in:

Cannot open backup device
'D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup/var/opt/mssql/backup/xxx.bak'

Operating system error 3
(The system cannot find the path specified.)

I understand from the documentation that MSSQL currently supports two file transfer modes:

Local/shared filesystem

SSH/SFTP

For a remote SQL Server running natively on Windows, neither option is ideal.

Would it be possible to support an SMB/UNC-based MSSQL file transfer workflow, for example:

DBackup (Linux/Docker)
│
│ BACKUP DATABASE
▼
Windows SQL Server
│
▼
\synology-nas\sql-backup\database.bak
│
▼
DBackup reads the .bak via SMB

This would make it possible to use DBackup on a Synology NAS or Linux Docker host to back up remote Windows SQL Server instances without requiring SSH on the Windows server.

Also, does DBackup currently support Windows-style server backup paths such as:

D:\SQLBackup

or UNC paths such as:

\192.168.0.10\SQLBackup

for the Backup Path (Server) setting?

My current SQL Server is SQL Server 2008 R2, which I understand is older than the versions currently listed as officially supported. However, this question also applies to supported SQL Server 2017/2019/2022 instances running natively on Windows.

Thanks!

[Skyfay]

Hey @billy-shang

Thank you for your detailed report.

First, a quick note: you're using a very old version of MSSQL. DBackup does not officially support this version. We support versions from 2017 onward.

That said, I think this issue is generally related to Windows machines. I'll look into it, but it might take a little longer since I need a Windows machine.

Thank you very much for your understanding.

[Skyfay]

Hi @billy-shang

Short version: this is not a version problem and not a missing SMB feature. It is the backup path.

Backup Path (Server) is handed to SQL Server exactly as you type it, straight into BACKUP DATABASE ... TO DISK. The default /var/opt/mssql/backup is a Linux path, and a Windows instance resolves it relative to its own backup directory, which is exactly the concatenation in your error. A 2017, 2019 or 2022 instance on Windows would fail the same way.

To your question: yes, both Windows forms are accepted. They are passed through unchanged, D:\SQLBackup as well as \\192.168.0.10\SQLBackup.

So for your architecture, staying on local file transfer:

1. Share a directory on the NAS and mount it into the DBackup container, for example at /mnt/sql-backup.
2. File Transfer Mode: local
3. Backup Path (Server): \\synology-nas\sql-backup, what SQL Server writes to
4. Local Backup Path: /mnt/sql-backup, what DBackup reads

Both fields point at the same directory from opposite sides. DBackup never speaks SMB itself, it reads the mount, so the workflow you sketched needs no new transfer mode.

One thing that will bite you with a UNC path: BACKUP DATABASE runs as the SQL Server service account, not as the login DBackup connects with. NT Service\MSSQLSERVER and Network Service have no identity on the network, so the write fails with operating system error 5 even when the share looks wide open. Either run the SQL Server service under a domain account with write access to the share, or grant the share and NTFS permissions to the computer account (DOMAIN\SERVERNAME$). Test it from SSMS on the server first, before configuring anything in DBackup:

BACKUP DATABASE [master] TO DISK = N'\\synology-nas\sql-backup\permission-test.bak' WITH INIT

On SSH mode: that is what it exists for, and it is the cleaner answer for a remote server. On the SQL Server host DBackup only uses SFTP and a port forward, never a remote shell command, so the OpenSSH server that Windows Server 2019 and newer offer as an optional feature should work with a path like D:/SQLBackup, and port 1433 would not need to be exposed at all. I have verified that in the code but not yet against a real Windows machine, so I am not going to document it as supported until I have. If you get a chance to try it, I would be very interested in the outcome.

Changing in the next release: restoring a database under a different name used to place the data and log files at a hardcoded Linux path, which could never work on Windows. That now uses the directories the instance itself reports. The backup path was already passed through correctly, so beyond the docs there was nothing to fix on that side. The SQL Server guide is getting a Windows section covering the path formats and the share setup.

On 2008 R2, it stays outside what we support, but I want to be clear that it is not the cause here. This failure is the path alone.

Does this answer help you?

[Skyfay]

Hey @billy-shang

Has this resolved the issue, or do you need further assistance?