Skip to content
AirtableBackup
Sign up

Guide

How to restore deleted records in Airtable

The trash gives you seven days. Revision history gives you the old value of a cell. A snapshot gives you the whole base as it was, as a new base. What none of them gives you is the one thing most people want after a bad afternoon: put back exactly what was lost, where it was, and keep everything done since. This guide goes through each in the order you should try them, with Airtable’s own documentation as the reference.

Updated · about 9 minutes

First: stop, and note the time

Before anything else, write down roughly when the deletion happened and what you think was deleted: a few records, a whole view’s worth, a field, a table. Every method below asks you to find a moment, and the moment is easier to find now than after an hour of clicking. If an automation or a script is still running and may be the cause, switch it off before you restore anything, or it will do it again.

If you are still in the same browser session, try undo first (⌘Z or Ctrl+Z, or the undo arrow). Airtable’s undo covers the current session only; once the tab is closed it is gone, which is why the rest of this guide exists.

Within seven days: the base trash

Every base has a trash. Airtable’s help centre describes it as the place to view and restore the tables, views, fields, extensions, and records that have been deleted in a base in the past 7 days. Editors and above can open it and restore from it.

  1. Open the base the records were deleted from.
  2. Click the history icon (the clock) next to Share at the top right, then Trash.
  3. Find the deletion. Records deleted together are listed together, with when they were deleted; a deleted table or field is its own entry.
  4. Click Restore. The records go back into their table.

What it misses. The window is seven days from the deletion, on every plan. Changes to records that still exist are not in the trash: a record whose cells were overwritten was not deleted, and the trash has nothing to say about it. Automations are not in the list of what the trash holds; a deleted automation is a snapshot question (below). And the trash shows what was deleted, not what was changed around it afterwards: if a linked record was deleted and another record’s link to it was cleared as a result, restoring the record does not necessarily restore the link; check the linked-record fields after a restore.

A record that was changed, not deleted: revision history

If the record is still there and a value is wrong, expand the record and open its activity feed on the right. Airtable’s record revision history lists every edit to that record with who made it, when, and the value before and after. There is no restore button; you read the old value and type it back. Retention is by plan: two weeks on Free, one year on Team, two years on Business, three years on Enterprise Scale.

What it misses. It is per record. A question like “which records did the import touch on Tuesday?” has no answer here; you would open each record in turn. It is not exposed through the API, so nothing outside Airtable can read it for you. And it does not survive a snapshot restore or a base duplication: the new base starts with no revision history. The guide to revision history covers it on its own.

Older than seven days: restore a snapshot beside the base

Airtable takes snapshots of every base automatically, more often for busy bases (if you use your base a lot, you’ll likely get at least one snapshot per day), and you can take one by hand. Retention is by plan, two weeks on Free to three years on Enterprise Scale. A snapshot is the whole base: tables, records, views, interfaces, automations, comments.

  1. Open the history icon, then Snapshots. Pick the most recent snapshot taken before the deletion. The time you wrote down earlier is what you are matching.
  2. Click Restore. Airtable creates a new base from the snapshot and leaves the live base exactly as it is. The new base has a new address and, if it is restored into a different workspace, may need collaborators added.
  3. In the restored base, find the records you lost. Select them and copy; in the live base, paste into the same table in a view that shows the same fields in the same order. Pasted records are new records with new ids.
  4. Check the awkward fields. Linked-record fields paste as the linked records’ primary values and re-link by matching text, which works only when the names are unique and still exist. Attachments paste as files only within Airtable’s own copy mechanics; verify them. Formula, lookup and rollup fields recompute on their own.
  5. Delete the restored base when you are done, or keep it a week in case you missed something.

What it misses. The snapshot is a point in time, so everything that happened between the snapshot and the deletion is not in it, and everything that happened after the deletion is in the live base only; you reconcile by hand. The restored base has no revision history. Record ids differ between the two bases, so anything keyed on a record id (an integration, a form, a synced table) does not see the pasted records as the same records. And the copy lives inside Airtable, under the same account: if the workspace or the account is what was lost, the snapshots went with it.

