How to back up Airtable

Why a base needs a backup at all

Airtable is reliable. Its servers are backed up, its data centres are redundant, and in ordinary use you will never lose a record to a hardware failure. That is not what backups are for. Backups are for the things Airtable does exactly as told: the automation that ran with the wrong condition and overwrote a field on six hundred records, the import that mapped the wrong column, the collaborator who deleted a table they thought was a view, the sync that stopped and was “fixed” by clearing the table, the base that was moved to a workspace whose owner then left the company. Airtable’s own help centre opens its snapshot article with the sentence that “snapshots are a great way to protect your work from accidental changes,” which is the vendor telling you where the risk is.

A second reason is control. Your base is in one account, under one subscription, on one vendor’s terms. A copy that lives somewhere else, in a format you can open without Airtable, is the difference between an outage being an afternoon off and a crisis. Enterprise plans get eDiscovery exports and audit logs; everyone else gets what they arrange for themselves.

The third reason is the one most people discover late: the question after a mistake is rarely “give me yesterday’s copy.” It is “what did this record look like before Tuesday afternoon, and who changed it?” A backup that can answer that is a different thing from a backup that cannot, and the methods below differ on it more than on anything else.

What is in a base, and what “backed up” has to mean

Before comparing methods it helps to list what a base actually contains, because “we back up Airtable” can mean any subset of it:

• Records and cell values: the obvious part, and the only part some methods cover.
• Attachments: files in attachment fields. Airtable serves them through expiring links; a backup has to download the files, not the links, and an attachment-heavy base is usually 90% files by size.
• Schema: tables, fields, field types and their options: the formula text, the select choices and colours, which table a link points at, a rollup’s summary function.
• Views: filters, sorts, grouping, field order, hidden fields, row colouring. Views are where most of a base’s working logic lives, and they are the thing the API exposes least.
• Comments on records, with their authors and dates.
• Automations: triggers, actions, conditions, and the source code of script actions.
• Interfaces and forms: the pages, their elements and layouts; the form definitions.
• Revision history: Airtable’s own per-record record of who changed what, visible in the record sidebar, retained by plan.
• Sharing and permissions: collaborators, share links, passwords.

Then there is the time dimension. A copy taken once a day holds 365 points a year; a question about 14:05 on Tuesday is answered with the state at midnight. A copy taken on every change holds the moment.

And there is restore. A copy you cannot put back into Airtable without a week of work is an archive, not a backup. Restoring a whole base is one thing; restoring one table, one record, or one field across a thousand records without disturbing the thousand edits made since is another, and it is the thing you will actually want.

Method 1: Airtable’s own snapshots

Every base on every plan has snapshots. Open the base, click the history icon at the top right, and “Take snapshot” saves the whole base as it stands; Airtable also takes automatic snapshots on a schedule that “depends on usage patterns,” with an active base getting at least one a day. Retention is by plan: two weeks on Free, a year on Team, two years on Business, three on Enterprise Scale.

What a snapshot captures: everything. Restoring one “generates a new, separate base” that includes all automations, interfaces, extensions, tables, views, records and comments. It is the only method on this page that brings views and interface layouts back exactly, and for that reason alone it should stay on no matter what else you do.

What it misses:

• Revision history is excluded from the restored copy.
• Nothing smaller than a base. A restore is a new base. To recover one table you restore the whole base beside the original, copy the table across by hand, and reconcile the records edited since. To recover one field across many records, you are doing it cell by cell.
• The copy lives inside Airtable, in the same account, under the same subscription. If the workspace is deleted, the account closed, the plan lapsed or access lost, the snapshots go with it.
• No control over cadence. Automatic snapshots are taken when Airtable decides. You can take manual ones, which means remembering to.
• No change history. A snapshot is a point; it does not say who changed what between two points.

Verdict: necessary, not sufficient. Keep snapshots on, take a manual one before any risky change (a big import, a schema change, turning on a new automation), and know that the restore is whole-base-only.

Method 2: CSV export

Every view has “Download CSV” in its menu. It writes the view’s visible rows and visible fields to a file, which is as simple as backup gets and is why people do it.

