How to encrypt drives on live SQL Server with Always-On

To encrypt drives for AlwaysOn I would suggest these steps:

  • Do encryption during low usage hours.
  • Encrypt drives on SECONDARY first. Without taking AlwaysOn offline. Do this during a low usage time slot.
  • Do one drive at the time.
  • Give a bit of time for IO to catch up. I’d wait 10-15 minutes after each drive encryption completes before starting a new one. This may be overkill. But maybe not, since we doing this on live PRODUCTION.
  • Repeat the same steps PRIMARY AlwaysOn node.

To encrypt drives on PRIMARY, you have few options.

Option 1

Failover AlwaysOn to SECONDARY.

And encrypt drives then. Just as described above.

Option 2

I don’t think AlwaysOn failover is a must for drive encryption.

It may safe to simply encrypt on PRIMARY.

Just pay attention to the latencies of SQL operations. And how long SPIDs are taking

Start with the smallest drive or least active drive.

I think, there may a good chance this will go fairly unnoticed to SQL.

Option 3

Encrypt volumes on SECONDARY.

Then set AlwaysOn to asynchronous commit (currently it’s in Synchronous)

Perform steps are described above.

When complete, set AlwaysOn back to synchronous commit.


Your workload is quite heavy. On some days, your PRIMARY is spewing out 800MB worth of logs in 5min.

So if PRIMARY gets affected for too long – there is a good chance this will cause issues.

To make sure AlwaysOn is good – use the AlwaysOn Dashboard.

There you can see AlwaysOn in two statuses:

  1. Synchronizing – which means, if you failover, you may have data loss. And there is no auto-failover at this point.
  2. Synchronized – which means, both replicas are caught up. All good. And auto-failover is ready to kick in if needed.

And if you trying to encrypt *all* drives for compliance with SOC2 or similar regulation and need to encrypt quorum drives – you can. Nothing special about this drive.

I would just encrypt, without any special steps.


Any questions – let me know!


Mark Varnas

Mark Varnas

I love making performance tuning SQL Servers fast and making them more stable. And I channel that obsession into our SQL Managed Services and new content here. When I'm not writing about SQL, I spend time outside hiking, skiing, mountain biking, or trying a new recipe.

Leave a Reply

Your email address will not be published. Required fields are marked *