Press "Enter" to skip to content

Category: HA / DR

Asynchronous Snapshot Replication from ActiveCluster Pods to Other Arrays

Anthony Nocentino digs into some very neat and very expensive things:

I’ve been rebuilding my three-site SQL Server demo lab, and I ran into something I’ve wanted for a long time. If you’ve ever designed a SQL Server environment on ActiveCluster, you know the pattern: two FlashArrays running a synchronously replicated pod for zero RPO between sites, and a third array somewhere else for a longer retention, disaster recovery copy. The problem was that you couldn’t get the data to that third array directly from the pod. Protection groups inside a stretched pod simply couldn’t have an array target.

That’s changed, and it’s been possible longer than a lot of us realize. You can create a protection group inside an ActiveCluster pod, add a third FlashArray as a target, and asynchronously replicate snapshots to it on a schedule. Your synchronously replicated data gets a third copy, and you don’t have to build a parallel set of non-pod volumes to make it happen.

In this post, I’m going to show you how to configure this end to end with the Pure Storage PowerShell SDK2, so you can automate it. Let’s go.

I mean, sure, you need multiple FlashArrays to do this. But who doesn’t have a few of those floating around?

Leave a Comment

An After-Action Report of a DR Scenario

Jordan Boich tells it like it is:

As anyone in IT will tell you, when an outage strikes, and all hands are on deck, that is something that will wake you up faster than any cup of coffee. That was me. Waking up trying to get my bearings to take part in addressing an outage with my bed-head in full effect (Thank you Microsoft Teams for giving that little preview window to show what you look like before you turn on your camera).

Click through for the full story.

Leave a Comment

The Importance of Disaster Recovery Testing

Vlad Drumea performs some tests:

After the ANCPI hack that took down Romania’s land registry, Andrei Avădănei, CEO of Bit Sentinel and founder of DefCamp, published on LinkedIn a detailed proposal for a national offensive security program.
It covered pentesting frameworks, vulnerability disclosure, continuous monitoring, and accountability measures. The proposal was thorough, logical, and exclusively focused on prevention and detection.

I left a comment suggesting one addition: mandatory disaster recovery simulations.
Can institution X recover after their entire production environment is encrypted? If so, how long does it take and what data is lost? Are there backups? And if yes, are they actually viable, or are they Schrödinger’s backups, where you only find out whether they work at the exact moment you need them?

This exchange made me realize that organizations, especially in the public sector, rarely consider doing disaster recovery tests.

I’ve been on the edges of DR scenarios at prior jobs, including one at a state agency. Most of the time, the tests have to be hypothetical or piecemeal because we rarely had the hardware to support a full switch-over, or the budget to spin up an equivalent set of hardware in a different region.

Leave a Comment

Planned Failover of Availability Groups on Kubernetes

Anthony Nocentino runs a test:

When building the sql-on-k8s-operator, I wanted to make sure it could handle both planned and unplanned failovers. The easy case is a planned failover, where you deliberately move the primary role to another replica. The harder case is an unplanned failover, where the primary pod just disappears. The operator needs to handle both.

I recently ran a full planned failover rotation on a three-replica SQL Server Availability Group managed by sql-on-k8s-operator, and I want to show you exactly what happens inside SQL Server and the operator during each hop. If you’ve been following my Introducing the SQL Server on Kubernetes Operator post, this is the logical next step: what does the error log actually look like during a planned failover, what does the operator do in response, and how long does the whole thing take?

I ran the same three-hop rotation twice: once with an idle 5GB database to establish a baseline, and once under a sustained TPC-C workload with HammerDB. In this post, I’ll walk through the SQL Server error log entries, the operator’s reconcile behavior, and the timing data for both runs. In the next blog post, I’ll show what happens during an unplanned failover. Let’s go.

Click through to see how it all works.

Comments closed

The Cloud (Alone) Is Not a Disaster Recovery Strategy

Umair Shahid explains that you need more:

When AWS stumbled – twice – in October 2025, many teams discovered that “we are in the cloud” is not the same as “we have disaster recovery”.

