Restore

Restore Airtable data to a new base

When to use a new-base restore, why overwrite restore is risky, and what to check after recovering data.

8 min guide

Guide status

ContentPractical launch guide

FocusAirtable restore planning

UpdatedMay 31, 2026

In this guide

Overview

Quick answer

Use a new-base restore when you need a safe recovery copy of Airtable data without changing the original base. Airhistory v1 creates a new Airtable base from supported snapshot data, then the user reviews fields, records, relationships, and operational gaps before deciding what to move back into production.

The most dangerous restore is the one that tries to fix production while everyone is panicking. Overwriting an existing Airtable base can replace the wrong data, erase investigation context, or damage automations that still depend on the current base.

Airhistory v1 uses a more cautious model: restore supported snapshot data into a new Airtable base. The original base remains untouched while the team reviews what was recovered, compares it to the incident, and decides the next operational step.

This guide explains when a new-base restore is the right move, what to check after the recovered base is created, and which parts of an Airtable workspace may still need manual review.

Before you start

What to confirm before setup

Identify the incident: accidental deletion, bad import, unwanted bulk edit, broken automation, or client handoff mistake.

Choose the snapshot timestamp you want to recover from.

Confirm the connected Airtable account can create a base in the target workspace.

Expect restore to create a new base rather than overwrite the original.

Plan to review formulas, views, automations, permissions, comments, and attachment binaries manually.

Keep the original base intact until the recovered base has been inspected.

Step-by-step

Follow the workflow in order

Choose the restore point

Start from the snapshot taken before the unwanted change. If you are unsure, compare nearby snapshots first so you understand what changed.

Use snapshot history to locate the closest clean point in time.
Compare before and after snapshots when possible.
Avoid restoring from an unverified or unrelated base snapshot.

Create a new Airtable base

Run restore into a new base. This preserves the original as evidence and avoids a risky overwrite of live Airtable data.

Use a clear recovered-base name.
Create the base in the workspace where the owner expects it.
Keep the restore receipt safe and understandable.

Review restored tables and fields

After restore, inspect the recovered base before anyone treats it as production. Look for table coverage, field types, select choices, linked-record behavior, and readable fallback fields.

Check the most important tables first.
Confirm key fields were created with usable names and types.
Review linked-record relationships when the snapshot contained enough metadata.

Compare records against the incident

A recovered base should answer a concrete question: what did we need back? Review records that were deleted, edited, imported, or cleaned up incorrectly.

Spot-check records the team cares about most.
Compare counts and representative examples.
Keep sensitive Airtable record values out of public support channels.

Rebuild operational pieces deliberately

A data restore does not automatically mean every operational layer is back. Some Airtable features may need manual rebuilding or verification after the new base exists.

Review views and formulas before handoff.
Reconnect or rebuild automations only after data checks pass.
Check permissions, comments, and attachments according to the workflow's risk.

Decide how to return to production

Once the recovered base is verified, decide whether to copy specific data back, switch users to the recovered base, or use it only as a reference.

Do not rush the recovered base into production.
Communicate what was restored and what still needs manual work.
Keep the original base untouched until stakeholders agree on the next step.

Checklist

Use this before you call the backup ready

1The restore point is tied to a specific incident or timestamp.

2The original Airtable base remains untouched.

3The restored base was created in the expected workspace.

4Critical tables and fields were inspected.

5Sample records were compared against the incident.

6Formulas, views, automations, permissions, comments, and attachment binaries were reviewed as manual follow-up items.

7The team chose a clear path: reference only, copy selected data, or move work to the recovered base.

FAQ

Questions people ask before trusting this workflow

Why restore to a new Airtable base instead of overwriting?

New-base restore is safer because it leaves the original base untouched. The team can inspect recovered data before deciding whether to copy anything back into production.

Does restore recreate every Airtable feature exactly?

No. Airhistory v1 focuses on supported snapshot data and a cautious recovery path. Some field metadata, select choices, and linked-record relationships can be restored when snapshot metadata is available, but exact full-fidelity restore is not the v1 promise.

Can restore recover formulas, views, comments, and attachments?

Treat those as manual review items in v1. Restored data should be inspected, and operational layers such as formulas, views, automations, permissions, comments, and attachment binaries may need separate rebuilding or verification.

What should I do before using the recovered base?

Check important tables, field types, sample records, linked relationships, and the incident-specific records you needed back. Only then decide whether the recovered base should become production, remain a reference copy, or supply selected data back to the original workflow.