Comparison tables rank object storage on one figure, and backup planning built on that figure produces a bill nobody forecast and a recovery time nobody can meet. Requests, retrieval and thaw latency are the terms that matter for a destination you will one day read back in full. This works through all four, and the lifecycle rules that quietly delete things on schedule.
Object storage is priced on four axes, and backup planning that looks at only the first one produces bills that arrive as surprises. Storage per gigabyte is the number everyone compares. Request charges, retrieval fees and egress are the ones that decide what a restore costs, which is the moment you least want a finance conversation.
The Four Charges
Storage. Per gigabyte per month, the number in every comparison table. Lowest for archival classes.
Requests. Per thousand operations, for PUT, GET, LIST and lifecycle transitions. Irrelevant for a few large objects, significant for millions of small ones, which is exactly what a file-level backup of a mail store or a document system produces.
Retrieval. Charged by some archival classes when you read data back, sometimes with a minimum billable object size and a delay before the object is available at all. This is the charge that does not exist until the day you need it.
Egress. Per gigabyte leaving the provider's network. For a backup this is the restore path, so egress pricing is effectively a tax on recovery.
A backup destination should therefore be evaluated on the restore, not the upload. Ten terabytes sitting cheaply is worth nothing if pulling it back costs four figures and takes two days.
The Archival Trap
Archival storage classes are genuinely cheap per gigabyte and carry conditions that interact badly with backup retention.
| Condition | Why it bites a backup |
|---|---|
| Minimum storage duration | Deleting early is billed as if you kept it; short retention pays twice |
| Minimum billable object size | Many small files are billed at a floor each, inflating a file-level backup |
| Retrieval fee per gigabyte | A full restore adds a charge nobody modelled |
| Restore latency | Objects must be thawed before reading, adding hours to recovery time |
| Per-object thaw requests | Millions of objects means millions of billable requests to restore |
The pattern that works: recent backups in a standard class where restore is immediate and cheap, older backups in an archival class where you accept latency because you will probably never read them. The pattern that fails: everything archival to minimise the storage line, then a recovery time objective that the thaw latency alone cannot meet.
Check the archival latency against your objective before choosing the class. If recovery must happen in four hours and objects take twelve to become readable, the class is wrong regardless of price.
Lifecycle Rules as the Retention Mechanism
Lifecycle rules move and expire objects by age without anybody running a script, which makes them the right place to implement retention rather than a cron job that can silently stop.
{
"Rules": [{
"ID": "backup-tiering",
"Filter": { "Prefix": "backups/" },
"Status": "Enabled",
"Transitions": [
{ "Days": 30, "StorageClass": "STANDARD_IA" },
{ "Days": 90, "StorageClass": "GLACIER" }
],
"Expiration": { "Days": 1095 }
}]
}Two cautions. Transitions are billed per object, so tiering millions of small objects costs a request charge for each one, and that transition bill can exceed the storage it saves. Consolidate into archives before uploading where the backup tool allows it.
And expiration deletes. A rule with the wrong prefix or an off-by-one retention deletes backups on schedule, quietly and permanently. Test a new lifecycle rule against a prefix holding disposable objects first, and verify that the retention it implements matches the one your policy requires. Our guide to backup retention policies covers deciding those numbers before encoding them.
Versioning and Lock Are Separate Features
Versioning keeps previous copies when an object is overwritten or deleted, which protects against a bad backup overwriting a good one. It does not protect against an attacker with credentials, who can delete versions and empty the bucket.
Object lock is the feature that does, by making objects undeletable for a retention period even by the account owner. That distinction matters because a backup destination reachable with production credentials is the first thing ransomware operators go for. Our guide to immutable backups against ransomware covers the two lock modes and the dwell-time problem that decides the retention period.
Note that versioning interacts with lifecycle in a way that surprises people: with versioning on, deleting an object creates a marker and keeps the old versions, which continue to be billed. Non-current version expiration rules are what actually reclaim that space, and without them a bucket grows forever while appearing to have had things deleted from it.
The Restore You Should Price
Before committing a backup set to a destination, do the arithmetic on the worst realistic recovery: a full restore of the largest system from the oldest retained backup.
Add the retrieval fee for the whole set, the request charge for thawing every object, the egress for pulling it to wherever it will be restored, and the time the thaw adds. Then compare that against the annual storage saving from the cheaper class. For backup sets in the low terabytes, the saving is frequently smaller than one restore, which makes the archival class a false economy.
Also price the restore path. Pulling ten terabytes back over the internet takes as long as the bandwidth allows, and a restore into the same provider's compute is faster and cheaper than a restore to somewhere else, which quietly constrains where you can recover to.
Egress Is the Lock-In
Storage prices are visible and comparable, so they compete. Egress is charged on the way out, so it does not, and it is the mechanism that makes leaving a provider expensive in proportion to how much you trusted them with.
This is worth weighing separately from the monthly rate. A destination with modest storage pricing and no egress charge can be cheaper across a three-year period than one with a lower storage rate and metered egress, and the difference only appears in the year you migrate or the day you restore. Our comparison of the true cost of AWS against cloud servers covers how egress accumulates across a whole estate rather than one bucket.
A Destination Priced for Recovery
The property to want in a backup destination is that restoring is not a decision with a cost attached, because a restore you hesitate over is one you will delay during an incident.
MassiveGRID's backup services use block-level incremental backups with AES-256 encryption at a flat $0.01 per GB, stored on RAID10 in Tier-3 and Tier-4 datacenters with destinations in the US and EU, plus two free VPS snapshots per instance. Block-level incrementals also sidestep the small-object request problem that makes file-level backups expensive on object storage. HA cloud storage covers the case where the backup set itself needs to be highly available, and the platform underneath runs Proxmox high-availability clustering with automatic failover over Ceph storage replicating every block three times across independent NVMe drives.
Backup destinations can be ordered across a partner footprint of more than 700 datacenters in 85 metros, 30 countries and six continents, with auto-provisioning in New York, London, Frankfurt and Singapore, which lets the copy sit in a different jurisdiction from the primary where a residency rule permits it.