Applications went offline, customer-facing portals returned errors, and internal dashboards that teams rely on every morning failed to load.

Most of those systems were already running on managed cloud services. They had multi-AZ databases, auto scaling groups, and health checks. What they did not have was a clear answer to three simple questions:

Read on for those questions, which are critical to ensuring business continuity.

Comments closed

PostgreSQL Business Continuity as Layers

Umair Shahid explains that it’s like an onion:

High availability for PostgreSQL is often treated as a single, big, dramatic decision: “Are we doing HA or not?”

That framing pushes teams into two extremes:

  • a “hero architecture” that costs a lot and still feels tense to operate, or
  • a minimalistic architecture that everyone hopes will just keep running.

A calmer way to design this is to treat HA and DR as layers. You start with a baseline, then add specific capabilities only when your RPO/RTO and budget justify them.

My thing I would point out is that the first few layers are actually disaster recovery, and that high availability first comes into the picture with Layer 3. But if you think of it in terms of Business Continuity (High Availability + Disaster Recovery), then the approach is a good one.

Comments closed

Deciding Whether to Use Clustering or Availability Groups

Brent Ozar has a take:

Sandra Delany (LinkedIn) wrote a well-thought-out blog post called, “Should a SQL Server DBA Know Windows Clustering?” She’s got about 20 years of DBA experience, and she works for Straight Path (a firm I respect) as a consultant. You can probably guess based on her background that yes, she believes you should know how to set up, configure, and troubleshoot Windows clustering. It’s a good post, and you should read it.

But… I don’t agree.

Read on for Brent’s opinion. I do agree that there are companies that don’t need high availability, and that there are plenty of problems you can run into if you don’t understand how it all works. I also think that, if you’re a DBA responsible for maintaining servers, and your company isn’t using any kind of high availability option, it’s important at least to learn how the mechanisms work so that, if HA does become important, you aren’t pushing back because of ignorance in the product.

But on the flip side, where does that rank in importance? It’s probably closer to the middle (or lower) than the top of the list. And I definitely agree that disaster recovery is generally the more important of the two if you can only have one. But even there, we have exceptions in things like stock trading systems or data warehouses, where you can rebuild the system from external sources.

Comments closed

Security and High Availability Checklist for Database Application Vendors

Andreas Wolter has a new version of a checklist:

As a database application vendor, the security and reliability of your software are key competitive differentiators. As a Database Administrator, your priority is ensuring that hosted databases do not expose data or the environment to risk. To support this, we have developed a checklist designed as a blueprint for building secure-by-default, resilient data applications. Following this guidance not only helps you align with ISO 27001 controls but also ensures that your customers can trust your product against the backdrop of a demanding enterprise environment and an evolving threat landscape.

Click through for the list, as well as a PDF version of it. I had a couple of quibbles in my immediate reaction (especially avoiding CLR and triggers), but in fairness, as I thought about whether I’d trust rando vendor XYZ to get it right, I decided that this is good advice.

Comments closed

A Security and HA Checklist for Database Application Vendors

Andreas Wolter shares a list:

As a database application vendor, the security and reliability of your software are core competitive advantages. To help reaching this goal, we have created a checklist which is meant to serve as a blueprint for designing data applications that are secure by default and resilient to failure, ensuring your customers can trust your product in demanding enterprise environments.

I think it’s a good set of criteria. And from the customer’s side, it’s easy to convert these into questions that you can ask vendors before deploying their software.

Comments closed

Backup and Recovery versus Disaster Recovery

Brendan McCaffrey draws a distinction:

It surprises me how many people treat “disaster recovery” and “backup & recovery” as interchangeable terms. But backups are not disaster recovery, and disaster recovery is not a backup strategy. Confusing the two creates a false sense of security that often becomes visible the moment something goes wrong. The goal of this post is to offer clarity on what separates these concepts, so you can design a strategy that actually protects your business, not just your data.

Read on for Brendan’s argument.

Comments closed