Backups and Disaster Recovery for Business Applications: What Owners Should Ask For

Most business owners assume their application is backed up. Far fewer can say how much data they would lose if the database failed this afternoon, how long it would take to get back online, or whether anyone has ever restored from those backups to check that they work.

You do not need to be technical to get this right, but you do need to ask for specific things. Whether your system is being built now or has been running for years, backup and recovery should be a written part of your software development services agreement or hosting arrangement, not an assumption.

This guide explains the terms in plain language, what has to be protected, where copies should be kept, and the questions to put to your developers or host.

Backup, Disaster Recovery and High Availability Are Three Different Things

A backup is a copy of your data taken at a point in time and kept somewhere else. It protects you against loss: a deleted record, a corrupted database, a failed update, an attack. A backup on its own does not get you running again. It is raw material.

Disaster recovery is the plan and the resources for rebuilding a working system from that raw material: where the application will run, who does what, in what order, and how long it should take. High availability is different again. It means running duplicate components, such as a second server or a standby database, so that a single hardware failure does not cause an outage at all.

The point owners most often miss is that high availability does not replace backups. A standby database copies every change from the primary within seconds, including mistakes. If someone deletes the customer table, the deletion is faithfully copied too. Only a backup from before the mistake can undo it.

The Two Numbers to Agree: Recovery Time and Recovery Point

Recovery planning comes down to two targets. The US National Institute of Standards and Technology defines the recovery point objective (RPO) as the point in time to which data must be recovered after an outage. In practice it answers "how much recent work can we afford to lose?" The recovery time objective (RTO) is the length of time a system can be in recovery before the business is harmed: "how long can we be down?"

An illustrative example: a wholesale distributor takes orders through a web application that is backed up once a night at 2 am. At 4 pm on a Tuesday the database is corrupted. The newest backup is 14 hours old, so every order, payment record and stock change from that day is gone and must be re-entered from emails and memory. If restoring takes six hours, the team is also offline until 10 pm.

Nothing malfunctioned in that scenario. The backup did exactly what it was set up to do. The problem is that nobody decided whether losing up to a day of orders was acceptable. Tighter targets are achievable, for instance by continuously recording database changes so you can restore to any minute, but they cost more to build and run. That is why these are business decisions, and why different systems in the same company can reasonably have different targets.

What Actually Needs Backing Up

"The database is backed up" is rarely the whole answer. A business application usually has four parts that need protecting, and a restore fails if any one is missing:

• The database: customers, orders, accounts and transactions.
• Uploaded files: documents, images, invoices and anything users attach. These are normally stored outside the database and are easy to overlook.
• Configuration: server settings, scheduled jobs, domain and email settings, and the scripts that define the infrastructure.
• Secrets: encryption keys, passwords and credentials for payment gateways and other third-party services.

Secrets deserve particular attention. If data or backups are encrypted and the key is lost with the server, the backup is unreadable. Keys should be stored separately from the backups they unlock, with access limited to named people. The application source code should live in a version control repository that your company controls, not only on a developer's laptop or the live server.

Where Backups Should Live

A backup on the same server as the application protects against very little. A long-standing rule of thumb, described by the UK National Cyber Security Centre, is the 3-2-1 rule: at least three copies, on two devices, and one offsite.

For a cloud-hosted application, the practical translation is: keep copies in a different geographic region from the live system, and keep at least one copy in a separate account with separate login credentials. If a single compromised or mistakenly used administrator login can delete both the application and every backup, you effectively have one copy. Backups should also be encrypted, and you should decide how long they are retained, since some problems are only noticed weeks later.

An Untested Backup Is Not a Backup

Backup jobs fail quietly. A disk fills up, a credential expires, a new file store is added and never included. The job may even report success while producing a file that cannot be restored. The only reliable evidence is a restore: taking the latest backup, rebuilding the application in a separate environment, and confirming that it runs and the data is complete.

A restore test also tells you your real recovery time, which is often longer than anyone guessed. Ask for one on a schedule, for example quarterly and after major changes, with a short written record of how long it took and what went wrong. Alerts should fire when a backup fails or does not run.

Ransomware Changes the Rules

Ransomware attackers know that backups are what let a victim refuse to pay, so they go after them first. The US Cybersecurity and Infrastructure Security Agency (CISA) advises organizations to maintain offline, encrypted backups of critical data and regularly test them, noting that many ransomware variants try to find and then delete or encrypt accessible backups. The NCSC reports the same pattern, including cases where connected cloud storage holding backups was compromised.

"Offline" here means a copy that the live environment cannot reach or alter. In cloud terms that is usually immutable storage, where a backup cannot be changed or deleted for a set period even by an administrator. CISA's guide notes that some cloud vendors offer this. It is worth asking for by name.

What Your Cloud Provider Does and Does Not Do

Hosting on a major cloud platform does not mean your data is backed up. Providers work on a shared responsibility basis. Amazon Web Services, for example, states that it is responsible for protecting the infrastructure that runs its services, while customers are responsible for managing their data. The provider keeps the data centers and hardware running. It will not rescue you from a deleted database, a bad deployment or a stolen password.

Cloud platforms do supply good tools: automated database backups, snapshots, cross-region copies, immutable storage. Someone still has to switch them on, configure them correctly and pay for them. The same applies to managed hosting and software-as-a-service products: read what the contract actually says about backup frequency, retention and restores. Our guide to choosing cloud hosting for business applications covers the wider hosting decision.

Common Mistakes to Avoid

The same handful of errors appear again and again: treating a standby server as a backup, backing up the database but not uploaded files, storing every copy under one login, keeping only a few days of history, and having a recovery process that exists only in one developer's head. Another is over-engineering. A low-traffic internal tool rarely needs multi-region failover. Spending should follow the cost of downtime and data loss for each system, not a blanket standard.

What to Do Next: Questions for Your Developers or Host

Put these in writing and expect specific answers, not reassurance:

• What exactly is backed up, how often, and how long is each copy kept?
• Where are the backups stored, and are any in a separate region and a separate account?
• Can any single person or credential delete both the live system and all backups?
• Is any copy immutable or offline?
• When was the last full restore test, and how long did it take?
• What are our recovery time and recovery point targets for this system, and who agreed them?
• Is there a written recovery procedure, and who is alerted when a backup fails?

If the answers are vague, start with a single restore test. It will show you most of the gaps in one afternoon.

Conclusion

Backups protect your data, disaster recovery gets you running again, and high availability reduces how often you need either. A sound setup covers the database, files, configuration and secrets, keeps copies where one failure or one attacker cannot reach them all, and is proven by regular restore tests against targets the business has actually chosen.

If you are planning a new application or are unsure how well an existing one is protected, you can contact Entrant Technologies to talk through recovery requirements as part of the build or a review.