Every organization has backups. Considerably fewer have a demonstrated restore, and the gap between those two facts is where most recovery plans actually fail.
This is about closing that gap for a Drupal estate: what has to be protected, how to set objectives that mean something, and how to prove the arrangement works before you need it.
Start with the two numbers
Recovery arrangements are sized by two objectives, and they should be decided by the business and written down before the architecture is settled.
NIST states them precisely. The recovery point objective represents the point in time, prior to a disruption or system outage, to which data must be recovered. The recovery time objective is expressed in terms of the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact.
In plain terms: how much work may be lost, and how long may it be gone.
Two things follow. They are decisions rather than technical properties, so somebody with authority has to make them. And they differ per site: a public information site and a site taking applications with a statutory deadline do not have the same answer, and pretending they do means over-engineering one and under-protecting the other. The classification in the site complexity assessment is where those numbers are captured per site.
What has to be protected
The database is the obvious item and it is not sufficient. A restore that produces a working site needs all of the following.
- The database. Content, users, and much of the site's behavior.
- Public files. Images, documents and derivatives. Frequently far larger than the database and frequently on a different backup schedule for no considered reason.
- Private files. Often the most sensitive data on the platform, and often overlooked because they are not served directly.
- Configuration. In version control, which means the repository is part of the recovery story.
- Code and the deployment artifact. Including the ability to rebuild a specific past release, not merely the current one.
- Infrastructure definitions. The environment itself has to be recreatable, which is the point of Infrastructure as Code.
- Secret references and the means to reissue. Not the secrets in a backup, but a documented way to restore access.
- Platform metadata. DNS records, certificates, edge configuration, integration credentials and the list of who owns what.
The last item is the one that turns a four hour recovery into a two day one. Restoring an application into an environment nobody can point traffic at is not a recovery.
Consistency between the parts
A Drupal restore has a subtlety that catches people: the database and the files are separate systems, and a backup of each taken at a different moment may disagree.
The database may reference a file that was not yet in the file backup, or the file store may contain items the restored database knows nothing about. The first produces broken media on a restored site. The second produces orphaned data that quietly accumulates.
The practical mitigations are to align the schedules, to prefer point in time capability where the service offers it, and to accept and document a bounded window of inconsistency rather than pretending it does not exist. AWS Backup, for example, describes itself as a fully managed service that makes it easy to centralize and automate data protection across AWS services, and centralizing is largely valuable because it makes alignment achievable rather than incidental.
Retention, which is a policy question
Frequency and retention are usually inherited from a default and should be decided.
Frequency follows the recovery point objective directly: a daily backup cannot support a one hour objective, however often it is described as robust. Retention answers a different question, which is how far back you might need to reach. Ransomware and slow corruption are the scenarios that argue for longer retention, because both are typically discovered well after they began.
Two properties matter more than the number of copies. At least one copy should be outside the blast radius of the primary account, so that a compromise of that account does not compromise the recovery. And at least one copy should be immutable for a defined period, so that a credential with deletion rights cannot remove the thing that would have saved you.
Restore rehearsal is the control
This is the section that matters most, and it is a single idea: a backup that has never been restored is a hypothesis.
Rehearsal has to be scheduled, because it will never happen otherwise. A workable arrangement is a monthly restore of a representative site into a scratch environment, with three things recorded: whether the restore succeeded, how long it took, and what was missing. The third question is the useful one, and the answer is rarely nothing.
Common findings on a first rehearsal, all of them from real estates rather than imagination: the file backup was a different age from the database; private files were not included at all; the restore needed a credential nobody currently held; the DNS and certificate steps were undocumented; and the elapsed time was several times the stated recovery time objective.
None of those are discovered by inspecting a backup policy. All of them are discovered on the first attempt to use it.
Disaster recovery is a different problem
Backup answers a data loss question. Disaster recovery answers an availability question, and the two are frequently conflated.
Restoring a database does not help if the region it was running in is unavailable. What is needed is the ability to bring the platform up somewhere else, which is where the environment definitions stop being a convenience and become the plan. Rebuilding an environment from code in another region is a rehearsable procedure; rebuilding it from memory is not.
The failure domain is a cost decision that should follow the recovery objectives rather than precede them. AWS's Well-Architected material is a reasonable reference for the reasoning: it describes a framework based on six pillars, one of which is reliability, and notes that achieving reliability is challenging in traditional environments because of single points of failure and a lack of automation.
LABUSA runs this pattern in its own estate: it uses AWS to provide disaster recovery and failover capability for designated websites and web applications hosted within its private infrastructure. That is an arrangement rather than a product, and it is the shape most hybrid recovery designs take.
The procedure, and who runs it
A recovery plan that exists only as an architecture diagram is not a plan. What is needed is short, specific and current.
- Who declares a disaster, and what authority that carries.
- The ordered steps, specific enough to follow at three in the morning by someone who did not write them.
- Where the credentials are, and how they are obtained if the usual route is unavailable.
- How to redirect traffic, including who can change DNS.
- How to communicate, to whom, and who decides what is said.
- What acceptance looks like, so that recovery has an end rather than a feeling.
Two failure modes worth naming. A plan that depends on one person is not a plan; that person will be on a plane. And a plan stored only in the system that is down is a familiar and entirely avoidable irony.
The scenarios worth planning for
Recovery planning improves markedly when it stops being generic. Four scenarios cover most of what actually happens to a Drupal estate, and each stresses a different part of the arrangement.
A bad release. The most frequent by far. The site is up and wrong. Recovery is usually a forward fix or a return to a known point, and the constraint is that database updates are frequently not reversible. This is the scenario the release process should handle, and it is covered in cutover and rollback strategy rather than by the backup regime.
Accidental deletion. Someone removes content, a media library, or a whole site. Recovery is a partial restore, and partial restores are far harder than full ones: extracting one site's content from a shared database backup, without disturbing the rest, is a procedure that needs to have been tried. This is the scenario that most often reveals that the only rehearsed path is a full restore.
Corruption or compromise. The damage is present in the backups because it predates discovery. Retention depth and immutability are what save you, and the recovery point is no longer the most recent backup but the last known good one. Deciding what "known good" means, and how you would establish it, is worth doing before the day.
Infrastructure loss. An availability zone or a region becomes unavailable. Data may be intact and unreachable. Recovery is a rebuild elsewhere from definitions, which is why the environment being described in code is a recovery control and not merely an engineering preference.
Most organizations have implicitly planned for the fourth and rehearsed for none. The second is the one that occurs most often after a migration, because a newly consolidated estate concentrates more sites into fewer databases, and it is the one worth rehearsing first.
What to check on an existing estate
- When was the last successful restore, and who performed it?
- Are private files included?
- Is one copy outside the primary account, and is one immutable?
- Can the environment be rebuilt from definitions, in another region?
- Do the recovery objectives exist per site, and did the business set them?
- Does the actual restore time match the stated objective?
Question one settles most assessments quickly, and question six is the one whose answer most often surprises the people who wrote the objective.
Protection and recovery are one layer of enterprise Drupal cloud architecture, and they connect directly to the reference architecture and to the operating model in enterprise Drupal managed services. If nobody can answer question one, that is the place to start.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.