Best Cloud Backup & Storage: Recovery, Retention & Costs

Cloud storage for developers can mean several different things: object storage for application assets, file synchronization for working documents, offsite backup repositories, or long-term archives. Those are related use cases, but they are not interchangeable.

A production backup strategy should answer four questions: what is protected, how often it is copied, how far back you can recover, and how quickly you can restore it. Storage price matters, but versioning, retention, immutability, API support, retrieval costs and restore testing matter just as much.

Last verified: September 26, 2026. Storage pricing, free-egress allowances, minimum-retention rules and object-lock behavior can change; verify the live provider documentation before production migration.

1. Developer Cloud Storage & Backup Platforms Matrix

For a direct object-storage pricing and egress comparison, see Cloudflare R2 vs DigitalOcean Spaces vs Amazon S3.

2. Object Storage vs Sync vs Backup vs Disaster Recovery

• Object storage: stores objects/files through APIs. It is a storage primitive, not automatically a backup strategy.
• File sync: keeps copies in sync across devices or locations. Sync can also propagate accidental deletion or corruption.
• Backup: creates recoverable historical copies according to retention rules.
• Server snapshot: captures a point-in-time state of a VM/disk, often inside the same provider/control plane. Useful for rollback, but not automatically an independent offsite backup.
• Replication: copies data to another location or system, often for availability. Replication can also propagate corruption or deletion.
• Disaster recovery: includes the people, procedures, infrastructure and tested steps required to restore service.

Moving production data into cloud object storage does not automatically create an independent backup. If the same credentials or automation can delete both the source and the only stored copy, the recovery design is still fragile.

Minimum recovery design questions

• Failure domain: can loss of the production account/provider/host also remove the backup?
• Credential domain: can one compromised key delete both production and every backup version?
• History: can you recover from an earlier point after corruption or accidental deletion?
• Integrity: do you verify archive/database validity and retrieved bytes?
• Restore path: is there a documented, tested way to rebuild service in an isolated environment?
• Keys: are encryption keys/recovery credentials stored independently from the data they unlock?

3. Developer and Website Backup Use Cases

• Database dumps: MySQL/MariaDB/PostgreSQL exports stored off-host.
• WordPress files: uploads, themes, plugins and configuration snapshots.
• VPS configuration: Nginx/Apache, systemd, firewall and application configuration.
• n8n and automation assets: workflow exports, credentials backups where supported, generated files and database backups.
• CI/CD artifacts: build outputs, release packages and deployment exports.
• Media/assets: large image, video or downloadable-file repositories.
• Logs and exports: retained operational data that may need historical recovery.

For application object storage rather than backup policy, use the Amazon S3 vs Cloudflare R2 vs DigitalOcean Spaces comparison.

4. Inventory What Must Be Recoverable

Before choosing a provider, write down the actual recovery set. A website backup can be unusable if it contains the database but omits uploads, application configuration, encryption keys, DNS/proxy configuration or deployment version information.

5. Define RPO and RTO Before Choosing Storage

RPO (Recovery Point Objective) describes how much recent data loss the business can tolerate. RTO (Recovery Time Objective) describes how long service restoration can take.

For example, a database that can lose at most 15 minutes of transactions needs a different backup cadence from a static archive that changes once per month.

Do not invent RPO/RTO values from generic templates. Set them from business and operational requirements, then design backup frequency, retention and restore tooling around those targets.

6. Safer Linux Backup Automation With mysqldump, Integrity Checks and rclone

Do not hard-code a database password directly into a shell script or command line. Use a protected MySQL option file, socket authentication or a secret-management method appropriate to the environment.

For InnoDB, MySQL documents --single-transaction as a way to obtain a consistent logical snapshot without table locks, and recommends combining it with --quick for large tables. This does not make every storage engine transactionally consistent, and schema-changing DDL during the dump can still interfere with the operation.

#!/usr/bin/env bash
set -euo pipefail
umask 077

DB_NAME="production_wp"
BACKUP_DIR="/var/backups/mysql"
REMOTE_DIR="backup-remote:project-backups/mysql"
TIMESTAMP="$(date -u +'%Y%m%dT%H%M%SZ')"

