BigQuery time travel works. Google built it to hold two to seven days of table history, enough to undo a mistake you catch quickly. Recovery plans break when that window becomes the whole plan, because the losses that cost the most take the longest to notice.
There was no plan, only a spreadsheet
A senior data warehouse director described the failure to us on a recent call. Their team ran truncate-and-load pipelines: each run wipes the target tables, then reloads them from the source. One day an upstream source shut down. The truncate step kept running. The load step had nothing left to load, and a year of history disappeared from the warehouse.
Nobody caught it inside the seven days, and no recovery plan existed to fall back on. They were only able to recover because another team kept a spreadsheet with the same figures for their own work. An accidental copy did the job the platform couldn't.
The director's takeaway stuck with us: BigQuery retains about seven days of history, and any loss you notice after that is your responsibility, not Google’s. A senior cloud engineer on the same call said the trouble starts even earlier. Auditors and new clients ask for proof of retention, and a seven-day window turns into an audit finding before any data disappears.
What does BigQuery time travel actually cover?
Time travel keeps a rolling window of table history. You set the length per dataset or project, anywhere from two to seven days. Inside that window, you can query any past state with FOR SYSTEM_TIME AS OF, or bring back a table someone dropped. For the failures it targets (a bad UPDATE at 3pm, a script that drops the wrong table), it works, and it works fast.
Past the window, a fail-safe period holds deleted or replaced data for seven more days. You can't query it yourself; retrieval runs through Google Cloud support. And once the fail-safe lapses, Google's docs are blunt: no method restores the table, a support ticket included.
Credit where it's due, the docs never oversell the feature. They point you to table snapshots as soon as your needs outgrow the window. Google built an undo button and labeled it honestly.
BigQuery's durability is also real, and it solves a different problem. Google won't lose your data; durability says nothing about what your own pipelines do to it. Under the shared-responsibility split, bad loads, software bugs, accidental deletions, and rogue writes stay on your side of the line.
Why slow-burn errors beat a seven-day window
Errors come in two volumes. The loud kind is a dropped production table: a dashboard breaks within the hour, and the restore runs before lunch. Time travel exists for exactly that.
The quiet kind took the year of history. No alert fired, because nothing failed. The tables still existed, and the jobs still ran on schedule. Quiet losses show up far downstream: a month-end report that looks thin, or a finance close that doesn't tie out.
Either path usually takes weeks. With truncate-and-load, the clock is exact. The last clean version leaves your reach seven days after the upstream dies, and Google's on day fourteen.
Timing is only half the problem. The other half is where the history lives. Time travel is versioning, not isolation: the rollback path sits in the same project and trust domain as production, under the very accounts and credentials that run the pipelines.
So an identity with sufficient permissions to wreck a dataset stands within the same boundary as the feature meant to reverse the damage. A production agent with write access to the warehouse raises that exposure to machine speed. Ransomware and rogue-agent recovery both hinge on copies that production credentials can never reach.
The pattern is common. In a live poll of 573 practitioners at Eon's BigQuery Day in May 2026, 82% said their coverage came down to time travel alone, snapshots, or no formal plan.
What a real recovery plan for BigQuery looks like
To be fair, the native stack does go past the window. Table snapshots persist after time travel expires, and scheduled exports put copies in Cloud Storage, outside BigQuery entirely. Both are real tools, worth using for the tables you know are critical.
The catch is that it's all manual. Every snapshot and export is a per-table choice a person sets up and maintains, and each copy inherits production's access controls unless you deliberately move it to another project. A snapshot can only capture the last seven days of state, so it can't rescue data that already aged out. The usual diff-export pattern also burns two full table scans per table, on every run.
And the dataset someone creates next quarter is the one the export script never heard about.
Good looks like answering four questions for any dataset, on any day: what's protected, how far back, in what trust domain, and how fast it comes back. Getting there takes five things:
- Independent copies outside the warehouse's own history, on a schedule you set.
- Retention measured in months or years, set by policy instead of a product constant.
- A separate trust domain: a different account or organization, immutable storage, credentials production never holds.
- Coverage that follows the estate, so a new dataset gets a policy without a human updating a script.
- Restores you've actually run. A runbook nobody has tested is a hypothesis.
For the operational version of the list (dataset tiering, RPO targets, restore drills), our BigQuery backup best practices playbook goes deeper.
Where Eon fits
Eon Data Protection backs up BigQuery datasets, native tables, and their metadata (views, materialized views, and routines) down to every six hours. Copies land in an immutable, logically air-gapped vault with credentials independent from production. Retention follows your policy, whether that's 90 days or seven years, and Cloud Backup Posture Management (CBPM) assigns policies as new datasets appear, with no script to keep current. Restores scope to what actually changed: a full dataset, a single table, or the records matching a SQL query.
Eon builds on time travel rather than around it. After the first full copy, incremental capture uses the window itself to pick up what changed since the last pass. We think the feature is good at its job, which was never long-term retention. After day seven, the vault carries the history.
Protected data stays usable, too. Eon stores its BigQuery recovery copies in open Apache Parquet format rather than a proprietary blob, so you can look inside them without running a full restore. Finding the last clean version of a truncated table becomes a SQL query instead of an archaeology project.
Pick the one dataset your business would miss most and trace what its recovery looks like on day eight. If the trail ends at a window, or at a spreadsheet another team happens to keep, start there.
FAQ
How long does BigQuery time travel keep data?
Between two and seven days. You set the window at the dataset or project level, and seven is the default. Seven is also the ceiling: you can shrink the window to two days, but nothing extends it beyond that.
Does the fail-safe period make time travel safe enough?
The fail-safe holds deleted or replaced data for seven more days as an emergency backstop. You can't query it yourself, and pulling anything out means a ticket with Google Cloud support. Fourteen days is the absolute outer edge, and only for losses you've already noticed.
Do table snapshots and exports count as recovery copies?
Partly. Snapshots persist past the window, exports land in Cloud Storage, and both help for the tables someone thought to cover. The limits: a snapshot can't capture any state older than the time travel window, exports run on whatever schedule exists, and neither copy leaves production's trust domain on its own.
Can ransomware or a rogue agent get past time travel?
Time travel lives in the same project and under the same access controls as the data it versions, so anything with permission to destroy tables can often reach the history too. Recovery copies in a separate trust domain, with their own credentials outside production's reach, close the hole that window-based history leaves open.
How does Eon protect BigQuery?
With independent recovery copies taken as often as every six hours and held in an isolated, immutable vault for as long as your policy says. Restores cover a full dataset, a single table, or the records matching a SQL query, along with views, materialized views, and routines. And because the copies live in open Apache Parquet format, you can query them before you restore anything.
