A disaster recovery (DR) plan gets written once, signed off once, and then trusted indefinitely unless something forces a second look. Data volumes grow, workloads change shape, the person who designed the original setup moves to another team, and the plan in the folder describes a system that no longer exists. None of that shows up in normal operation. It shows up on the day you need the plan to work, which is the worst day to find out it doesn’t.
These six questions are the ones worth asking this week, before an incident asks them for you.
| Question | What a weak answer sounds like | What a strong answer looks like |
|---|---|---|
| Actual RPO and RTO (recovery point and recovery time objectives) | “The design said four hours” | Lag and restore speed measured this week |
| Standby headroom | “It’s only for emergencies” | Standby sized for peak production, reviewed as production grows |
| Replica consistency | “Replication says it succeeded” | Row counts and views checked against the source |
| Job health | “The dashboard is green” | Alerts on repeated failures and growing lag |
| Storage headroom | “It’s just a copy” | Backup shares and standby on the same growth plan as production |
| Failover testing | “We did a walkthrough” | A full failover run on a schedule, runbook updated afterwards |
Do You Know Your Actual RPO and RTO, or Just the Numbers From the Original Project?
The RPO and RTO in most DR plans are the estimates from the original design, not figures anyone has checked against the system as it runs today.
Those numbers were set once, from the data volume and change rate when the project closed. On Netezza, RPO depends on how far the standby is behind: how many backup and restore cycles it has applied, and how often those cycles run. RTO depends on how long it takes to bring the standby into service, and on the restore throughput you actually get, not the throughput someone assumed. As data grows, each cycle takes a little longer, the standby drifts a little further behind, and the RPO on the closeout slide stops being true without anyone noticing.
A healthier setup treats both as numbers you can work out today, from this week’s lag and this week’s measured restore speed.
The Netezza Replication module in Smart Management Frameworks (SMF) shows how many backup cycles each DR target is behind its source, flags any target that has never been restored, and records the duration and transfer speed, in megabytes per second, of every backup and restore, so an RPO and RTO conversation starts from measured numbers instead of a three-year-old estimate.
Does Your Standby Have the Headroom to Run Production, Not Just Hold a Copy of It?
A standby that holds every row correctly can still fail as a DR system if it can’t carry production load once it’s asked to.
Standby appliances are often sized down from day one, a smaller model or fewer snippet processing units (SPUs), because “it’s only for emergencies.” Nobody tests that assumption under real concurrency. Then the emergency arrives, queries that took seconds start queuing behind each other, and the outage DR was meant to end just changes shape. The data restores fine. The service doesn’t.
This one is a design decision, and no tool makes it for you. A healthier setup sizes the standby for peak production concurrency, or agrees in writing which workloads will be paused during a failover, and reviews that decision whenever production grows rather than once at the original build.
Can You Spot an Inconsistent Object on the Replica Before You Need It?
Replication that reports success and a replica that is ready to query are two different things, and most monitoring only checks the first.
A restore can complete while a table on the standby has fewer rows than its source, because of a skipped object or a partial run that nobody spotted. A view that references another database can break on restore and stay broken until someone queries it. Permissions can be missing, so the data is there but the users who need it can’t see it. None of this trips an alert, because from the replication engine’s point of view nothing failed.
A healthier setup checks the replica against the source: row counts per table, views that compile, and users, groups and grants that match.
SMF’s Replication Check compares row counts table by table between source and replica, at the same consistent point in the backup, and runs whenever you ask for it. After each restore, SMF also detects broken views and rebuilds cross-database views, replays grants on the target, and can back up users and groups alongside the data.
Is Anyone Watching Replication Job Health, or Just Assuming It’s Running?
A replication job that is quietly degrading looks, from a distance, exactly like a healthy one. The only difference is whether something is checking.
Jobs fail and retry, restores fall behind backups, and a status page can stay green because it only confirms that the process started. Whether it finished, and whether the standby is catching up or falling further behind, is a separate question.
A healthier setup alerts on the things that matter: repeated failures, a target that is falling behind, and restores that can’t keep pace with backups, and it stops retrying a failure that keeps happening for the same reason.
SMF’s Netezza Replication module shows live status for every replication set, alerts when failures repeat (after three in a row by default) or a target falls behind, and uses a circuit breaker to stop retrying a failure with the same cause. A Daily DR Summary reports what ran, how much data moved, and anything that needs attention.
Do Your Backup Shares and Your Standby Have Room to Grow?
Growth on the primary lands on the standby and on the backup storage in between, and a DR chain that’s already tight on space is how a routine data load turns into a failure on several systems at once.
Standbys are often provisioned to match the primary at build time, without the same growth margin. Backup shares get sized for the backups of the day. Production keeps growing on its planned curve, and the copies fill up first, so replication starts failing at exactly the moment you’d want it working.
A healthier setup puts the standby and the backup storage on the same capacity plan as production, reviewed on the same schedule, instead of treating them as smaller siblings that can be looked at later.
SMF monitors the health and free space of the backup shares that replication depends on, and warns when free space drops below 10%, so a filling share shows up as an alert rather than a failed cycle.
Has Anyone Tested a Full Failover, or Has the Plan Only Run on Paper?
A DR plan that has never been through a real failover is a hypothesis. It might be a good one. Nobody knows yet.
Full failover tests are disruptive and hard to schedule, so many teams settle for a tabletop walkthrough or a partial test of the easy parts. That’s understandable, and it’s also how gaps survive for years: an extract, transform and load (ETL) job with the primary’s hostname hard-coded, a credential that only exists on the primary, a Domain Name System (DNS) change nobody automated, a downstream report that points at an Internet Protocol (IP) address. On Netezza the database side is usually the best-understood part. The surrounding plumbing is where failovers stall.
A healthier setup runs a full failover test on a real schedule, at least once a year, times it end to end, and updates the runbook based on what actually broke rather than what the plan assumed would work. That measured time is your real RTO.
The Pattern: A DR Plan Is a Claim About Today’s System
None of these six questions get answered by “yes, we have a DR plan.” A DR plan is a claim about the current state of a system, and that claim expires every time the system changes underneath it. Nothing alarms when it does. The gap between “should work” and “will work” just grows until a real incident forces the question.
We’ve written before about the cost of getting a Netezza system back after a disaster. The questions here are about keeping that capability true after it’s built. Smart Database Replication, delivered through SMF, keeps replication lag, job health, replica consistency and backup storage visible as measured numbers instead of assumptions. If you hesitated on more than one of these questions, talk to the team. The cheapest time to find a gap in a DR plan is before you need it.
