Backup and Disaster Recovery for Business Software: A Practical Plan (Backups You Have Actually Tested)

Most businesses say they have backups. Far fewer can answer three simple questions: how much data would we lose, how long would we be offline, and has anyone ever actually restored from these copies? A business software backup that has never been restored is a hope, not a plan. This guide explains what to back up in a custom application or WordPress site, how to choose a schedule, how the 3-2-1 rule works today, and how to test recovery before an incident forces the test.

Why backups fail when you need them

Backups rarely fail loudly. They fail quietly: a job that stopped running months ago, a copy stored on the same server that just died, a database dump that is missing the uploaded files, or credentials nobody can find. Common causes include:

• Same-place storage: the backup lives on the same server, account or cloud project as the live system, so one mistake or one attacker removes both.
• Partial coverage: the database is saved, but not uploaded files, configuration, environment variables or the code version that matches the data.
• No restore test: the files exist, but nobody knows the steps or how long they take.
• Single owner: only one person knows where backups are and how to open them. See our software handover checklist for how to avoid that.
• Attackers target backups: modern ransomware often tries to delete or encrypt backups first.

Small businesses are not too small to matter. According to the Verizon Data Breach Investigations Report 2025, as summarised by CNIC Solutions, ransomware was present in 88% of breaches at small and medium businesses, compared with 39% at large organisations. Attackers automate; they go after whatever is exposed.

Two numbers that drive every decision: RPO and RTO

Before choosing tools, agree on two targets in plain language:

• RPO (recovery point objective): how much recent data can you afford to lose? If the answer is “one hour of orders”, backups must run at least hourly. If it is “one day”, a nightly backup is enough.
• RTO (recovery time objective): how long can the business be down? If it is four hours, you need a rehearsed procedure and a place to restore to, not just files in storage.

Different systems deserve different targets. Your online ordering system and payment records usually need tight RPO and RTO; an internal archive can be far looser. Writing this down per system is often the first time a business sees the gap between what it assumes and what it has.

The 3-2-1 rule, and the version for 2026

The classic 3-2-1 backup rule says to keep three copies of your data, on two different types of storage, with one copy off-site. It still protects against hardware failure, deleted data and site-level disasters. Because attackers now go after backups, vendors such as Veeam recommend 3-2-1-1-0: add one copy that is immutable or offline (it cannot be changed or deleted), and aim for zero errors when you verify restores.

What to back up in a custom application

For a typical web application, a complete backup has more parts than people expect:

1. Database: consistent snapshots plus, where RPO is tight, point-in-time recovery through transaction logs.
2. User-uploaded files: images, documents and invoices, which often live outside the database.
3. Source code and releases: a repository you control, with tagged versions, so you can redeploy the exact build that matches the data.
4. Configuration and secrets: environment settings, API keys and certificates, stored in a secure password or secret manager, never in plain text next to the backup.
5. Infrastructure definition: notes or scripts describing servers, DNS, email and domain settings, so a replacement environment can be rebuilt quickly.
6. Third-party SaaS data: your CRM, email platform or accounting tool. Providers protect their service, but you are usually responsible for your own export and retention.

For WordPress, that means the database, the wp-content folder (uploads, themes, plugins) and the server configuration. Pair backups with the security hardening steps in our guide to WordPress site security (in Albanian).

A restore test you can run this month

A restore test turns a backup from an assumption into evidence. Do it on a separate staging environment, never on live data, and write down every step.

1. Pick a recent backup at random, not the newest one.
2. Restore the database and files into a clean environment.
3. Deploy the matching code version and configuration.
4. Run a short checklist: can staff log in, can an order be created, do recent uploads open, do emails and payments run in test mode?
5. Record how long it took and what was missing. That duration is your real RTO.
6. Fix the gaps, then schedule the test again (quarterly is a sensible start for important systems).

Example: a restaurant ordering platform

Imagine an online ordering system used by a few dozen restaurants. Orders arrive all day, so the team sets an RPO of 15 minutes and an RTO of two hours. The database uses continuous log shipping, menu images are replicated to a second storage provider, and a weekly copy goes to an immutable bucket that the production credentials cannot delete. Each quarter, an engineer restores everything to a staging environment from a randomly chosen day and times it. The first test takes five hours because a certificate and a queue worker were missing from the documentation. After the fix, the second test takes 80 minutes. That difference is exactly why testing matters: the number on paper changed only after someone tried it.

Who owns recovery?

Backups need an owner, a schedule and monitoring. Failed jobs should alert a person, not sit in a log. Include recovery in your support agreement and budget, as described in our guide to software maintenance cost. If you are moving systems, a clean cut-over plan matters too; see our data migration plan.

Frequently asked questions

How often should I back up my business software?

As often as your RPO requires. If losing a day of data is unacceptable, daily backups are not enough. Many order or booking systems back up hourly or continuously, while static websites can manage with daily or weekly copies.

Is my hosting provider’s backup enough?

Often not on its own. Provider backups may be short-lived, stored in the same account, or limited to the server rather than your application. Treat them as one copy and keep an independent one elsewhere. Read the provider’s terms to see what is covered and how restores work.

What is the difference between a backup and disaster recovery?

A backup is a copy of data. Disaster recovery is the whole ability to be running again: a place to restore to, documented steps, access to credentials, and people who know what to do within your target time.

Do cloud and SaaS tools need backups too?

Yes, for data you cannot afford to lose. Accidental deletion, wrong integrations and account compromise are your risk, not the vendor’s. Schedule regular exports for critical records.

How much does a proper backup and recovery setup cost?

It depends on data volume, the targets you set and how many systems are involved. Storage itself is usually the smaller part; the work is in configuration, monitoring and regular restore tests. A short review of your current setup is the quickest way to get a realistic estimate.

Check whether you could really recover

Shkulaku designs, hardens and maintains WordPress, Laravel, Symfony and React systems, including backup, monitoring and recovery as part of our services. If you are not sure your backups would survive a bad day, contact us for a short recovery review: we will map what is protected, what is not, and propose a realistic plan.