Cloud Backup Doesn't Mean Safe: How to Set Up a Truly Recoverable Backup

Many teams feel they have a backup simply because their files are stored in the cloud. However, folder synchronization, server snapshots, and recoverable backups are three different things. If a file is deleted and that deletion is synchronized, the cloud doesn't help much. If an admin account is compromised, attackers may also be able to delete the entire backup.

A good backup is not just about making copies. Its main goal is to ensure that data can be restored to a reasonable condition, within an acceptable timeframe, and without relying on a single account or system.

Cloud storage is not always backup

Cloud storage is designed for files to be accessible from multiple devices. The synchronization feature allows changes on one device to be reflected on others. This is practical for daily work, but it does not provide complete protection against data loss.

For example, if a team member accidentally deletes a project folder, and the system performs automatic synchronization, that folder may also disappear from other devices. Some services provide a trash bin or version history, but the recovery period is limited and may not cover all types of data.

Backups have different characteristics. Backup systems typically create copies on a schedule, store multiple versions, and provide recovery mechanisms. Ideally, those copies have access and retention policies that cannot be easily altered by anyone with access to the main system.

Start with two important questions

Before choosing a service or purchasing additional capacity, determine the following two metrics:

• RPO or Recovery Point Objective: how much data can be lost in the event of a disruption. An RPO of one hour means backups need to be performed at least every hour to limit potential data loss.
• RTO or Recovery Time Objective: how long the system can be unavailable before it starts to have serious impacts. An RTO of four hours requires a recovery plan that is much more prepared compared to a two-day recovery target.

The values do not have to be the same for all data. Documentation photos may only need to be backed up once a day. Transaction databases, on the other hand, may require more frequent backups or additional replication.

This distinction helps avoid two common mistakes: paying too much for protection for non-critical data, or saving too much on systems that are actually operational centers.

Use the 3-2-1 principle as a starting point

The 3-2-1 principle remains relevant because it is easy to understand and strong enough as a foundation:

1. Keep at least three copies of data.
2. Use at least two types of media or storage locations.
3. Store at least one copy in a location different from the main system.

In cloud practice, the first copy could be on the production server, the second copy in the primary backup service, and the third copy in a different account or provider. “Different locations” does not always mean different countries. What matters is that disruptions to the main system, account, credentials, or network do not immediately delete all copies.

For stronger protection, some copies can be made immutable, meaning they cannot be changed or deleted for a certain period. This feature is useful against ransomware that tries to encrypt data while also deleting backups.

Pay attention to accounts and access rights

Backups can fail not because the backup process is broken, but because all systems use the same credentials. If one admin account is compromised, attackers may gain access to the production server and delete the backup.

Separate access between production systems and backup systems. Use dedicated accounts with the minimum necessary rights. Do not make one account an administrator for all services unless absolutely necessary.

Some practical steps that can be taken include:

• Enable multi-factor authentication for admin accounts.
• Use dedicated backup accounts, not personal employee accounts.
• Limit who can delete or change retention policies.
• Keep activity logs and review configuration changes regularly.
• Use different credentials between production servers and backup storage.

This is not just a matter of cybersecurity. Separating access also reduces the risk of human error, such as someone deleting a bucket or volume thinking it is no longer in use.

Test recovery, not just “successful” status

A backup dashboard showing a green status does not prove that the data can actually be recovered. The backup process may complete without errors, but the backed-up files may be incomplete, recovery credentials may have expired, or application configurations may not have been saved.

Conduct recovery tests regularly. Start with simple scenarios, such as restoring a deleted file. After that, test the recovery of databases, application servers, or entire work environments to a temporary location.

Note several important points:

• How long does the recovery process take?
• Can the restored data be opened and used?
• Do access permissions, domain names, and application configurations also recover?
• Who should make decisions during the recovery?
• Which parts still require manual steps?

If you have never performed a recovery, do not wait until an incident occurs. A backup that has never been tested is more accurately described as hope rather than a plan.

Don’t forget hidden costs

The costs of cloud backup do not only come from storage capacity. Also consider costs for data transfer out, the number of read-write requests, snapshots, cross-region replication, and large-scale recovery.

For data that is rarely accessed, archive storage classes may be cheaper. However, retrieval times may be longer, and there are minimum storage duration rules. If data needs to be recovered quickly, the cheapest option may not be the most suitable.

Make a simple estimate based on three conditions: normal operation, partial recovery, and full recovery. This way, the team not only knows the monthly costs but also the potential costs when the recovery plan is actually used.

What can be done now

1. List all data and systems considered important.
2. Determine RPO and RTO for each data group.
3. Ensure there is more than one copy in separate locations or accounts.
4. Enable multi-factor authentication and limit delete rights.
5. Check retention periods and available file versions.
6. Conduct a small recovery test this week.
7. Document the recovery steps in a way that others can follow.

Good cloud backups do require costs, discipline, and testing. However, this approach is much cheaper than trying to guess which data is missing after a server failure or account takeover. What you should look for is not the service with the biggest promises, but a system where copies are separate, access is controlled, and the recovery process has been proven.

– Rio Yotto @rioyotto