mkdir -p "$BACKUP_DIR"

ARCHIVE="${BACKUP_DIR}/${DB_NAME}_${TIMESTAMP}.sql.gz"
MANIFEST="${ARCHIVE}.sha256"
TMP="${ARCHIVE}.partial"

cleanup() {
  rm -f "$TMP"
}
trap cleanup EXIT

# Credentials come from a protected client option file / socket auth.
mysqldump   --single-transaction   --quick   --routines   --events   --triggers   --databases "$DB_NAME" | gzip -9 > "$TMP"

# Fail locally before upload if the gzip stream is invalid or empty.
test -s "$TMP"
gzip -t "$TMP"

mv "$TMP" "$ARCHIVE"

(
  cd "$BACKUP_DIR"
  sha256sum "$(basename "$ARCHIVE")" > "$(basename "$MANIFEST")"
)

# Copy: do not use sync unless remote deletion mirroring is intentional.
rclone copy "$ARCHIVE" "$REMOTE_DIR/" --retries 3
rclone copy "$MANIFEST" "$REMOTE_DIR/" --retries 3

# Compare the newly uploaded object against the local source.
rclone check "$BACKUP_DIR" "$REMOTE_DIR/"   --include "$(basename "$ARCHIVE")"   --one-way

printf 'backup_ok archive=%s manifest=%s
' "$ARCHIVE" "$MANIFEST"

Do not delete the local staging copy merely because the upload command exited successfully. First validate the archive, transfer result and remote object. Then apply local retention separately.

rclone check compares file sizes and hashes where the destination supports compatible hashes. For a stronger retrieval-path test when hashes are unavailable, rclone check --download can compare by downloading data, but that increases transfer time and may create egress/retrieval charges.

Schedule the job only after running it manually and intentionally testing a failure path—for example, an unavailable remote or rejected credentials. A systemd service/timer can make exit status and logs easier to inspect than silently discarded cron output.

7. Test Failure Behavior, Not Just the Happy Path

A backup system should fail loudly when any critical stage fails. Test at least these scenarios in a non-production environment:

• Database dump command fails.
• Local disk fills up.
• Archive integrity check fails.
• Remote credentials are revoked.
• Remote bucket/path is unavailable or misconfigured.
• Upload succeeds but the remote object cannot be read back.
• Retention policy prevents expected cleanup.
• Encryption key/recovery credential is unavailable.

Use set -euo pipefail, explicit validation commands and monitoring that alerts on non-zero exit status. Avoid scripts that print “backup complete” after only the first successful step.

The recovery process should also be able to identify the newest verified recovery point rather than blindly selecting the newest object by timestamp.

8. 3-2-1 and 3-2-1-1-0 Backup Strategies

The familiar 3-2-1 strategy is a planning framework: keep three copies of important data, on two different types of storage/media, with one copy offsite.

Some backup teams extend this to 3-2-1-1-0:

1. 3 copies: production plus two backup copies.
2. 2 storage/media types: reduce common-mode failure.
3. 1 offsite copy: protect against site-level loss.
4. 1 immutable/offline copy: reduce the risk of destructive changes reaching every backup.
5. 0 unverified backups: verify jobs and perform restore tests so failures are discovered before an incident.

This framework is useful, but it is not a guarantee. Recovery still depends on valid data, retention design, credentials, documentation, compatible software and tested restoration procedures.

9. Provider Notes That Affect Backup Design

Backblaze B2

Backblaze currently lists B2 Pay-As-You-Go starting at $6.95/TB-month, with the first 10 GB storage free. B2 includes egress up to three times average monthly storage; egress above that is $0.01/GB unless a partner-free path applies. PAYG Class A/B/C API calls are currently free; Class D is $0.004 per 10,000 calls after the first 2,500 calls per day. B2 Object Lock supports governance and compliance modes: governance can be overridden by appropriately privileged keys, while compliance retention cannot be removed before expiry.

Wasabi

