How to Back Up Airtable Bases, Attachments, and Automations

A practical field guide from Automation Ace.

How to Back Up Airtable Bases, Attachments, and Automations

Most teams assume they have Airtable backups because Airtable has snapshots and revision history. Those are useful features and they are not backups. They live inside the same account, under the same billing relationship, subject to the same access controls — which means they protect you against the mistake you notice quickly, and not against a deleted base, a lapsed subscription, a departed admin, or an account you lose access to. A real backup lives somewhere else and covers three distinct things that need three distinct approaches.

What Snapshots Actually Protect Against

Airtable's snapshot and revision history features are genuinely good at one job: undoing a change you made recently and noticed. Someone deletes a column, someone pastes over a hundred rows, a script writes garbage — snapshots handle that well, and retention length varies by plan.

They do not help when the base itself is gone, when the account is inaccessible, when a subscription lapses and record limits put data out of reach, or when you need the data in a system that is not Airtable. Those are the scenarios a backup exists for, and every one of them requires a copy outside Airtable.

If longer in-product retention is what you actually need, that is a plan question rather than a backup strategy question — Airtable's plans are here. Treat that as a complement to an external backup, not a replacement for one.

The Three Things to Back Up

They fail differently and need different handling:

• Records — the row data. Easiest to export, easiest to restore.
• Attachments — the actual files. Deceptively hard, because the obvious approach silently fails.
• Configuration — schema, views, automations, interfaces, permissions. There is no export button, and this is the part that takes weeks to rebuild from memory.

Backing up only the first one is the common mistake, and it leaves you able to recover the data but not the system that used it.

Backing Up Records

Two workable approaches, depending on how much you need it automated:

1. Manual CSV export per table. Fine for a base that changes slowly and a team that will genuinely do it on schedule. It exports the current view, so export from a view with all fields visible and no filters applied — a filtered view produces a partial backup that looks complete.
2. Automated export via the API. A scheduled job pulls every table through the Airtable API and writes the results to storage you control. This is the version that actually keeps happening six months from now, because it does not depend on anyone remembering.

For the automated path, a scheduled Zap or scenario can page through records and write them out to Google Sheets, a CSV in cloud storage, or a database. Mind the rate limits when pulling large bases — batching and pacing matter, and the failure modes are covered in Airtable API rate limit 429 errors. If you are wiring up the API calls yourself, how to use APIs in Zapier steps covers the request mechanics.

Export field values in their raw form where possible. Formula and rollup fields export as computed values, which is fine for reading but means the logic that produced them lives only in the configuration backup.

Backing Up Attachments — The Trap

This is where most Airtable backup setups quietly fail. When you export a table containing attachments, the CSV contains URLs, not files. Those URLs are not permanent public links — they expire. A backup CSV full of attachment URLs looks like a complete backup and is worthless once the links go stale.

The backup has to download the actual bytes:

1. Pull the attachment URLs through the API for each record.
2. Download each file while the URL is still valid.
3. Write the file to storage you control — Google Drive, Dropbox, S3, or similar.
4. Record the mapping between the record and the stored file path, so a restore can reconnect them. A backup of loose files with no idea which record each belonged to is only half a backup.

Filename collisions are a real problem at volume; prefixing stored filenames with the record ID keeps them unique and preserves the mapping in the filename itself. Related mechanics are covered in setting Airtable attachment filenames via the API, and for routing the files into cloud storage automatically, automating Dropbox folders, files, and shared links covers that side.

Backing Up Configuration and Automations

There is no native export for automations, interfaces, or permission settings. Rebuilding a base's structure from scratch after losing it is the expensive part of any recovery, and it is entirely avoidable with modest ongoing effort.

What to capture, in rough order of value:

• Schema. Tables, fields, field types, and options. The Airtable metadata API can pull this programmatically, which makes it easy to snapshot on a schedule and diff over time.
• Formulas, rollups, and lookups. The actual expressions, in plain text. These represent real logic and they are tedious to reconstruct.
• Automations. Trigger conditions, each action step, and any script bodies in full. Script contents in particular should be stored as text, not screenshots.
• Views, filters, and sorts that people depend on operationally.
• Interfaces and permissions — who can see what, and which record-level filters enforce it.

Store this as text in version control rather than as screenshots in a folder, so you can see what changed and when. The reasoning is the same as for any other no-code system — see version control for no-code automations.

Automate It or It Will Not Happen

A backup process that depends on someone remembering is a backup process with an expiry date. Put the record and attachment export on a schedule — weekly is a reasonable default for most operational bases, daily if the data is high-value or high-churn — and have it write to dated folders so you keep a history rather than overwriting one copy.

Add a failure alert. A backup job that has been silently erroring for three months is worse than no backup, because you believed you had one. Alert on "backup did not complete" rather than only on explicit errors, since the most common failure is a job that stopped running rather than one that ran and failed.

Test a Restore Before You Need One

A backup you have never restored from is a hypothesis. At least once, take a backup and rebuild a working copy from it: import the records into a fresh base, reconnect a sample of attachments, and recreate one automation from your configuration notes. You will find gaps — a field type that did not survive, an attachment mapping that does not resolve, an automation note too vague to act on. Finding those during a drill costs an afternoon. Finding them during an actual recovery costs considerably more.

If you keep off-platform copies on your own server, SFTP by Zapier can upload exports on a schedule.

Keep the Backup Itself Secure

An Airtable backup is a full copy of your operational data sitting in cloud storage, often containing customer records. Restrict access to the backup location as tightly as the source, keep it out of broadly shared drives, and apply a retention policy so old copies do not accumulate indefinitely. The broader checklist in the automation security checklist for small businesses applies directly.

Backups are also the foundation of portability — the same three exports are what an exit plan depends on. See the Airtable exit plan and portability checklist for that framing, and how to migrate from Airtable without breaking your automations if you are heading toward an actual move.

For help setting up automated Airtable backups, attachment archiving, or a tested restore process, talk to Automation Ace.

The attachment URLs in your CSV export are the tell. If your backup contains links rather than files, you do not have a backup of your attachments — you have a list of things you used to be able to download.