Backup and Disaster Recovery for SMEs: the 3-2-1 rule, RTO and RPO explained for managers

How small and medium-sized enterprises can protect their data, applications and business continuity through automated backup, monitoring and effective recovery procedures.

Imagine a company with 30 employees that uses an ERP system, a CRM application, an online store and a billing platform every day.

One morning the main server will not start. The database becomes inaccessible, orders cannot be processed and employees can no longer consult the documents they need.

The IT administrator discovers that the last available backup was made three days ago. The company now faces two problems: recovering the system and reconstructing the lost information.

Such an incident can cause delays, financial losses and damage to customer relationships. For small and medium-sized enterprises, these situations can have a disproportionate impact because technical and financial resources are limited.

The solution is not only making periodic backups. A complete Backup and Disaster Recovery strategy is needed, built around business continuity.

This strategy must answer three essential questions:

• Which information and applications must be protected?
• How long can the company operate without them?
• How much data can the organisation afford to lose?

The answers set the level of investment and the technical measures required.

1. Backup and Disaster Recovery: what is the difference?

Although the terms are often used together, backup and disaster recovery are not the same thing.

Backup is the process of creating copies of information for later recovery. These copies may include documents, databases, application configurations, virtual machines and other digital resources.

Disaster Recovery (DR) is the set of procedures needed to restore IT systems and resume operations after a major incident.

A backup can save information, but it does not guarantee that applications will work immediately after restoration.

For example, recovering an Excel file may take a few minutes, while rebuilding an ERP server may require installing the operating system, configuring the application, restoring the database and verifying integrations. Disaster Recovery includes all of these operations.

From a management perspective, backup protects information, while Disaster Recovery aims to resume business operations. Both must be included in the operational continuity strategy.

2. Why do SMEs need a recovery strategy?

IT risks do not affect large companies alone. An SME can lose access to information because of equipment failure, human error, a failed software update or a cyber attack.

Ransomware is a particular risk because it can encrypt company files and may also try to compromise backups.

Other situations include accidental deletion of a database, problems with a cloud provider or physical damage to equipment.

An online store may lose recent orders, and an accounting firm may temporarily lose access to client documents. Even an incorrectly performed software migration can cause a major incident.

For that reason, backup must be treated as a permanent process, not as an occasional operation.

3. The 3-2-1 rule: the foundation of a backup strategy

One of the best-known recommendations in data protection is the 3-2-1 rule.

The principle is simple:

3 copies of the data. The organisation must keep three copies of important information: the original data and two backups.

2 different types of storage media. Copies must be distributed so that a single failure does not compromise them at the same time. Local disks, NAS systems, cloud storage or dedicated media can be used.

1 copy in a separate location. At least one copy must be kept away from the main site, for protection against fire, theft or other local incidents.

Consider a company that uses a server for order management. The original data are stored on the server, one copy is made on a separate NAS, and another copy is sent encrypted to a storage service in a different data centre.

If the server fails, the company can use the local backup. If the entire site becomes unavailable, it can recover information from the external copy.

The rule alone does not guarantee recovery, but it reduces the risk of losing all data at once.

4. From 3-2-1 to 3-2-1-1-0

For ransomware protection, organisations can adopt an extended version of the classic rule: 3-2-1-1-0.

The additional numbers represent two important objectives.

1 offline or immutable copy. This must be protected so that an attacker who compromises the main infrastructure cannot easily delete or modify it.

An offline backup is disconnected from active systems. An immutable backup uses technical mechanisms that prevent modification or deletion of data for the configured retention period.

0 errors on verification. Copies must be verified and tested through restoration procedures. The objective is that validation operations report no unresolved errors.

This is a practical design rule, not a mathematical guarantee against loss. The organisation must continuously track backup results and test recovery.

A copy that exists on disk but cannot be restored does not provide the expected protection.

5. RTO: how long can the company stay without a system?

Recovery Time Objective (RTO) is the maximum acceptable time to restore a service after an interruption.

For a manager, the question is: How many hours can we operate without this application before the impact becomes unacceptable?

An online store with a high order volume may need an RTO of one hour. For an internal archiving application, an RTO of 24 hours may be acceptable.

RTO is not a duration automatically guaranteed by a software product. It is a business objective that must be supported by infrastructure and tested procedures.

If the organisation sets an RTO of two hours, but full restoration takes six hours, the strategy does not meet the requirement.

The shorter the desired recovery time, the higher the investments may become. Redundant systems, standby servers and recovery automation can reduce the time needed to resume operations.

6. RPO: how much data can we afford to lose?

Recovery Point Objective (RPO) expresses the maximum acceptable amount of data loss, measured in time.

