Your data lakehouse runs the business now. Does your backup infrastructure know that?
Data infrastructure has gone through a few distinct changes. It started with the data warehouse: structured, expensive, and slow to scale, the classic setup most of us grew up on. Then came the data lake, raw and unstructured data piling up cheaply in object storage like S3, but with none of the structure needed to reliably query it.
Now we're in the lakehouse era, where an open table format like Apache Iceberg sits on top of that cheap storage and gives it back the structure of a real database. Now, transactions, schema evolution, and time travel, are all available without locking you into one vendor's warehouse.
A decade ago, the data in these environments mostly powered a report someone glanced at once a month. Today it's training data for the models your team ships. It’s powering the actions taken by AI agents. It's the input layer for pipelines making decisions in real time.
Lakehouses haven't just grown in size, they've become critical operational infrastructure the business runs on—and that changes what's at stake when something goes wrong.
What Is Apache Iceberg?
Think of Amazon S3 as a hard drive. It's great at storing files, but a giant pile of files isn't something you can run a SQL query against. Apache Iceberg is the layer that turns that pile of files into something you can actually query like a table: a catalog that keeps track of which version of the table is the current one, a metadata layer that records the schema and full history of changes, and manifests that list exactly which files belong to which version.
That structure is what lets engines like Spark, Athena, and Snowflake treat lower cost object storage like a real database, and it's a big part of why Iceberg has become the default table format for modern lakehouses. Being open source, Iceberg has some availability options built in, however none of them amount to a true backup.
Time Travel Isn't A Backup Strategy
Every time an Iceberg table changes, whether a row gets added or updated, Iceberg doesn't overwrite anything. It writes a new snapshot: a record of exactly which data files made up the table at that moment. Iceberg uses those snapshots for two things: Time Travel (which lets you query the table as it looked earlier) and rollback (which resets the table to a past snapshot).
The catch is that a snapshot is just a pointer into files sitting in the same S3 bucket, in the same AWS account, as the table itself. It's not an independent copy. A snapshot isn't a backup. It's a pointer to files that can disappear right along with it. If those files get deleted—whether by accident, a compromised account, or an AI agent with more access than it should've had—the snapshot pointer doesn't help.
Rebuilding Is Not The Same As Recovering
Even when the raw files survive, you're not out of the woods. Restoring objects to S3 doesn't give you back a working table, because nothing has told the catalog where to find them. Someone still has to manually rebuild that metadata before a query engine can read a single row.
On a smaller scale, that's an annoying afternoon rebuilding metadata. At the scale most Iceberg tables actually run today (millions of files and multiple petabytes) it’s real engineering time spent reconstructing metadata by hand. If you're rebuilding a table from source instead of from a proper backup, it's weeks of compute and data transfer costs to regenerate a dataset that took years to accumulate. None of that accounts for what's happening upstream while it's offline: every pipeline, model, and dashboard reading from that table sits dark for as long as the rebuild takes.
The tools most teams reach for today don't close that gap. AWS Backup can capture the underlying S3 objects, but it has no concept of what an Iceberg table actually is—so a restore still leaves you with files and no catalog. Versioning and replication protect against some failure modes, but a bad delete replicates right along with everything else, and there's no clean point-in-time recovery once you're dealing with billions of object versions. Custom scripts can work, but they're brittle, they rarely account for the catalog, and they tend to be the least fun thing to debug live during an actual incident.
None of that is a knock on any of those tools individually—they just weren't built to understand what a table is.
Announcing Rubrik Apache Iceberg Protection
Rubrik Apache Iceberg Protection backs up Iceberg tables end to end: the data files, the manifests, the metadata, and the catalog entry itself, whether that table lives in a self-managed AWS Glue Data Catalog or in fully managed Amazon S3 Tables. The backup itself lives somewhere the original account can't touch, whether that's a separate, locked-down AWS account with no human access or Rubrik Cloud Vault, so whatever took down the table in the first place can't reach the copy either.
On recovery, Rubrik doesn't hand you back a pile of Parquet, ORC or Avro files. It rebuilds the metadata and re-registers the table in the catalog automatically, so the table comes back immediately queryable in Athena, Spark, or whatever engine you're already using. No manual catalog surgery is required and no waiting on an engineer to stitch things back together while the business is down.
How It Works
Backing up an Iceberg table holistically means capturing more than just the files sitting in S3. Rubrik also has to grab the manifests, the metadata, and the catalog entry, then know how to put all four back together in a way the catalog actually recognizes.
Here's what that path looks like:
Rubrik retrieves customer specific credentials from a trusted Rubrik owned AWS account.
STS:AssumeRole is called.
Rubrik is granted permissions to the customer AWS account via a deployed cross-account role during onboarding.
Regional APIs are called to determine which data to backup including catalogs, tables, and metadata.
Rubrik instantiates a collection of lightweight, transient EKS pods to determine what needs to be protected and the backup process begins.
Data is written immutably and air-gapped to either a customer-hosted S3 bucket or Rubrik Cloud Vault.
Metadata is then returned to RSC to aid with restorations.
The restoration process is essentially the reverse of this flow, with the addition of Rubrik stitching the catalog back together so your lakehouse is immediately queryable. A few specific design choices make that path hold up at scale:
Rubrik doesn't rescan everything every time: We use Iceberg's own manifest files to figure out exactly what changed since the last backup, instead of doing a full inventory scan of the bucket. That keeps backup windows sane even as your tables grow into billions of objects.
- Rubrik backs up the version that matters, not every version: You can perform backups against only the latest snapshot, or target the latest compacted snapshot or latest tagged snapshot with failback to the latest snapshot. No need to backup EVERY snapshot.
- You control where the copy lives: Backups can be stored within a separate, locked-down AWS account with no human access, or in Rubrik Cloud Vault, an air-gapped, immutable location kept separate from your primary authentication domain.
- You get a rollback point before you need one: You can trigger an on-demand backup ahead of a risky operation, like a schema change or a large batch write, so there's a clean point to fall back to if it goes sideways.
- Risk-Free Recovery via Sandbox Branching: You can choose to restore to an isolated branch to validate data and schemas before seamlessly promoting to production.
One Platform For The Whole Lakehouse, Not Just The Tables
Iceberg tables don't exist in isolation. They're fed by databases like DynamoDB and RDS, built by pipeline code that usually lives in GitHub, and they sit inside the same AWS accounts as everything else you're already running.
Rubrik protects that entire chain from one platform, with consistent policies and one place to look during an incident, instead of a patchwork of point tools that all have to work correctly at the same time for recovery to actually succeed.
Coverage can exist at the account level, so a new table someone spins up next quarter doesn't sit unprotected just because nobody remembered to tag it. If you need tighter control, you can override account-level protection with namespace or table-level SLAs for the specific workloads
Try It Yourself
Apache Iceberg gives you structure on top of cheap object storage, but the versioning it ships with, time travel and rollback, was never built to survive a deleted bucket or a compromised account. Rubrik Apache Iceberg Protection closes that gap: full backup and recovery for the data files, manifests, metadata, and catalog entry together, stored somewhere the original failure can't reach, and restorable into a fully queryable table without anyone touching the catalog by hand.
Read the Datasheet for a deep-dive or take it for a test drive yourself by walking through one of our self-guided, hands-on labs on Rubrik Explore.