Skip to content

Azure Database Backup Strategy

VIDEO TRANSCRIPT | Recorded: 2025-03-19 | Verify against current system state

Abstract

Strategy discussion for transitioning Azure SQL database backups from Aptify-managed to Veeam-managed solution. Covers application-aware VM image backups that properly handle SQL transaction logs, multiple restoration methods (VM rollback, file-level, application-aware SQL restore), retention policies including 8-year annual retention for compliance, and staging server setup for granular database recovery.

Key Procedures

  • Configure Veeam application-aware backup for SQL VMs
  • Set up backup retention policies (daily, weekly, monthly, annual)
  • Install SQL Developer edition on Veeam server for staging
  • Use staging server for granular database browsing
  • Restore database files to original or alternate location
  • Roll back entire VM using Azure snapshots
  • Copy backups to off-site data center
  • Review daily backup status emails
  • Test disaster recovery scenarios annually

Notable Statements

  • 0:00:58 "Previously, Aptify was responsible for the database backup process"
  • 0:01:39 "Lee brought up a way to do it with... Veeam, which it's just a solution they're using for backups for VMs"
  • 0:02:30 "Currently... we are doing image backups of all the Azure machines, including the two SQL Servers"
  • 0:02:41 "You can do like an application specific recovery and actually pull the SQL database out of an image backup"
  • 0:02:54 "This method requires like a staging SQL Server"
  • 0:03:04 "It used to require SQL for its own database, but now they use Postgres"
  • 0:04:26 "I would probably prefer to get this SQL staging server set up... before we go to the plugin route"
  • 0:05:24 "You can't use SQL Express for a staging server. For your DBs, they're too big"
  • 0:06:87 "Scanned email is a shared account in 365 for using as mail relay"
  • 0:07:01 "When it does the image backup, it is application aware, so it will actually tell SQL that it's backed up and backup the transaction logs"
  • 0:07:36 "It's almost the equivalent of shutting the system down, taking it back up and turning it back on again"
  • 0:09:29 "I do want an annual and quarterly backups... I don't want those deleted"
  • 0:10:04 "I think we're required at least seven just with our policies" (years of retention)
  • 0:10:36 "Keep one daily backup for 14 days. Keep weekly backups for a month. Keep monthly backups for 12 months"
  • 0:11:43 "Some of these are immutable meaning if somebody goes in here and tries to delete them... it's not deletable"
  • 0:13:48 "The Veeam server itself is not domain joined. I did that intentionally just to isolate it"
  • 0:14:00 "In case there was some sort of bad actor that happened to get domain admin on your network"
  • 0:18:42 "We're getting 3 sets here... the Azure, the Veeam that's going to another storage blob and then completely off site"

Systems & Configurations

Systems Mentioned

  • Veeam (backup management)
  • Azure (VM hosting, blob storage, snapshots)
  • SQL Server (databases being backed up)
  • SQL Server Developer Edition (staging server)
  • Azure Blob Storage (backup storage)
  • Bestline Data Center (off-site backup copy)
  • OwnBackup (Salesforce backup comparison)
  • Microsoft 365 (mail relay for notifications)

Specific Configurations

Item Value/Setting Timestamp Notes
Daily backup retention 14 days 0:10:36 Immutable
Weekly backup retention 1 month 0:10:43 -
Monthly backup retention 12 months 0:10:48 -
Annual backup retention 8 years 0:10:58 Compliance requirement
Veeam server Not domain-joined 0:13:48 Security isolation
Staging SQL version Developer Edition 0:05:13 Not Express - DBs too large
Backup copies 3 locations 0:18:42 Azure, Veeam blob, off-site
Notification email scanned email account 0:06:87 M365 shared account

Credentials/Access Mentioned

  • Veeam server requires separate local logins (not domain)
  • Azure admin access: Jeff, Will, Hector
  • Backup access: Infrastructure team (Will, Lee)
  • Daily backup notification emails to IT team

Vendor Contacts Mentioned

  • Lee (infrastructure team member conducting Veeam configuration)
  • Will (infrastructure team member)
  • Hector (Azure admin)

Errors & Troubleshooting

  • Issue: Christina downloaded AdWare
  • Cause: User error (mentioned at start of meeting)
  • Resolution: Being handled separately by Will
  • Timestamp: 0:00:09

Transcript Gaps & Quality Notes

  • Meeting with infrastructure team (Lee, Will, others)
  • Screen sharing of Veeam console not captured
  • Detailed retention policy screenshot taken during meeting
  • Follow-up session planned for staging server demo
  • Multiple speakers including Lee (infrastructure)
  • Annual disaster recovery test scenario discussed