If a company has an RPO of 24 hours, it accepts the possibility of reconstructing information entered after the last recovery point within that period.

For an online store, losing a day’s orders may be unacceptable. Such a system may need an RPO of 15 minutes or even less, depending on financial impact.

Consider an incident at 11:00. The last valid recovery point is from 10:45. The company may lose changes recorded in the last 15 minutes. If the system is restored at 13:00, the outage lasted two hours.

RPO measures acceptable data loss. RTO measures acceptable service interruption. These two objectives must be set separately.

7. Example RTO and RPO for an SME

A company can classify applications by operational importance.

The values are indicative and must be set through a business impact analysis (BIA).

A company that processes financial transactions may need stricter objectives than an organisation that updates documents only occasionally. The decision should be taken jointly by management and the IT team.

8. Full, incremental and differential backup

There are several methods for protecting data.

Full backup saves all selected information. It is simple to understand and restore, but can consume space and time.

Incremental backup saves changes since the last relevant backup, reducing the volume of transferred data.

Differential backup saves changes since the last full backup.

The choice depends on data size, change frequency and the time available for restoration.

A company may run a weekly full backup, daily incremental copies and additional protection for databases with frequent changes.

Frequency must still be aligned with RPO. If the database is saved only once a day, a 15-minute RPO cannot be met with those copies alone.

For critical applications, journaling mechanisms and point-in-time recovery may be required.

9. Monitoring: backup must be supervised

A common mistake is configuring an automatic backup and assuming it will work permanently.

In reality, operations can fail because of lack of space, expired credentials, network problems or software errors.

That is why the backup strategy must be integrated with IT infrastructure monitoring. Solutions such as Zabbix, Prometheus, Grafana or other monitoring systems can supervise processes using appropriate integrations and checks.

Administrators must track the time of the last valid copy, operation duration, available space and integrity check results. Independent verification that copies exist at the final destination is also useful.

For example, if a backup scheduled for 02:00 does not complete, the system can alert the IT team. For critical problems, notifications should be sent through channels that do not depend exclusively on the affected infrastructure.

Monitoring provides visibility, but it does not replace restoration testing.

10. Backup for Docker applications

Docker is frequently used to host web applications, Help Desk platforms, internal services and databases. The technology simplifies installing and administering applications through containers.

There is an important difference between a container and persistent information. A container can be recreated quickly from a software image, but data stored in volumes must be protected separately.

For example, a CRM application may use three containers: one for the web interface, one for application services and one for the database. For full recovery you must keep persistent data, user-uploaded files and the configuration needed to rebuild the services.

With Docker Compose, configuration files and volume definitions must be included in the recovery plan.

It is also important to protect secrets, certificates and connection parameters, without including them unencrypted in archives accessible without authorisation.

For active databases, simply archiving a volume may produce an inconsistent copy. Database-engine-specific backup mechanisms or properly coordinated snapshots are preferred.

A complete plan must allow rebuilding the application on another server, not only recovering files.

11. Database backup: PostgreSQL and MySQL

Databases are often the most important component of a business application.

In PostgreSQL you can use logical copies made with pg_dump or physical backup mechanisms. For low RPO objectives, PostgreSQL supports WAL archiving and point-in-time recovery (PITR).

This mechanism can restore the database to a state before an accidental deletion, if the required backups and journals are available.

In MySQL, strategies may include full copies, storage-engine-appropriate backups and binary logs for recovering changes.

The solution must be chosen according to database version, volume, consistency requirements and resources.

An important aspect is protecting users, roles, extensions and configurations that are not always included in a normal export of a single database.

For ERP and CRM applications, administrators must also verify compatibility between the database version and the restored application version.

12. Backup before database migration

Migrating a database may be needed when changing servers, updating an application or moving to another cloud provider.

Any important migration must be preceded by a protection and rollback strategy. Before the operation, the IT team must make a valid copy, document software versions and test restoration in a separate environment.

Table structure, user rights and database-dependent features must be verified.

For migrating a production system, you must also decide how transactions made during the transfer are handled. In some cases a maintenance window may be needed in which writes are temporarily stopped.

After the transfer, verify data integrity, application functionality and integration with external services. The plan must also include conditions for returning to the previous system.

A rollback is not always possible by simply restoring an old copy, especially if users entered new data after migration. Therefore the rollback procedure must be designed and tested before the change.

13. Replication does not replace backup

Many companies use data replication to increase system availability. For example, a primary database may send changes to a secondary server.

If the primary server fails, the secondary system can take over, depending on architecture. Replication is useful, but it does not replace backup.

If a user accidentally deletes information, the deletion may also be transmitted to the secondary replica. The same can happen with incorrect changes or data compromise.