One field changed on hundreds of records

The common version of this story is not a deletion. An automation ran with the wrong condition, an import mapped the wrong column, a find-and-replace in a view went wider than intended, and one field now holds the wrong value on six hundred records. Nothing is in the trash. Revision history has the old value, on each of the six hundred records, one at a time. A snapshot has the old values, as a new base to copy a column out of, if nobody edited those records legitimately since.

If you have a snapshot and the records have a unique key, the workable path is: restore the snapshot, copy the key and the one field from the restored base into a scratch table in the live base, and use a lookup to pull the old value alongside the new, then paste the old values back for the rows that should change. It is an afternoon, and you will want to switch the automation off first.

This is the case a change history outside Airtable is for. AirtableBackup’s Batch Fix is built for exactly this day: name the field, the time window and, if you like, the actor, and the plan lists every record whose cell will be put back and every one left alone because a person edited it since. One restore, undoable.

A deleted table, field or base

A deleted table or field is in the base trash for the same seven days, and comes back with its records and values. After that, a snapshot restore is the way, and the table is copied across like records are, with the same caveats about linked-record fields.

A deleted base goes to a trash of its own, reachable from the workspace, for a limited time; Airtable’s article on managing trash has the current window and who can restore. A base that was deleted along with its workspace, or that belonged to an account that was closed, is the case that ends in a support ticket, which is the strongest argument for a copy that lives somewhere else.

What a backup adds, and what it cannot

Everything above is what Airtable gives every base, and it is a lot: a seven-day trash, per-record history by plan, and whole-base snapshots. A backup outside Airtable adds four things, and it is worth being exact about which of them a given tool delivers:

  • A copy that is not in the account. Lose the workspace, the account or the plan, and the backup is still there.
  • Time beyond seven days, and finer than a day. A daily backup answers “yesterday”; a per-change backup answers “14:05 on Tuesday”.
  • A smaller restore. One record, or one field across many records, put back into the live table, keeping the edits made since, instead of a whole base to copy from.
  • Who changed what, across the whole base, not one record at a time.

AirtableBackup does these four: every change saved as it happens with the name of the person, automation, form or integration that made it; any table shown as it was at any moment; undo of one change or one field of it; restore of a table at a moment or a whole base into a new base; and every restore undoable and, if you turn it on, tested every night. Backing up starts when you connect the base; nothing before that moment is in the history, and Airtable’s own revision history is not copied, because the API does not expose it. The coverage table lists the rest, gaps included.

What no backup can do: bring back views exactly (Airtable’s API does not expose filters, sorts or field order; only a snapshot has them) or restore into the live base with the original record ids once Airtable has deleted the record. A restored record is a new record to Airtable, from every tool. Plan for that by keying integrations on a field you control rather than on the record id.

Questions

Can I restore a record deleted more than seven days ago?
Not from the trash. After seven days the ways back are a snapshot taken before the deletion, restored as a new base beside the original and copied across by hand, or a backup taken outside Airtable. A snapshot restore keeps the record ids inside the new base, but the copy you paste into the live base is a new record.
Does restoring a snapshot overwrite my base?
No. Airtable restores a snapshot as a new, separate base and leaves the original untouched. That is safe, and it is also why a snapshot cannot put one record back where it was: you copy what you need from the restored base into the live one.
Can I see who deleted a record?
Once the record is back from the trash, its revision history shows the edits made to it, with names and times, for as long as your plan keeps history. Airtable does not expose revision history through its API, so a tool outside Airtable can only tell you who deleted a record if it was recording changes before the deletion happened.
Does undo work after I close the base?
No. Undo in Airtable is for the current session; once the tab is closed or you sign out, the undo stack is gone. The trash, revision history and snapshots are the ways back after that.