What it captures: cell values, as text, for one view of one table.

What it misses: almost everything else. Hidden fields and filtered-out rows are not in the file. Attachments become URLs that expire in a couple of hours. Linked records become their primary field as text, so the link graph is gone. Field types are gone (a date is a string; a multiple-select is a comma-joined string, which breaks on any option with a comma in it). Formulas export their result, not their formula. Views, comments, automations, interfaces, schema and history are not in a CSV at all. And it is manual: it happens when someone remembers, once per view.

Restore: Airtable can import a CSV into a new table or, with the CSV import extension, merge into an existing one on a key field. Types have to be set by hand, links re-established by hand, attachments re-uploaded by hand. For a small lookup table this is fine. For a working base it is a week.

Verdict: a fine way to hand a table to someone, and a fine thing to do before you delete a table on purpose. Not a backup plan.

Method 3: scripts, Make and the API

Airtable’s REST API exposes records (with pagination), the base schema (tables, fields, options, views by name and type), comments, and webhooks that notify you of changes with before-and-after values. With a personal access token and a few hundred lines of code, or a Make or Zapier scenario, you can pull all of it on a schedule into a spreadsheet, a database, a Google Drive folder or an S3 bucket. There are open-source scripts on GitHub and a PyPI package that do exactly this.

What it captures: whatever you write code for. Records with their types intact (the API returns typed JSON), the schema with formula text, comments, and the attachments if you download them inside the link’s expiry window. Since July 2026 Airtable’s MCP server also exposes automation configuration including script source, interface pages and form definitions, which the REST API still does not.

What it misses:

• Views: the API gives names and types, not filters, sorts or field order. No script can back up a view’s configuration, because nothing exposes it.
• Interface layouts and revision history: not exposed.
• Everything you did not think of. Attachment links expire in about two hours, so a script that stores the link has stored nothing. A large base pays the API rate limit of five requests a second per base; a nightly full pull of a big base is a long job that shares that limit with your automations and integrations. The webhook that gives you live changes expires after seven days unless refreshed and holds unsent payloads for seven days before dropping them. A dropped payload looks exactly like an idle base.
• Restore. Writing back is a second project. The API caps writes at ten records per request, five requests a second; it cannot create a base’s computed fields in one step; it cannot set a formula’s display format; it cannot delete a table or a base; it creates automations only as drafts and refuses script actions. A restore script has to handle links (the target record ids changed), attachments (re-upload from your copy via a URL Airtable can fetch), and the records edited since the backup (overwrite them, or not?).
• Nobody watches it. The failure mode of a home-made backup is that it stopped in March and nobody noticed until September.

Verdict: the right choice if you have an engineer, a place to put the data, and a habit of testing the restore. The honest estimate is that the capture is a weekend and the restore, monitoring and attachment handling are the following six months. Airtable’s developer terms also matter here: an integration you offer to other people must not ask them for their personal access token, so a script that works for your own base does not become a product by being shared.

Method 4: third-party backup services

A handful of services sell the script above, run, hosted and watched. As observed on their own pages on 2026-10-06, the live ones are:

• ProBackup: a multi-app backup service (twenty-plus SaaS tools) that takes one backup a day, keeps daily versions, and prices on how much storage your backups use, with retention by tier (from $25 a month billed yearly). It restores tables as duplicates and records as copies or overwrites, skips computed fields on restore, and holds a SOC 2 Type II report. Its help article began listing automations in October 2026; what is captured is not documented.
• On2Air Backups: writes CSV and attachment copies into your own Google Drive, Dropbox, Box or OneDrive on a schedule, holding nothing itself. Priced on bases, records, attachments and restores per month: daily backups from $49.99, hourly from $79.99, one to ten restores a month. Restore rebuilds tables as new tables with formula, lookup and rollup fields as text; no single-record restore.
• Backup247: a multi-connector service with hourly or daily snapshots, in-place restore of a record, table or base with a visual diff, EU storage or bring-your-own bucket, priced by connectors with a 15 GB cap on every published paid tier (from $29, or $19 on its Airtable page; the site disagrees with itself).
• AirBackups: $15 a base a month, daily plus manual backups with long tiered retention and XLSX/JSON export; restore is manual, not into Airtable.

