Jax Data

You're brand new to the DBA role, or the accidental DBA who inherited the servers — either way, you are now the person who owns the databases. Anyone can schedule a backup; the job that matters is getting the data back. In this session we will walk through SQL Server backup and recovery from the ground up — backup types, recovery models, and the restore discipline that turns a pile of .bak files into a real recovery plan. You'll leave knowing not just how to back up a database, but how to prove you can restore it.

Maybe you're brand new to the DBA role, or maybe you're the accidental DBA who inherited the servers because you were the "person who's good with computers." Either way, you are now the person who owns the databases — and backups are the one thing you can't afford to get wrong, because a backup you've never tested is a hope, not a recovery plan.

In this session we will walk through everything you need to protect SQL Server data and, more importantly, bring it back. We'll start with the fundamentals: full, differential, copy-only, transaction log, and VM snapshot backups, and how the Simple, Full, and Bulk-Logged recovery models decide which ones you can even use. From there we get practical — managing transaction log VLFs so restores don't crawl, setting retention with a GFS strategy, and separating RPO from RTO so you can give the business real answers about data loss and downtime.

Then we'll cover the tooling and the tuning: SQL Server Maintenance Plans, RedGate, Idera, dbatools, and Ola Hallengren — what each is good and bad at, and how mixing them quietly breaks your LSN chain. We'll tune backup performance with BUFFERCOUNT, MAXTRANSFERSIZE, and striping, and look hard at compression, including SQL Server 2022's QAT hardware offload and the brand-new ZSTD compression in SQL Server 2025, with real benchmark numbers from a 444 GB database.

Finally, the part everyone skips: restores. Tail-log backups, the NORECOVERY/RECOVERY sequence, point-in-time recovery with STOPAT, automated test restores, protecting your encryption keys, and the 3-2-1 rule with an immutable copy that ransomware can't touch. Because a backup is only as good as your last successful restore.

Goals / Learning Objectives

By the end of this session, you'll be able to:

Choose the right backup type for a database based on its recovery model, and explain what point-in-time recovery does and doesn't require.
Distinguish RPO from RTO and translate the business's tolerance for data loss and downtime into a concrete backup schedule.

Keep restores fast and reliable by managing transaction-log VLFs and designing a sensible short- and long-term (GFS) retention strategy.
Pick and configure backup tooling (Ola Hallengren, dbatools, and others) without breaking the LSN chain, and tune backup performance and compression — including SQL Server 2025 ZSTD.

Perform a real recovery: tail-log backup, ordered restore chain, point-in-time STOPAT, and automated test restores — plus protect encryption keys and apply the 3-2-1 rule with an immutable copy.

You know how to write a PowerShell script. You know how to use dbatools. But every time you need the same logic in a different place, you copy and paste — and then you have two scripts to maintain. Then five. Then twenty.

This session is about breaking that habit. We will build a real, production-ready function from scratch — live, in front of you — one concept at a time. By the end, you will have a `Get-SqlServerHealth` function that interrogates every SQL Server instance in your registered server group, produces a full inventory and health report, and pipes directly to Excel or your clipboard for an email. No hardcoded instance names. No copy-paste. One function, every server.