Backups are the safety net that matters most exactly when everything else has already gone wrong — a ransomware attack, an accidental deletion, a failed migration. Yet backup strategy is one of the most commonly neglected areas of cloud security for small teams, often set up once during initial infrastructure setup and never revisited or actually tested. This guide covers what a reasonable backup strategy looks like for a small team, building on our cloud security basics guide.
The 3-2-1 rule, adapted for cloud infrastructure
The traditional backup guideline — three copies of your data, on two different types of storage media, with one copy stored offsite — still applies conceptually in a cloud environment, adapted slightly. For a team running infrastructure on AWS or GCP, this typically translates to: your live production data, an automated backup within the same cloud region, and a copy stored in a different region or even a different cloud provider entirely, protecting against a region-wide outage or an issue affecting your primary cloud account specifically.
The “different cloud provider” copy is often skipped by small teams due to the added complexity and cost, but it protects against a genuinely distinct category of risk — an account-level compromise or billing dispute affecting your primary provider, which a same-provider backup in a different region does not protect against.
What should actually be backed up
Beyond the obvious (production databases, user-uploaded files), a complete backup strategy for a small team should also cover infrastructure configuration itself — the specific settings, IAM policies, and network configuration that define how your environment is set up, not just the data flowing through it. Recovering data into an incorrectly configured environment is only a partial recovery.
Infrastructure-as-code tools (Terraform, AWS CloudFormation, GCP Deployment Manager) address this specific gap by defining your infrastructure configuration in version-controlled code that can be used to rebuild an environment from scratch, rather than relying on manually reproducing console settings from memory or scattered documentation during a recovery scenario.
Automating backups vs manual snapshots
Manual backups depend on someone remembering to actually perform them consistently, which in practice tends to degrade over time as other priorities compete for attention. Automated backup schedules — configured once and running on a defined schedule without ongoing manual intervention — are far more reliable for anything genuinely important. Both AWS and GCP support automated, scheduled snapshots for databases and storage volumes, configurable with retention policies that automatically manage how long each backup is kept before being deleted.
Reserve manual snapshots for specific, deliberate moments — immediately before a risky migration or major configuration change, for example — as a supplement to your automated schedule, not a replacement for it.
Backup frequency and retention: matching your actual recovery needs
Backup frequency should be driven by how much data loss your business could actually tolerate if you had to restore from the most recent backup — this is often called your Recovery Point Objective. A daily backup means you could lose up to a full day’s worth of changes in a worst-case restoration scenario; if that is unacceptable for your specific data (active financial transactions, for example), more frequent backups or continuous replication may be necessary.
Retention policy — how long backups are kept before being deleted — should balance genuine recovery needs against storage costs, which accumulate with every additional retained backup. A common pattern is keeping frequent recent backups (daily for the last week or two) alongside progressively less frequent older backups (weekly for the last few months, monthly beyond that), rather than retaining every single daily backup indefinitely at full cost.
The step everyone skips: actually testing your backups
A backup that has never been tested is, in practice, an assumption rather than a genuine safety net. It is common to discover during an actual emergency that a backup was misconfigured, incomplete, or corrupted — problems that would have been caught by periodically testing the actual restoration process rather than only confirming that a backup job completed without an error message.
Schedule a periodic test restoration — quarterly is reasonable for most small teams — where you actually restore a backup into a separate test environment and verify the restored data and configuration work as expected. This is the single highest-value backup practice most small teams skip, generally because it takes real time and does not feel urgent until the moment a genuine restoration is suddenly, urgently needed.
Protecting backups from the same threats as production data
A backup strategy that stores backups with the same access permissions and in the same account as production data provides limited protection against certain threats — notably ransomware or an account-level compromise that could affect backups alongside the production data they are meant to protect. Where possible, store backups with more restrictive access than production data itself (fewer people or services with permission to delete backups, specifically), and consider immutable backup options that prevent modification or deletion for a defined period even by an account with otherwise elevated permissions.
This additional protection matters specifically for the ransomware scenario, where an attacker who has compromised production access may also attempt to delete or encrypt backups to prevent recovery without paying a ransom — a documented pattern in real ransomware incidents that immutable, separately-permissioned backups specifically defend against.
Documenting your recovery process, not just your backup process
Having backups is only half the equation — the actual recovery process, including who is responsible for initiating it, what order systems should be restored in, and how long each step realistically takes, deserves its own documentation separate from simply knowing backups exist. During an actual incident, especially a stressful one like a ransomware event or major outage, having a clear, written runbook reduces the chance of mistakes made under pressure and reduces dependency on one specific person’s memory of how the process works, particularly if that person is unavailable when the incident occurs.
This documentation should be treated with the same care as any other sensitive infrastructure information — accessible to the people who would need it during an incident, but not so widely distributed that it becomes an unnecessary security exposure itself, given that it likely describes exactly how your production systems and access controls are structured.
Practical starting checklist
1. Identify what data and configuration genuinely need backup, beyond just the obvious database.
2. Set up automated, scheduled backups rather than relying on manual snapshots.
3. Store at least one backup copy outside your primary cloud region, ideally outside your primary provider entirely for critical data.
4. Define a retention policy balancing recovery needs against storage cost.
5. Restrict backup deletion permissions more tightly than production data access.
6. Schedule and actually perform a test restoration at least quarterly.
Frequently asked questions
How much should a small team budget for backup storage costs?
This varies significantly based on data volume and retention policy, but backup storage is generally a small fraction of overall cloud infrastructure cost for most small teams, and the cost of inadequate backups during an actual incident — lost data, lost business time, potential ransom payments — far outweighs reasonable backup storage costs in almost every case.
Is a backup to a different region within the same cloud provider sufficient, or do we need a different provider entirely?
A different-region backup within the same provider protects against a regional outage, which is a meaningfully common scenario. A different-provider backup adds protection against an account-level compromise or provider-specific issue, which is a lower-probability but higher-impact scenario. For most small teams, a different-region backup is a reasonable minimum, with a different-provider backup as a worthwhile addition for genuinely critical data specifically.
How do we know if our current backup setup is actually adequate?
The clearest test is attempting an actual restoration, as described above. If you cannot confidently restore your data and configuration from backup into a working state today, your current setup has a gap worth addressing regardless of how the automated backup schedule itself appears to be running.
Should backup testing be done in production or a separate environment?
Always in a separate, isolated test environment, never in production, to avoid any risk of the test restoration process itself disrupting live systems or data.
Who on a small team should be responsible for backup strategy and testing?
Assign clear ownership to a specific person rather than leaving it as an ambient responsibility nobody is specifically accountable for, which is how backup testing most commonly gets quietly neglected over time. This does not need to be a full-time role — a quarterly reminder and a couple of hours to run the test restoration is a reasonable ongoing time commitment for most small teams.
For more on protecting your cloud infrastructure broadly, see our cloud security basics guide and IAM best practices guide.