No, Database Vault does not support creating database backups from a remote SQL Server system. This is due to Database Vault using Microsoft's SMO library to create database backups which requires access to the local file system that the SQL Server instance is running on.

The limitation exists because SMO performs backup operations in the security context and file system environment of the target SQL Server. Remote initiation from a separate machine introduces path resolution failures, permission boundaries, and network dependencies that the current implementation does not bridge. This design maintains reliability and reduces attack surface for backup processes running under SQL service accounts.

#Technical Reason Behind the Limitation

Microsoft's Server Management Objects (SMO) is a managed .NET library that provides programmatic access to SQL Server administration tasks. The Backup and Restore classes within SMO connect to the database engine, read from its data files, and write backup streams directly to specified devices. These devices are almost always file paths on the local server disks because the SQL Server service account must have NTFS permissions to those locations. Executing this from a remote client without additional proxy services or UNC paths that the server can resolve leads to immediate failures.

Database Vault leverages SMO for its backup features to ensure consistency with SQL Server's native capabilities. When the SQL Server instance is not local to the system where Database Vault executes the SMO code, it cannot satisfy the file I/O requirements. This is not a bug but an architectural constraint tied to how SQL Server exposes backup functionality.

#SMO Backup Code Example

csharp 
using Microsoft.SqlServer.Management.Smo;
using Microsoft.SqlServer.Management.Common;

Server server = new Server("sql-instance");
Backup backup = new Backup();
backup.Database = "YourDatabaseName";
backup.Devices.AddDevice(@"D:\Backups\YourDatabaseName.bak", DeviceType.File);
backup.CompressionOption = BackupCompressionOptions.On;
backup.SqlBackup(server);

The example above illustrates a typical SMO backup in C#. The device path (D:\Backups\...) must be reachable from the SQL Server instance itself. When this code runs inside Database Vault against a remote SQL Server, the library cannot write to that path without the server having direct file system access, which is exactly why remote backup support is not available.

#Local vs Remote Backup Behavior

When the SQL Server instance shares its host with Database Vault or runs in a local configuration, the SMO calls succeed because the file system is directly accessible. Backups land on local volumes where permissions are pre-configured. For remote SQL Servers, the same calls fail with errors indicating inability to access the backup destination or connect to the required resources. Understanding this distinction lets administrators avoid wasted troubleshooting time on unsupported configurations.

#Alternatives for Remote SQL Server Backups

Since Database Vault cannot handle remote backups, use native SQL Server tools or scripts that run directly on or near the target server. These methods still produce standard .bak files that you can then copy to secondary storage.

  • Execute T-SQL BACKUP commands via SSMS, sqlcmd, or PowerShell Invoke-Sqlcmd connected to the remote instance, targeting a local path or approved UNC share.
  • Configure SQL Server Agent maintenance plans on the remote server itself to run scheduled full, differential, and transaction log backups.
  • Use Robocopy, AzCopy, or SFTP after the backup completes to move files from the server to long-term storage locations.
  • For automated remote management, deploy lightweight agents or scheduled tasks on the SQL Server that push backups to network storage you control.

#Common Pitfalls and How to Avoid Them

  • Specifying a client workstation path as the backup target instead of a server-local path, resulting in "access path denied" errors.
  • Running backups under accounts that lack sysadmin or backup operator permissions on the remote SQL instance.
  • Insufficient disk space on the SQL Server volume where the backup is written before any file transfer occurs.
  • Neglecting to verify backup integrity with RESTORE VERIFYONLY or actual test restores on a regular basis.

Always confirm the SQL Server service account has write access to the backup directory and that the directory exists prior to execution. Monitor the SQL error log and Agent history for detailed failure reasons when automating backups.

#Best Practices for Reliable SQL Backups

  • Combine full weekly backups with daily differential and hourly transaction log backups for databases larger than a few gigabytes.
  • Enable backup compression and verify checksums to reduce storage usage and detect corruption early.
  • Retain backups for at least 30 days and store copies offsite or in separate infrastructure from the production server.
  • Test restores in a non-production environment at least once per quarter to validate your recovery process.

Plan backup strategies around the local capabilities of Database Vault where possible. For remote SQL Servers, combine native engine tools with secure file transfer to achieve the same outcome without depending on unsupported remote functionality. This approach delivers consistent, testable data protection across your environment.