What they capture: records and schema, all of them; attachments, all of them, with varying care; comments, ProBackup and AirBackups; automations, none with documented depth. Views, none; the API wall is the same for everyone.

What to check before choosing one:

1. The meter. Storage-based pricing means an attachment-heavy base climbs the ladder; attachment counts and restore quotas mean the bill is set by the thing you cannot predict. Ask what a 22 GB base with 45,000 attachments costs, and whether the answer is on the pricing page.
2. The cadence. Daily means a day of work is the unit of loss. Hourly is better. Per-change is the only cadence that answers “what did this look like at 14:05?”
3. The smallest restore. Can it put back one record? One field across many records, while keeping edits made since? Or is the unit a table, copied beside the original for you to reconcile?
4. Computed fields on restore. Formula, lookup, rollup and count fields are where most restores silently degrade to text. Ask what comes back as what.
5. Where the copy lives and who can delete it. The vendor’s cloud, your drive, or your bucket; and whether the vendor’s own service account can delete your backup.
6. Whether the restore is ever tested. By them, automatically, on your data. Most say nothing, which is an answer.
7. Who changed what. Whether the history names the person, the automation or the integration, or only shows two dated copies to compare.

What each method misses, side by side

The pattern: snapshots are complete and inside; everything else is outside and incomplete, and the incompleteness is the same shape every time, because the API is the same wall for everyone. Views and interface layouts are not available to anyone outside Airtable. The differences that remain, cadence, the smallest restore, computed fields, attachments, who changed what, and whether anyone tests it, are the ones to choose on.

How to test a restore, which is the only test that counts

A backup that has never been restored is a hope. Whatever method you use, do this once now and then on a schedule, in a scratch workspace that holds nothing you need:

1. Pick a table with the awkward fields. Links to another table, a lookup, a rollup, a formula with a display format, an attachment field with a few hundred files, a multiple-select with a comma in one option. Easy tables pass every test.
2. Write down what you expect. Record count, a few specific cell values, the number of attachments on three records, the formula text of two fields, the link target of one field.
3. Restore it into the scratch workspace, by the method’s own path: restore the snapshot as a new base; import the CSV; run your restore script; use the service’s restore. Time it.
4. Compare, cell by cell for your sample. Open both tables side by side. Are the attachments files or dead links? Did the formula come back as a formula or as its last value? Did the link field come back as a link or as names? Did the select options keep their colours? Did the date field keep its timezone?
5. Then test the small restore. Change one cell in the scratch copy, and try to put just that cell back from the backup. Change a cell in a record and restore a different field of the same record: did your edit survive? This is the case you will actually face.
6. Write down what did not come back and decide whether it matters. Every method has a list. The question is whether you know yours before the day you need it.
7. Put it in the calendar. Quarterly is the minimum. A service that runs the test for you every night and shows the result is a reason to choose it.

A backup plan that fits on one page

1. Keep Airtable snapshots on, and take a manual one before any risky change. They are the only copy of your views and interface layouts.
2. Keep a copy outside Airtable that captures records with their types, the schema with formulas, attachments as files, and comments, on a cadence shorter than the amount of work you are willing to lose. Daily if you must; per change if you can.
3. Make sure that copy records who changed what. The question after a mistake is “what happened?” before it is “give me the copy.”
4. Know the smallest thing you can restore, and that restoring it keeps the edits made since.
5. Know what is not in it. Views and interface layouts are not in any outside copy. Write that down somewhere a successor will find it.
6. Test the restore, now and on a schedule, in a scratch workspace, with the awkward table.

If you would rather not build and watch this yourself: AirtableBackup is a service built on exactly this plan. It saves every change with the author’s name as it happens, takes a full backup every night, stores attachments once, backs up automations with their script source, restores one cell, one record, one table at a moment or a whole base into a new base, can be undone, and, if you turn it on, restores 25 records into a test base of yours every night and checks them. Its coverage table says in print that views and interface layouts are not backed up, for the reason this guide gives. One flat price per base; a 14-day trial with no card.