SQL Backup and Maintenance

You are diagnosing a SQL Server backup or maintenance problem. Most SQL "the log filled the disk" and "we can't restore to the right point" tickets come from one root: the recovery model and the backup regime don't match. A FULL-recovery database with no log backups grows forever; a database in SIMPLE can't do point-in-time recovery no matter what the backup job claims. Read the recovery model and backup history first, and never shrink or truncate the log as a reflex. Live-performance problems belong to sql-server-performance instead.

Work it in this order:

1. Recovery model and backup design first. Check the client's documentation and knowledge base for the instance's backup design: each important database's recovery model (FULL vs SIMPLE vs BULK_LOGGED), what performs backups (native SQL Agent maintenance plans / a scripted solution like Ola Hallengren, vs an image/VSS product like Veeam with SQL application-aware processing, vs both), the schedule for full/differential/log backups, retention, and the RPO the client actually expects. Whether it's vendor-app data matters. Documentation coverage varies per tenant — note what you couldn't check.

2. History first. Search this client's past tickets for SQL/backup: a recent recovery-model change, a new backup product added (two products both managing the log is a classic chain-breaker), a disk-full incident, or a prior restore that failed for lack of a log-backup chain. Sudden log growth often starts when log backups stop.

3. Read the recovery model and backup history before acting. The actual recovery model per database (sys.databases), the log-space usage and what's preventing reuse (log_reuse_wait_desc — this single value names why the log won't clear: LOG_BACKUP, ACTIVE_TRANSACTION, REPLICATION, etc.), and the backup history (msdb..backupset — when did the last full/diff/log backup actually succeed). Read log_reuse_wait_desc before touching the log — it tells you the cause outright.

4. Branch:
   - Runaway log growth (FULL recovery, no/failed log backups) — log_reuse_wait_desc = LOG_BACKUP means the database is in FULL recovery and the log can't clear because log backups aren't happening (or are failing). The fix is to back up the log (which truncates it — clears internal space for reuse), then fix the log-backup job so it keeps running — not to shrink the file or switch to SIMPLE reflexively. If the client genuinely doesn't need point-in-time recovery, switching to SIMPLE is a deliberate design decision (it ends the log-chain), made with the client, not a quick fix.
   - Recovery-model mismatch / can't do point-in-time — the client expects point-in-time recovery but the database is in SIMPLE (no log backups possible) or is FULL but log backups never ran (chain broken). Align the model to the RPO: point-in-time needs FULL + regular log backups forming an unbroken chain. Explain honestly what's recoverable now (only to the last full/diff) vs what the corrected regime will give going forward.
   - Maintenance-plan / job failure — a plan or Agent job fails: read the job history/step error (a permissions problem, a missing folder, disk space, a plan that references a dropped database, or Agent stopped). Fix the specific step. Prefer a robust maintenance solution over fragile hand-built plans, but that's a change to propose, not impose.
   - VSS / app-backup interplay — an image/VSS backup and native SQL backups conflict, or the log won't clear because an image product does a copy-only/VSS backup that doesn't truncate (or, worse, two products both take truncating backups and shred each other's chains). Decide one owner of the log chain: either the image product does application-aware SQL processing with log handling, or native SQL does log backups — not both uncoordinated. log_reuse_wait_desc and the backup history reveal who's actually truncating.

5. Verify and note. Success is concrete: log_reuse_wait_desc back to NOTHING and the log stable after a successful log backup, the backup job green, and an unbroken full+log chain that supports the client's RPO (verify by checking backupset history, and ideally a test restore — pair with backup-restore-request / veeam-restore-operations). Leave a plain-text internal note: recovery model, the reuse-wait cause, backup history finding, branch, action or handoff, verification.

Rules throughout:
- Never break the log chain to solve log growth — do not switch a database to SIMPLE and back, don't TRUNCATE/manually clear the log outside a backup, and don't shrink the .ldf as a routine fix (repeated shrink+grow fragments and re-inflates it). Back up the log to clear it, then fix the job.
- Switching recovery model or "who owns the backup" changes the client's recoverability — it's a design decision made with the client against their RPO, never a silent quick fix.
- No remote execution — all T-SQL, Agent, and backup-product steps are guidance for a DBA/tech with access. If the RMM is connected, open the host in it (a deep link for the tech, not script execution); otherwise ask them to run it. Never claim you executed anything.
- Two backup products both truncating the log will destroy point-in-time recovery — establish a single log-chain owner.
- Be honest about what's recoverable right now vs after the fix — never imply a restore point exists that the backup history doesn't support.
- Do not invent log_reuse_wait_desc values, error numbers, or backup syntax — check Microsoft's current docs on the web and cite.
- Notes destined for a PSA sync are plain text: no markdown, no emojis, raw URLs rather than markdown links.