Availability Group Direct Seeding: Mind Your Backup Jobs

I’ll get right to the point

While you’re Direct Seeding, you have to be careful with any other full or differential backup jobs running on the server. This is an artifact of the Direct Seeding process, but it’s one you should be aware of up front.

In the screencap below, courtesy of sp_whoisactive there’s a differential backup waiting on LCK_M_U, being blocked by session 89, running NULL. That NULL is the backup/restore process that Direct Seeding is going through. I can tell because it’s waiting on ASYNC_IO_COMPLETION, which is commonly associated with backups writing to disk.

Behind the scenes

One of the steps that you can see Direct Seeding go through if you watch it via Extended Events is LIMIT_CONCURRENT_BACKUPS. This isn’t just for Direct Seeding — meaning you can only get Direct Seeding up and running one database at a time — this apparently goes for other backups of the database you’re currently synchronizing.

Who has to be careful?

Basically everyone. Well, anyone whose backup jobs automatically detect new databases. If you’re using Maintenance Plans, you might have finally won a round, here. Whether it’s Ola, Minion, or Dell LiteSpeed, chances are you don’t have one backup job per database, because that would be crazy for anything other than log backups. Your backup jobs likely gather a list of databases, and cycle through them doing ~the necessary~

If your full or differential jobs hit a database while Direct Seeding is doing the initial sync, they’ll be blocked until it finishes. This can really mess with RPO and RTO for your other databases, especially if it takes a while to sync, or you’re syncing a bunch of databases with Direct Seeding, and the backup job keeps getting stuck behind each database synchronization.

Thanks for reading!