Backups are a second rent payment.

Why is backup storage so expensive?

You store the data again, often several times, for as long as the policy says. Daily incrementals, weekly fulls, and yearly archives are separate copies. A second region or a second product stores them again. The source system can shrink and the backup bill will not, until those copies age out.

A thirty-day daily backup is not one extra copy. It is up to thirty, minus whatever your tool deduplicates inside its own format. Dedup inside a backup product is real and useful when the product actually shares blocks across jobs. It is not magic across two vendors, and it does not shrink the one full backup you restore from. Ask the product what it stores after dedup, in bytes, not in a marketing ratio. That number is the capacity line.

Offsite copies are a second bill. The 3-2-1 habit, three copies on two media with one offsite, is a resilience rule. It is also a storage multiplier. The offsite copy may sit in object storage, on tape, or in another region's disk. If the offsite copy is object storage, you inherit that provider's class rules, request prices, and transfer prices. The backup page of a vendor and the pricing page of the cloud are both required reading. Neither one is a substitute for the other.

People notice backup cost when the primary estate was cleaned up and the backup estate was not. Legal retention, ransomware recovery windows, and customer contracts keep copies long after the source is gone. That can be correct. It can also be a policy nobody reread. List the generations you are required to keep. Everything else is optional bytes. Compression applies to both lists. Deletion applies only to the optional one.

Should I put backups in Glacier or another cold tier?

Use a cold tier for backups you will keep longer than that tier's minimum duration and that you rarely restore. S3 Glacier Flexible Retrieval and Deep Archive bill minimum durations, documented on the S3 pricing page. Short-lived dailies can cost more in a cold class than in a standard class. Read the page before you move them.

AWS documents a 90-day minimum for Glacier Instant Retrieval and Glacier Flexible Retrieval, and 180 days for Glacier Deep Archive. Objects deleted or transitioned early are still charged for the rest of the window. Backup tools such as Veeam repeat that warning and recommend archive retention of at least those lengths. A seven-day backup rotated into Deep Archive is a way to buy a fee. Keep short generations on a class meant for short generations. Archive the monthly and yearly copies if you truly will not restore them often.

Restore cost and restore time are the other half. A cold class can be inexpensive while it sits and unpleasant when you need it, because retrieval has its own price and its own delay. A ransomware drill that restores everything is an egress and retrieval event, not a storage event. Price one full restore on the current page before you congratulate the archive project. If the drill is unaffordable, the archive is unaffordable, no matter how small the idle line looks.

Azure Blob archive and Google Cloud archive classes have their own early-deletion and retrieval rules. Do not copy an S3 minimum into an Azure design. Open the Azure Blob pricing page and the Cloud Storage pricing page and read the early deletion section for the class you mean. The pattern is the same. The numbers are theirs.

Should I compress backups before I tier them?

Compress when the backup still contains compressible bytes and every retained copy should be smaller. Tier when the remaining bytes are cold. Many backup formats already compress or deduplicate. A second pass may do little. Measure a real restore chain. Shrinking first means the cold copy and the restore are both smaller.

Backup software often compresses inside its own container. If the container is already dense, another lossless pass will not move it, and you have added a decompressor to the restore path for nothing. If the product stores uncompressed images, database dumps, or logs, a pass before the product, or a better setting inside it, changes every generation you keep. Test restore, not only size. A backup you cannot restore is not cheaper. It is missing.

Order is the money. Bytes you shrink before they land in the archive class occupy less of that class and take less to retrieve later. Bytes you tier first and compress never are full-size for the whole retention. Do not pay a transition request to move data you are about to rewrite. Expire, then compress what remains, then tier what is actually cold. The S3 lifecycle docs are clear that transitions are not free of request charges.

Dedup, compression, and tiering answer different questions. Dedup removes repeated blocks across saves. Compression makes each remaining block smaller. Tiering changes what you pay to hold the result. A design review that picks only one of them will leave money in the other two. The comparison page sets them side by side. None of them is a reason to invent a savings percent for a customer we have not measured.

What should a backup cost review include besides disk?

Include restore time, retrieval and egress on a full recover, request charges, and the minimum duration of the class. Include the decompressor if the backup is compressed, because the bytes you store are not the whole restore story. A cheap idle copy that you cannot afford to read is not a cheap backup.

Write two numbers from your own bill: what you pay to keep the chain this month, and what you would pay to restore the largest generation once. The second number is retrieval plus transfer plus time. If you have never priced it, the archive decision is incomplete. Use the provider calculator or the pricing page, with the date on the printout. Our calculator covers storage rate and egress rate only, and only at a ratio you type. It will not model Glacier retrieval tiers. Do not ask it to.

Operational cost sits beside the invoice. Someone has to test restores. Someone has to keep the keys and the decompressor. A format only one vendor can read is a retention risk if the vendor changes the product. Lossless compression that you can run yourself, or that we can measure on a sample, should end with a file you can restore without a phone call. If we compress a sample for you, the report includes whether the original bytes came back. That is the whole promise.

Then revisit retention with whoever asked for seven years. Sometimes the answer is a contract and the copies stay. Sometimes the answer was a guess in a runbook. Cutting generations you do not need is the largest honest saving in backup, and it does not require us. Shrinking the generations you do need is the part we can measure. Send a sample of the backup, not of an unrelated dataset.

A practical order of work.

1. 1. Count generations

   List daily, weekly, monthly, and yearly copies you are required to keep, and the copies you keep from habit. Note which product holds each, and whether it already deduplicates or compresses.

2. 2. Price one restore

   Using the current provider pricing page, estimate retrieval and transfer for restoring the largest copy once. Write down the date you read the page.

3. 3. Match class to lifetime

   Keep short-lived copies out of classes with a long minimum duration. Archive only copies you will keep past that minimum and rarely read.

4. 4. Measure a real chain

   Take a sample of the backup as stored. See whether another lossless pass shrinks it and whether the original restores. Do not apply the enwik9 ratio to the chain.

Questions.

Provider docs, not our price list.

• Amazon S3 pricing, including Glacier minimum duration
• S3 Lifecycle, transitions, and expiration
• Azure Blob Storage pricing
• Google Cloud Storage pricing

Links checked Oct 21, 2026. Rates and rules on those pages can change.