Backups with historical versions and separately protected copies allow recovery of a previous state. Organisations must combine high availability with independent information protection.

14. What does a Disaster Recovery plan look like?

A DR plan must be a practical document, not only a general description of the infrastructure. It must identify critical systems, responsible people and procedures for activating recovery.

Consider a ransomware attack that affects a company’s main server.

• The first stage is identifying and isolating compromised systems to limit spread.
• Next comes incident assessment and verification that unaffected copies exist.
• The IT team prepares a clean environment, restores applications and databases and verifies that they work.
• Management sets priorities and coordinates communication with employees and customers.
• Before returning to production, the cause of compromise must be analysed to avoid reinfecting the restored system.

The plan must also provide alternative communication channels, because email or internal applications may be unavailable. Finally, the incident and measures needed to prevent similar problems are documented.

15. Restoration testing: the only real proof

The fact that an application displays “Backup successful” does not prove that the entire infrastructure can be recovered. Real verification means restoring into a controlled environment.

Tests can be performed gradually. Monthly you can restore a file or a test database, and quarterly you can verify recovery of a complete application.

Periodically, the company can organise a Disaster Recovery exercise with technical staff and business owners. During the test, restoration duration and the point to which data could be recovered are measured.

Results are compared with approved RTO and RPO values. If objectives are not met, causes must be identified and procedures updated.

16. How much does a backup strategy cost?

For SME managers, cost is an important factor. The investment must still be compared with potential losses from business interruption.

Suppose a company estimates a financial impact of €500 for every hour its order system is down. A six-hour outage can produce an estimated impact of €3,000, without including possible data reconstruction costs or damage to commercial relationships.

The figures are purely illustrative.

The budget for a protection strategy may include local storage, cloud services, software licences, monitoring and technical administration.

Open-source solutions can reduce some licensing costs, but require qualified staff. Managed services may suit organisations without a permanent IT team.

The choice must be based on likely business impact and total cost of ownership.

17. A practical 30-day implementation plan

An SME can start with a project organised in four stages.

Week one – inventory. Applications, databases, servers, documents and responsible people are identified. Management sets priorities and RTO and RPO objectives.

Week two – backup configuration. Local and external copies, encryption, retention policy and offline or immutable protection are implemented.

Week three – monitoring and documentation. Alerts are configured, recovery procedures are defined and emergency access is documented.

Week four – testing. A system is restored in a separate environment and time and data integrity are checked against objectives.

After implementation, periodic reviews are needed. New applications, servers or databases must be included in the backup strategy before they become critical for the company.

The 30-day plan is an example of initial organisation, not a guarantee that any infrastructure can be fully protected in that interval.

18. Management and IT team responsibility

Data protection must not be delegated exclusively to the system administrator.

Management defines which processes are critical, what interruption level is acceptable and what resources can be invested. The IT team identifies technical solutions, implements backups, monitors operations and tests recovery.

Responsibilities must be clearly documented. Access policies must also limit the possibility that users or compromised accounts delete backups.

It is recommended to separate credentials for the main infrastructure from those for backup administration.

When external providers are used, contracts must specify responsibilities, data access, restoration procedures and assumed service levels.

RTO and RPO objectives must be discussed explicitly with the provider, because they are not automatically guaranteed by simply purchasing a backup service.

Conclusion: backup is an investment in business continuity

For small and medium-sized enterprises, data protection must become a permanent component of business administration.

The 3-2-1 rule offers a simple basis for distributing backups, and variants that include offline or immutable storage reduce risks associated with ransomware attacks.

RTO and RPO turn technical requirements into clear objectives that management can understand and evaluate.

Monitoring enables rapid problem identification, while procedures dedicated to Docker and databases protect modern applications. Restoration testing shows whether the strategy works in practice.

A company does not necessarily need complex infrastructure to benefit from effective protection. It is more important to implement measures proportionate to the risks and verify them periodically.

It is not enough to know that you have a backup. You must know how quickly you can recover your business and how much information you can save in an incident. That is the difference between simply keeping copies and a real digital continuity strategy.

Sources and technical documentation

1. CISA – StopRansomware Guide
2. NIST SP 800-34 – Contingency Planning Guide
3. Microsoft Azure – Disaster Recovery
4. Docker – Backup, Restore and Migrate Volumes
5. Docker – Managing volumes in Compose
6. PostgreSQL – Backup and Restore
7. MySQL – Backup and Recovery
8. Google SRE – Data Integrity
9. NCSC – Offline Backups in an Online World

Informational and educational article, updated for October 2026. Objectives, procedures and costs must be adapted to each organisation’s infrastructure and risks.