R2 vs B2 vs S3: Choose Your Backup Target

Choose the target that fits your recovery workload

For a single VPS running Ubuntu 24.04 LTS, we would start with Backblaze B2 and an encrypted backup repository. It is a sensible default when retained data dominates your usage and restores are occasional. Choose R2 when repeated downloads materially change that workload, or S3 when using existing AWS administration saves you meaningful work.

B2 provides immediately accessible storage without minimum storage duration requirements. Its included download allowance depends on average stored data, so repeated recovery attempts can change the bill. Check your expected recovery workload against the official B2 billing details before treating downloads as an unlimited entitlement.

R2 removes direct egress bandwidth billing, but storage and requests still contribute to cost. R2 Infrequent Access also adds retrieval billing and minimum storage duration conditions. Those distinctions are documented in Cloudflare's R2 billing documentation, and they are why we would begin with Standard for an active backup repository.

S3 earns its place when your team already understands AWS identity policies and account administration. Familiar controls can be worth more than a smaller storage bill. If AWS would be a new operational dependency introduced only for backups, we would need a specific requirement to justify it.

Estimate retained data and recovery activity separately

The cheapest object storage for backups depends on what your backup software actually leaves behind. Your VPS disk usage is a poor substitute for repository size because exclusions and compression change the upload, while historical snapshots increase retained data. Deduplication helps when snapshots share content, but its effect depends on the files you produce.

Build an estimate for routine operation and a separate estimate for a failed server. Include scheduled verification in routine operation because reading backup data consumes requests and transfer even when nothing has broken. For recovery, allow for an interrupted download or a second attempt after discovering a missing dependency.

• Retained storage: repository data after your intended retention policy, plus any provider-held historical object versions.
• Write activity: new backup data and maintenance operations that rewrite repository objects.
• Read activity: integrity checks, pruning that downloads data, and application restore drills.
• Recovery traffic: the data needed to rebuild elsewhere, including a plausible retry.

For storage-heavy workloads, B2 is our first candidate to evaluate for lower ongoing cost. R2 deserves a closer look when downloads are a substantial part of the workload. Neither conclusion removes the need to inspect actual usage after your retention policy has settled.

Include operator time in the decision, especially if the repository is small. Moving a functioning backup system to save a modest amount can create more work than it removes. Establish a dependable schedule with the DIY VPS backup procedure before optimizing the destination.

Keep the recovery copy in immediately readable storage

A backup repository is an active data structure, even when most of its contents rarely change. Your tool may need old data during verification or maintenance. Moving objects into an archive class can therefore affect ordinary operation before you ever attempt disaster recovery.

S3 Standard supports direct reads, while Glacier Flexible Retrieval and Glacier Deep Archive require an archive restoration step before objects become readable. Glacier Instant Retrieval behaves differently and supports direct access. The S3 storage class documentation explains these distinctions and the associated retention conditions.

We would keep the primary repository in immediately readable storage until a complete restore procedure exists. Use delayed archive storage for a separate, deliberately designed archive whose recovery deadline permits waiting. Avoid adding a blanket lifecycle transition to an existing repository simply because its objects look old.

Minimum storage duration conditions also matter when pruning removes or replaces recently written objects. Frequent repository maintenance can undermine the apparent saving from a colder storage class. Decide using the repository's access behavior, rather than the assumption that every backup is rarely read.

Let your backup tool control repository retention

Choose the backup format before configuring bucket lifecycle rules. We would use restic for this object-storage workflow because it provides encrypted snapshots and supports these destinations through appropriate backends. If the tool decision is still open, use the backup tool comparison to settle it before creating production repositories.

For B2, restic currently recommends the S3-compatible interface over its native B2 backend. Its documentation also explains that deletions through this interface can leave hidden historical versions occupying storage. Follow the restic repository setup guidance when choosing the interface and the corresponding handling of hidden versions.

Never expire live repository objects solely by their age. A recent snapshot can reference a data object uploaded much earlier, so an age-based deletion rule can damage snapshots you intended to retain. Let the backup tool determine which repository data is no longer referenced.

Distinguish cleanup of provider-held historical versions from deletion of current repository objects. Keeping historical versions may support recovery from unwanted deletion, but it also means repository pruning might not reduce billed storage immediately. If you shorten that history to control storage growth, document the recovery protection you are giving up.

Separate backup credentials from deletion authority

Keep the bucket private and scope the server's credentials to its backup repository. A credential limited to a bucket can still destroy that bucket's contents if it includes deletion permission. Scope limits the damage area; it does not automatically make your backups resistant to a compromised server.

Where the provider and backup tool support it, keep retention administration outside the production host. Verify the permissions required by ordinary backup operations before removing delete access, because tools may need to remove temporary repository locks. A generic write-only policy is not a substitute for a documented, compatible permission model.

Before enabling immutability, verify how the chosen protection handles repository maintenance and which credentials can change it. Exercise backup creation and pruning against a disposable repository with the intended settings. If protection blocks maintenance, resolve that interaction before trusting the arrangement with production history.

Store the repository password outside the VPS as well as in the protected location used by automation. Access to encrypted objects cannot compensate for a lost password. Keep account recovery material accessible when the server and its local secrets are unavailable.

We recommend Claude Code for drafting backup jobs and reviewing redacted failures within a bounded task. Keep account recovery credentials and retention-changing authority outside its ordinary session, and require approval for destructive maintenance. Apply the same separation described in production guardrails for AI agents.

Verify application recovery before comparing convenience

A successful upload establishes that the destination accepted data. It does not establish that you captured a usable database or can restore ownership correctly. Choose a recovery destination with enough working space, then restore without relying on files that exist only on the original VPS.

For PostgreSQL, create a consistent backup using an appropriate database backup method before uploading it. Copying a running database directory with an ordinary file backup is not a dependable substitute. Follow the PostgreSQL backup and restore drill procedure and verify the recovered application against the restored database.

During the drill, record whether recovery meets your own outage tolerance and which manual steps were missing from the runbook. Check the destination account for unexpected storage growth or request activity afterward. These observations tell you whether your chosen target fits your operations without relying on generic provider speed claims.

If you later move providers, retain the old repository until recovery from the new destination succeeds. Use a tool-supported migration process or pause repository mutations while taking a consistent copy. Copying objects while pruning changes the source can leave the destination incomplete.

Create a disposable repository and complete a restore

Start with B2 unless your workload gives you a concrete reason to choose R2 or S3. Create a private bucket dedicated to a disposable repository, then configure your backup tool using credentials scoped to that bucket. Save the repository password in your recovery password store before uploading representative, non-sensitive files.

Restore the snapshot into a separate empty directory using credentials and the repository password retrieved from your recovery records. Compare restored contents with the originals, and inspect permissions relevant to your application. Use a clean recovery environment when checking that the runbook has no hidden dependency on the source VPS.

Exercise your intended retention policy on the disposable repository and inspect the bucket afterward. Confirm that remaining snapshots still restore and that historical object versions behave as intended. Then create the production repository and schedule its first application restore drill alongside the backup job.