3-2-1 Backup Strategy
Build a practical 3-2-1 backup setup in Zerobyte with a fast local copy and an offsite encrypted mirror
The 3-2-1 backup strategy is a simple rule for reducing backup risk:
- Keep 3 copies of your data
- Use 2 different storage systems
- Keep 1 copy offsite
In Zerobyte, that usually looks like this:
- Your live data on a server, NAS, or workstation
- A primary backup repository on fast local storage
- A mirrored repository on an offsite backend such as S3, Cloudflare R2, Google Cloud Storage, Azure Blob Storage, SFTP, or a remote REST server
Why 3-2-1 is a good strategy
A single backup copy can still fail for the same reason as the original data. The 3-2-1 rule reduces correlated failure, so one bad delete, dead disk, provider issue, or site-level incident is less likely to wipe out every copy at once.
| Failure scenario | What goes wrong without 3-2-1 | How 3-2-1 helps |
|---|---|---|
| Accidental deletion or bad change | Your only backup may be too recent or incomplete | Older snapshots give you a clean restore point |
| Disk or NAS failure | Data and backup can be lost together | A second storage system still has the data |
| Ransomware or host compromise | Local storage may be affected too | An offsite copy gives you another recovery path |
| Fire, theft, or power event | Everything in one building can disappear together | The offsite copy survives |
| Provider or account problem | One backend outage blocks restore | Different backends reduce that single point of failure |
Zerobyte fits this strategy well because it already gives you the building blocks:
- Encrypted repositories so offsite copies stay private
- Incremental, deduplicated snapshots so keeping multiple copies is more storage-efficient
- Mirror repositories so one backup job can copy snapshots to additional destinations
- Browsable restores so you can test recovery without dropping to the CLI
How 3-2-1 maps to Zerobyte
| 3-2-1 element | Zerobyte example |
|---|---|
| 3 copies | Live data + primary repository + mirror repository |
| 2 different storage systems | Local disk or NAS for the primary copy, object storage or remote server for the second copy |
| 1 offsite copy | A repository in another building, region, or provider |
Historically, the "2" in 3-2-1 meant two different kinds of media. In modern setups, different storage systems and failure domains matter more than literal media type. A local disk plus cloud object storage is a strong practical interpretation.
How to do it with Zerobyte
Create the volume for your live data
Add the directory or remote share you want to protect as a volume.
Create a primary repository for fast restores
Use a backend that is quick and close to the source, such as a local disk, mounted NAS path, nearby REST server, or nearby SFTP host. This gives you a fast day-to-day restore target.
Create a second repository in a different failure domain
Create another repository on an offsite backend such as S3-compatible storage, Cloudflare R2, Google Cloud Storage, Azure Blob Storage, or a remote SFTP or REST server in another location.
If you want a strong "2" in 3-2-1, avoid putting both repositories on the same host, in the same rack, or behind the same provider account.
Create the backup job and add the offsite copy as a mirror
Set the primary repository as the main backup repository, then configure the offsite repository as a mirror repository. After each successful backup, Zerobyte copies that snapshot to the mirror repository automatically.
Add a schedule and retention policy
Pick a schedule that matches how often the data changes. A solid starting point for many workloads is:
- Schedule:
0 2 * * *(daily at 2:00 AM) - Keep Daily:
7 - Keep Weekly:
4 - Keep Monthly:
6 - Keep Yearly:
1
Adjust this based on your recovery needs and storage budget.
Store the recovery key outside Zerobyte
Keep the organization's recovery key in a password manager, secret vault, or other secure place outside the Zerobyte server. The offsite copy only helps if you can still decrypt it during an outage.
Run a manual backup and test restore
Use Backup now to create the first snapshot, then test a restore to a non-production path. A backup strategy is only real once you have verified that recovery works.
Example Zerobyte layout
| Copy | Example |
|---|---|
| Live data | /srv/data on your server |
| Local backup copy | Local repository on /mnt/backup-disk/zerobyte |
| Offsite backup copy | Cloudflare R2 bucket or remote SFTP repository |
One backup job can then write to the local repository and mirror each successful snapshot to the offsite repository.
Common mistakes
- Keeping the live data and primary repository on the same physical disk
- Calling a second copy "offsite" when it is still in the same building
- Storing every copy under the same provider account without any separation
- Forgetting to protect the recovery key or imported repository password
- Never testing restores