ThomasMoore157

Posted on Nov 3

Compare Scalable Object Storage Services for App Backups — Tenant Deletion Controls

#storage #backups #sre #dataretention

A backup alert is often the first visible symptom of a retention design that was wrong weeks earlier. To compare scalable object storage pricing for app backups, start with what the on-call sees: an export job stuck, a bucket growing faster than forecast, or a tenant deletion that appears complete while old image versions remain recoverable.

Short answer: compare scalable object storage by the full lifecycle of a logistics image, not by the headline storage rate. The least complex design that usually survives this problem is an immutable backup stream with an explicit tenant manifest, a separate export path, measured retention transitions, and a deletion workflow that knows about versions and replicas.

For continuous app data backups, the important price is the cost of keeping the required recovery points, moving them between storage classes or regions, reading them during a restore, and proving that a tenant's data was deleted. A lower per-gigabyte figure can lose quickly if retrieval, lifecycle transitions, or deletion verification consume operational attention.

The alert that should have fired earlier

Imagine the page arrives at 02:13. A logistics customer is waiting for a tenant-scoped export of product images, and the job has crossed its 20-minute SLO. The export worker reports no application error. Object storage is healthy. The useful clue is elsewhere: the tenant's retention ledger says 30 days, while the object inventory shows current objects, noncurrent versions, incomplete multipart uploads, and a second copy in a recovery region.

That is an alerting problem, but it starts as a data-model problem. An image needs an owner, tenant identifier, creation time, backup generation, retention deadline, deletion state, and export eligibility. The object key can help operators find a record, but it should not be the only record. Keys get copied into manifests; manifests get rebuilt; version identifiers outlive assumptions about filenames.

My capacity-planning reflex is to model bytes and objects separately. A modest logical image volume can still create a large object count through thumbnails, manifests, multipart fragments, and backup generations. I would track logical bytes per tenant, daily changed bytes, recovery-point count, export read bytes, and deletion backlog. The first four forecast capacity and recovery cost. The last one tells me whether erasure is falling behind.

The threshold should page on projected failure, not only current usage. Alert when retained bytes are forecast to exceed the approved envelope within 14 days, or when the oldest pending deletion approaches its deadline. Those are control signals. A bucket-size alarm alone arrives after the operator has few good choices.

The first false positive is cheap: someone inspects a dashboard. The tenth is not. If the threshold ignores tenant growth bursts, it trains the team to mute the alert; if it fires on every short-lived export spike, it hides the retention breach that matters.

The page is a symptom.

Measure the gap.

How do scalable object storage services change backup pricing?

Start with a workload sheet, not a vendor shortlist. For each candidate, record the storage meter, request meters, lifecycle-transition charges, retrieval charges, network charges, minimum-duration rules, replication choices, and the evidence needed to verify deletion. Keep units consistent: GiB-month for retained data, bytes for transfers, requests for operations, and engineer-hours for controls the service does not provide.

AWS S3, Azure Blob Storage, and Google Cloud Storage expose multiple storage classes and lifecycle controls, but their meters and class boundaries differ. Backblaze B2 publishes a separate pricing model. Compare all four against the same workload sheet and current regional terms. The useful difference is the shape of the bill and the recovery contract, not which number looks smallest in isolation.

A simple monthly model is:

package main

import "fmt"

type Workload struct {
    RetainedGiB float64
    StorageRate float64
    RequestCost float64
    LifecycleCost float64
    RetrievalGiB float64
    RetrievalRate float64
    NetworkGiB float64
    NetworkRate float64
    ControlHours float64
    EngineerHourRate float64
}

func monthlyCost(w Workload) float64 {
    return w.RetainedGiB*w.StorageRate + w.RequestCost +
        w.LifecycleCost + w.RetrievalGiB*w.RetrievalRate +
        w.NetworkGiB*w.NetworkRate + w.ControlHours*w.EngineerHourRate
}

func main() {
    w := Workload{RetainedGiB: 1000, StorageRate: 1}
    fmt.Printf("modeled monthly cost: %.2f\\n", monthlyCost(w))
}

The sample is a model, not a quote. Populate it with current, region-specific terms and measured workload. Daily changed bytes, version cleanup, export frequency, and restore tests should be separate inputs. A price sheet that assumes constant retention is not a capacity plan.

