Most companies we work with don’t have a data inventory.

When we ask “where’s your data tracked?” (where it lives, what it contains, who owns it), the answer is usually some version of “we don’t have one.” There’s no comprehensive map of data locations. No business impact assessment for different data types, and accountability is unclear.

You can’t protect what you haven’t inventoried. And you can’t make good decisions about backup strategy when you don’t know what you’re backing up.

Data Has a Half-Life

Not all data ages the same way.

Some data becomes stale quickly. If you’re aggregating information from external sources like market data, business intelligence, or operational metrics, the value is often in the freshness. Yesterday’s data might be useful for trends, but it’s not the crown jewels.

Source data and processed insights need different protection levels. The raw inputs you collect might be recreatable from upstream sources. The analysis and transformations you’ve built on top might take significant effort to reconstruct, or might be regenerated in hours if you have the pipeline intact.

This changes the backup math. If your data pipeline gets destroyed but you can pull from upstream sources and recreate everything within an acceptable timeframe, maybe you don’t need to back up the work product. Maybe you just need to protect the source data and the pipeline itself.

Understanding your data’s half-life helps you spend backup dollars where they actually matter.

The Cost vs. Risk Conversation

Backup costs can reach hundreds of thousands of dollars annually. Cross-region replication, long-term retention, and disaster recovery infrastructure. It adds up fast.

That’s money not going to engineers or product development. A real tradeoff.

The question is: what’s the actual business impact if this data disappears? What’s the downtime cost? What’s your real risk tolerance?

These are executive decisions, not just technical ones. They require someone to say “we’re willing to accept X days of data loss on this system” or “we need to be able to recover this within Y hours, whatever that costs.”

Most organizations avoid making these decisions explicitly. The backup strategy drifts into existence based on whoever set things up initially, the defaults, and what seemed reasonable at the time. Nobody revisits it, and nobody asks hard questions about what’s actually protected versus what people assume is protected.

Then something happens, and everyone discovers the gap between assumptions and reality.

The Ransomware Reality

Protecting cloud data against ransomware is genuinely hard.

The defenses exist. Object Lock prevents tampering, MFA Delete prevents unauthorized removal, and versioning provides clean restore points. It’s effective against ransomware, but each control adds friction to day‑to‑day operations.

You might recognize some of these comments: “I need to delete data frequently for our workflow.” “I can’t add MFA to an automated process.” “Versioning is too expensive for our data volumes.”

Each exception opens another gap. The layered defense becomes like swiss cheese.

Nothing beats backing up to a different cloud with different access patterns. If your AWS root account gets compromised, your AWS backups are compromised too. But if you’re replicating critical data to a separate environment (different cloud provider, different credentials, different access model), then root in one isn’t root in the other.

That’s real protection; it’s also more complex and more expensive than most organizations want to deal with, which brings us back to the cost vs. risk conversation nobody wants to have.

Recreatability as Strategy

Before you build an elaborate backup infrastructure, ask: what can we actually recreate?

Some data is truly irreplaceable. Customer records, financial transactions, and audit logs can’t be regenerated if they disappear. This type of data requires serious protection.

But a lot of what sits in cloud storage falls outside that category. Processed outputs, cached results, intermediate artifacts. If the source data exists somewhere upstream and your processing pipeline is intact, you can rebuild.

The strategy: protect the sources and protect the pipeline. For everything else, understand how long recreation takes and decide if that’s acceptable.

Focus protection on what actually needs it instead of treating everything as equally critical.

The Takeaway

Start with inventory: you need to know what data you have and where it lives before you can make good decisions about protecting it.

Understand half-life: Different data has different value over time, and you must protect accordingly.

You need to have the cost-versus-risk conversation at the executive level. These are business decisions, and not technical defaults.

Back up critical data to a separate environment. A station wagon full of tapes was slow, but you couldn’t delete it with a bad script. If one set of credentials can destroy everything, you don’t have real protection.

Make explicit decisions; remember, the worst outcome is assuming you’re protected when you’re not, because nobody ever asked the hard questions.