Wasabi currently lists PAYG starting at $7.99/TB-month with a 1 TB monthly minimum. Egress and API requests do not have normal separate line-item charges, but Wasabi's published policy says workloads where monthly egress is less than or equal to active storage are a good fit. PAYG also has a 90-day minimum storage duration, so deleting or rotating objects early can still create timed-deleted-storage charges.

Amazon S3 and S3 Glacier storage classes

For new archival workloads, AWS recommends the S3 Glacier storage classes rather than the older standalone Amazon Glacier vault API. Current AWS documentation lists 90-day minimum storage durations for Glacier Instant Retrieval and Glacier Flexible Retrieval, and 180 days for Glacier Deep Archive. Flexible Retrieval and Deep Archive also require restore workflows before archived objects are directly accessible.

Google Cloud Storage

Google Cloud supports both bucket-level retention locks and object-level retention locks. A locked bucket retention policy cannot be reduced or removed. With Object Retention Lock, a locked object's retain-until time cannot be reduced or removed either. Apply these controls with change control and a tested recovery plan because the lock is intentionally difficult or impossible to reverse.

10. Dated Cost Illustration: 2 TB Stored, 500 GB Restored per Month

This is an illustrative September 26, 2026 calculation, not a quote. It uses published starting PAYG rates and excludes taxes, support, special regions, request patterns, early-deletion effects and negotiated discounts.

The cheaper row can change when object churn, minimum-duration charges, transaction mix, region, archive retrieval, support or restore frequency changes. Model the recovery workload, not only steady-state capacity.

11. Versioning, Retention and Immutability Are Different Controls

• Versioning: keeps older object versions after replacement/deletion events, but can increase storage cost and may not protect against every bucket-level failure or credential scenario.
• Retention policy: prevents deletion/replacement until an age or retain-until rule is satisfied.
• Object Lock / locked retention: makes selected retention settings harder or impossible to shorten, depending on provider and mode.
• Independent copy: reduces common-mode risk by placing recovery data outside the same account, credentials or provider where appropriate.

Use the control that matches the threat model. A versioned bucket is not automatically immutable, and an immutable bucket is not automatically a complete disaster-recovery plan.

12. Backup Storage Decision Matrix

13. Restore Testing Is Part of the Backup

A backup job can report success while producing incomplete, corrupted or operationally unusable data. Schedule restore tests for representative systems.

• Restore a database into an isolated environment and confirm it opens cleanly.
• Verify application files, ownership and permissions.
• Compare checksums, object counts or file sizes where appropriate.
• Check that encryption keys, recovery codes and credentials needed for recovery are available independently.
• Measure actual recovery time against the required RTO.
• Confirm the recovered point meets the intended RPO.
• Document the restore steps so recovery does not depend on one person.
• Record test date, result, failure reason and remediation.

For critical systems, test both a small-file recovery and a full-service recovery path. A backup that has never been restored is an assumption, not verified recovery capability.

Example isolated database restore drill

Do this only on a disposable server/container or dedicated recovery database—not against production.

RESTORE_DIR="$(mktemp -d)"
REMOTE_DIR="backup-remote:project-backups/mysql"
ARCHIVE_NAME="production_wp_YYYYMMDDTHHMMSSZ.sql.gz"

rclone copyto   "${REMOTE_DIR}/${ARCHIVE_NAME}"   "${RESTORE_DIR}/${ARCHIVE_NAME}"

rclone copyto   "${REMOTE_DIR}/${ARCHIVE_NAME}.sha256"   "${RESTORE_DIR}/${ARCHIVE_NAME}.sha256"

(
  cd "$RESTORE_DIR"
  sha256sum -c "${ARCHIVE_NAME}.sha256"
  gzip -t "$ARCHIVE_NAME"
  gunzip -c "$ARCHIVE_NAME" > restore.sql
)

# Run only against an isolated recovery database/server.
mysql --defaults-extra-file=/root/.mysql-restore.cnf < "${RESTORE_DIR}/restore.sql"

Then verify application-specific invariants: expected tables, representative row counts, critical records, restored uploads, decryptable secrets/credentials where applicable, and a harmless application read/write test. Record the elapsed recovery time instead of assuming it meets the RTO.

14. Local Recovery Drill Included With This Update

