Building a Backup Automation Framework with AI

Every DBA has backup scripts. Most of them started as a maintenance plan, got replaced with a handwritten T-SQL job, picked up a few IF branches over the years, and now live in that awkward space between “it works” and “I’m afraid to touch it.” The problem isn’t writing BACKUP DATABASE — it’s building a framework that handles multiple instances, different backup types on different schedules, verification, retention cleanup, and notification when something fails silently at 2 AM.

I decided to use AI to build this from scratch instead of patching my existing scripts one more time. Here’s the prompt I started with:

What the Agent Produced

The agent generated a solid three-part structure: a config schema, a main Invoke-DbaBackupFramework function, and a notification helper. The config file looked like this:

The backup type selection logic was clean — it checked the current day of week against the schedule, falling back to differential, then log. The RESTORE VERIFYONLY step used Test-DbaLastBackup from dbatools, which is exactly the right cmdlet.

Scheduling caveat: The "log": "*/15" pattern in the config file is not parsed by the Get-BackupType function — the function only checks the day of week for full and differential schedules, defaulting to log backup for any unmatched day. In production, log backup scheduling at a sub-day interval (e.g., every 15 minutes) should be handled by the task scheduler (Windows Task Scheduler or SQL Agent) that invokes this framework, not by the framework’s internal schedule logic. The */15 notation is shown as documentation of intent, not as executable configuration.

What needed fixing:

  • No copy-only support. In my environment, I regularly take copy-only backups for migrations or developer refreshes. These shouldn’t interfere with the differential chain, and the framework had no way to request one.
  • Retention cleanup was too aggressive. It deleted all .bak files older than N days, but didn’t distinguish between full and log backups. I need different retention periods — 14 days for full/diff, 3 days for log backups.
  • No -WhatIf parameter. For a framework that deletes files and sends emails, I need a dry-run mode before pointing it at production.

The Iteration

I followed up with two more prompts:

And then:

The agent handled both iterations well. The -WhatIf implementation used SupportsShouldProcess properly, and the retention split was straightforward.

The Final Framework

What I Validated

Before deploying this, I ran it with -WhatIf against a test instance to verify the schedule logic picked the right backup type on different days. I also confirmed a few things manually:

  1. The Verify parameter on Backup-DbaDatabase runs RESTORE VERIFYONLY automatically. No separate step needed — dbatools handles this internally. It’s a useful quick check, though not a substitute for actual test restores.
  2. Copy-only backups don’t reset the differential base. I took a copy-only full, then a scheduled differential, and confirmed the diff was based on the previous scheduled full — not the copy-only.
  3. Retention cleanup respects subdirectories. The -Recurse on Get-ChildItem walks \\share\instance\database\ correctly. Empty directories are left behind, which is fine — no need to over-engineer that.

The framework runs as a SQL Agent PowerShell job step or a scheduled task. For fleet-wide deployment, combine it with the Central Management Server pattern from Post 5 to generate config files per instance automatically.

Try This Yourself

Start small. Create a config file with a single test instance and run the framework with -WhatIf -Verbose to see what it would do. Then let it run against a dev instance with aggressive retention (2 days) so you can watch the cleanup work.

Once you’re comfortable, iterate with the agent. Ask it to add backup-to-URL support for Azure Blob Storage. Ask it to skip databases that are AG secondaries where sys.fn_hadr_backup_is_preferred_replica() returns 0. Ask it to generate a daily summary email showing total backup size across the fleet. Each iteration is a prompt and a few minutes of review — a lot faster than writing it from scratch.

The real value isn’t the initial framework — it’s how quickly you can customize it for your environment. The agent gives you the plumbing; you bring the knowledge of what your backup strategy actually needs.

For more on integrating PowerShell automation into your DBA workflow, see Post 6: PowerShell Automation.


Part of the ALTER DBA ADD AGENT series.