Problem Description
MS-SQL transaction log backups fail with the error code SQL6. This issue may manifest intermittently or after a period of successful backup cycles.
Traceback:
Phoenix SQL agent found no instance/database on the server to backup or the SQL service is not running or the backup content is set to exclude all databases.
Symptoms
Transaction Log backups fail consistently, while Full backups may occasionally succeed.
The error
Code: 4295163910is captured within themain_mssql_service.logs.Databases configured for Transaction Log backups are found to be using the Simple Recovery Model, or the log chain is actively being broken by an external process.
Cause
The primary cause of this error is a broken log chain. In an MS-SQL environment, only one backup process can maintain the log sequence number (LSN) chain. If an external process interrupts this sequence, Druva cannot perform incremental log backups until a new baseline is established.
Common triggers include:
Native SQL Maintenance Plans: Native full or differential backups running to local disks (e.g.,
.bakfiles) without the correct attributes.Missing COPY_ONLY Attribute: When native backups run alongside Druva, they must utilize the
COPY_ONLYflag. Without it, the LSN is reset, breaking the backup chain required by Druva.Recovery Model Mismatch: Databases set to the Simple Recovery Model do not support Transaction Log backups. Druva will skip these, potentially throwing "no database found to backup" errors if no other valid databases are selected in the backup set.
Traceback
From main_mssql_service.logs:
level=error ts=2026-02-11T19:17:51.5044119Z filename=commandhandler.go:617 layer=main message="Backup failed" Error="Error while DoBackup: Code: 4295163910 Original: Phoenix SQL agent Found no instance/database on the server to Backup/Restore or the SQL service is Not running or the Backup content is set to exclude all the databases. Message: Phoenix SQL agent Found no instance/database on the server to Backup/Restore or the SQL service is Not running or the Backup content is set to exclude all the databases."
Example of native backup conflict activity:
Database DTEST had native full backups written to: L:\SQL 2019 Backups\DTEST\DTEST_backup_2026_02_11_000002_4688772.bak on 02/11/2026 at 00:14:56
Resolution
Step 1: Identify External Interferences
Review the SQL Server Error Logs or Maintenance Plans to identify if other backup solutions (native SQL scripts, maintenance tasks, or third-party VSS tools) are running.
Check for Native Backups: Look for
.bakor.trnfiles generated in local or network directories.Audit LSN changes: Confirm if a native backup execution occurred between Druva’s scheduled log backups.
Step 2: Reconfigure Conflicting Native Jobs
If native backups must continue to run alongside Druva:
Modify the native backup scripts to include the
WITH COPY_ONLYcommand. This ensures the backup occurs without disrupting the LSN chain required by Druva.Alternative: Disable native SQL Maintenance Plans completely and utilize Druva as the primary data protection provider.
Step 3: Verify Database Recovery Models
Ensure that all target databases assigned to Transaction Log backups are utilizing Full or Bulk-Logged recovery models.
If a database is set to Simple mode, either change it to Full (if log backups are required) or modify the Druva backup policy to exclude it from the Transaction Log backup schedule.
Step 4: Reset the Log Chain
Once the conflicting jobs are disabled or corrected to copy-only:
Log into the Druva Console.
Trigger a Manual Full Backup for the affected SQL instance.
This action establishes a fresh LSN baseline. Monitor subsequent scheduled Transaction Log backups to confirm normal operations resume.