To make the recovery concept executable without pretending Digital Bhatti tested a cloud provider, this update includes a small local drill kit. It:

1. Creates deterministic fixture files.
2. Records SHA-256 checksums.
3. Builds a compressed archive.
4. Verifies the archive.
5. Copies it into a separate simulated backup repository.
6. Deletes the working source directory to simulate loss.
7. Restores the archive into a new location.
8. Rechecks every original file checksum.

This proves the supplied local archive/integrity/restore script mechanics work. It does not prove cloud-provider durability, production database consistency, egress speed, RPO or RTO. Those still require a provider-specific recovery test.

Summary: Cloud Storage & Backup Checklist

• Separate object storage, sync, backup and disaster recovery requirements.
• Define RPO and RTO before choosing retention and backup frequency.
• Keep more than one recoverable copy of important data.
• Use offsite storage for site-level failure scenarios.
• Use immutability or offline/isolated copies where the threat model justifies it.
• Do not embed production passwords directly in shell scripts.
• Choose rclone copy vs sync deliberately; sync can mirror deletions.
• Model egress, retrieval and minimum-storage-duration rules.
• Validate archive/database integrity before upload.
• Verify remote object presence/hash where the tooling supports it.
• Monitor backup-job failures and alert on non-zero exit status.
• Intentionally test a failed upload/credential scenario.
• Test restores on a schedule.
• Document the recovery procedure.
• Record the newest verified recovery point, not merely the newest uploaded object.
• Recheck provider pricing and retention behavior before major migrations.

For host-level protection around the backup source, see the Linux VPS Security Hardening Guide. For self-hosted automation that generates or transfers backup data, see How to Self-Host n8n with Docker.

Frequently Asked Questions

Is cloud object storage the same as a backup?

No. Object storage is a storage platform. It becomes part of a backup strategy only when you create recoverable historical copies with appropriate retention, monitoring and restore procedures.

What are RPO and RTO?

RPO defines how much recent data loss is acceptable; RTO defines how long recovery may take. They should be set from business requirements rather than copied from a generic template.

Is Backblaze B2 egress free?

Backblaze currently includes free egress up to three times average monthly storage for B2, with standard overage rules applying beyond that except for certain partner paths.

Does Wasabi really have free egress?

Wasabi's current PAYG model does not add a normal per-GB egress line item, but its published usage policy says monthly egress less than or equal to active storage is a good fit. PAYG also has a 1 TB monthly minimum and 90-day minimum storage duration.

Should I use Amazon Glacier for new backups?

For new archival workloads, AWS recommends S3 Glacier storage classes rather than the older standalone Amazon Glacier vault service/API.

Does Object Lock guarantee ransomware protection?

It can materially reduce deletion or overwrite risk during the retention period, but only when configured correctly. Credentials, retention mode, provider behavior and recovery procedures still matter.

How often should backups be tested?

Use a schedule that matches the risk and recovery requirements of the system. The important point is to test restores before an incident rather than assuming a successful backup job equals a successful recovery.

Is a successful rclone upload proof of a good backup?

No. Validate the archive/database first, check the transferred object with hashes or a retrieval test where appropriate, monitor exit status, and periodically restore the data into an isolated environment. Upload success alone does not prove recoverability.

Should I use rclone copy or sync for backups?

copy is usually safer for append-style backup workflows because it does not intentionally make destination deletions mirror source deletions. Use sync only when mirrored deletion is part of the design and independent history/immutability protects recovery points.

Can I lock a retention policy immediately for years?

That can create an expensive or operationally irreversible mistake. Test retention with short non-production policies first, confirm permissions and restore/deletion behavior, then apply longer governance/compliance retention only when the requirement is understood.

Written by

Abdul Shakoor

Founder of Digital Bhatti, an independent technical publication focused on web hosting and infrastructure, WordPress, technical SEO, web performance and automation.

This guide is documentation-led. It does not claim a Digital Bhatti cloud-provider throughput, durability, RPO or RTO benchmark unless the exact dataset, provider/region, storage class, transfer path and repeated recovery evidence are explicitly published.

• About Digital Bhatti • Contact