Deletion deserves its own line item because it has two meanings. Application deletion removes the tenant from normal reads. Retention deletion removes every object and version that policy covers. Legal erasure may also require deletion from replicas, indexes, manifests, caches, and exported copies. GDPR Article 17 describes a right to erasure with exceptions, so the workflow needs a policy decision and audit record rather than an unqualified promise that every byte disappears instantly.

What must the storage layer preserve?

Continuous backups need a stable recovery boundary. An image object, its metadata, and the manifest that makes an export reproducible should share a backup generation or transaction marker. Otherwise an export can contain a new database row pointing to an image that was not included in the corresponding object snapshot. That is a consistency bug, not a storage-rate problem.

Versioning changes the deletion conversation. In S3, enabling versioning means a delete operation can add a delete marker while older versions remain; those versions must be addressed by version identifiers for permanent removal. The same hazard exists wherever historical versions or soft-delete retention are enabled: listing current keys is not proof of erasure.

I would keep a tenant deletion record with requested time, policy basis, cutoff time, expected object count, completed object count, remaining versions, replica status, and verification time. The worker can retry idempotently because each object-version deletion is identified explicitly. A periodic inventory or equivalent reconciliation closes the gap between successful API responses and the actual retained set.

The export path should read from a manifest generated after retention and authorization checks. It should write to a destination with its own expiry, mark the export as tenant-scoped, and avoid silently becoming a second permanent archive. A successful export can recreate data that a deletion workflow just removed from the primary archive.

That last failure deserves a concrete test because it crosses ownership boundaries. Suppose a tenant requests an export at 10:00, the archive deletion starts at 10:05, and the export worker finishes at 10:07 after reading a manifest created before deletion. The archive can report success while the exported package still contains the regulated image set. The fix is to bind the manifest to a retention cutoff, record the export copy as another governed object, and reject a package whose source generation is no longer eligible. This is more work than deleting a key, but it is also the only way to make the terminal state observable.

Buy, build, and the operational bill

The managed-versus-self-hosted decision is mostly an on-call decision with a storage component. A managed object service usually gives a maintained object API, lifecycle controls, identity integration, and audit surfaces, but the team still owns policy composition, manifests, export correctness, and cost modeling. Self-hosting may fit an existing platform, but the team then owns disk failures, replication repair, capacity expansion, upgrades, and deletion across every copy.

Choice	You buy	You still operate
Managed object storage	A maintained object API and service controls	Retention ledger, export workflow, reconciliation, and spend controls
Self-hosted object storage	Control over placement and integration	Hardware lifecycle, replication, capacity, upgrades, and recovery drills
Hybrid archive	A separate failure and cost boundary	Classification, movement rules, two operational planes, and deletion parity

Choose the option whose worst month can be explained before it happens. Test a tenant growth spike, a restore during an incident, a region loss, an export burst, and a deletion backlog. A platform team that cannot observe those paths will eventually pay in emergency work, regardless of the storage rate.

SLOs make the trade-off concrete. Set one for backup freshness, one for export completion, one for restore readiness, and one for deletion processing. Do not combine them into a single availability number. A service can meet backup freshness while missing the tenant export SLO; it can complete deletion requests while failing to reconcile old versions.

Instrument the path before changing the threshold

The corrected instrumentation follows the alert backwards: record requested and completed export timestamps; count eligible, copied, skipped, and failed objects; attach tenant and policy labels with cardinality controls; measure backup freshness by tenant; and expose deletion age for the oldest outstanding object version.

Then run controlled tests. Create an image, generate a backup generation, export it for one tenant, expire the policy, and verify that the expected current object, historical version, manifest, replica, and export copy each reach the intended terminal state. Repeat with a retry at every step. The test should fail loudly if a duplicate object is counted twice or if an export points at a deleted generation.

Do this before tuning the page. Otherwise the team is arguing about noise while the system lacks the measurements needed to distinguish an export delay from a retention breach.

The practical comparison for 2026 is a worksheet plus a failure exercise. Published pricing pages describe the meters, but the application still has to test its retention and export controls against those meters. The design must restore the right tenant, delete the right copies, and explain the bill without guesswork.

DEV Community