Guide
How to back up Airtable without relying on exports
A practical backup model for teams that need point-in-time Airtable history, user-owned cloud copies, and a safe restore path.
Guide status
In this guide
Overview
Quick answer
The safest way to back up Airtable is to keep an independent copy outside the base: connect Airtable with OAuth, select the bases that matter, store snapshot JSON in a user-owned Google Drive or Dropbox folder, verify the first manual snapshot, then schedule recurring backups and document how restore will work before an incident happens.
Airtable exports are useful in emergencies, but they are not a dependable backup system by themselves. A CSV export is easy to forget, often misses context, and does not give a team a clean way to compare what changed between two points in time.
A practical Airtable backup workflow needs three things: a repeatable snapshot, a copy that lives outside Airtable, and a restore plan that does not put the original base at risk. Airhistory is built around that model. It connects to Airtable, snapshots selected bases, writes the backup body to your connected cloud storage, and keeps safe operational metadata in the app.
This guide explains the setup model before you need it. It is written for operators, founders, and consultants who need a simple answer to the question: how do we back up Airtable in a way that someone can actually trust later?
Before you start
What to confirm before setup
Step-by-step
Follow the workflow in order
Define the backup scope
Start with the bases that would hurt the business if they were damaged, accidentally changed, or deleted. Good backup scope is specific: a client operations base, a production tracker, an internal CRM, or a finance workflow.
- List the bases that need backup history.
- Name the person responsible for checking backup health.
- Separate production bases from experiments and disposable templates.
Connect Airtable and select bases
Use the normal Airhistory dashboard flow to connect Airtable. The browser should only show safe base labels and setup state. Tokens and raw provider details stay server-side.
- Grant access through Airtable OAuth.
- Select the bases Airhistory should protect.
- Use Add base later if you need to authorize more bases.
Choose user-owned cloud storage
A backup is more useful when the business controls the destination. Connect Google Drive or Dropbox, then pick a destination folder for each protected base.
- Use a folder the business can keep if the app account changes.
- Avoid mixing backup files with unrelated operations files.
- Keep folder names readable for people, not packed with internal IDs.
Run the first manual snapshot
Before turning on automation, create a manual snapshot. This proves the Airtable connection, cloud storage connection, destination folder, and snapshot parser all work together.
- Run the snapshot from the dashboard.
- Confirm it completes successfully.
- Open snapshot history and check the safe receipt details.
Compare history before you need a restore
Backup files are only useful if you can understand them later. Use snapshot history and field-level differences to review added, changed, and deleted records between two points in time.
- Check that important tables appear in the snapshot view.
- Review a recent change so the team knows how diffs read.
- Do not expose raw Airtable record data or provider file details in public support requests.
Schedule recurring backups
Once a manual snapshot is verified, turn on a daily, weekly, or monthly launch schedule. Higher-frequency timing should wait until the scheduled runner is hardened for larger backup loads.
- Use the daily, weekly, or monthly schedule that the launch plan supports in the shared daily processing window.
- Pause or edit schedules when a base is no longer in scope.
- Watch lost-connection alerts so a broken provider connection does not quietly stop protection.
Keep restore expectations honest
A restore plan should be clear before an incident. Airhistory v1 uses a cautious new-base restore path for supported snapshot data. It does not overwrite an existing Airtable base.
- Know where the recovered base should be created.
- Review the restored base before replacing any workflow.
- Treat formulas, views, automations, permissions, comments, and attachment binaries as items that may need manual review or rebuilding.
Checklist
Use this before you call the backup ready
FAQ
Questions people ask before trusting this workflow
Are Airtable CSV exports enough for backup?
CSV exports can help with one-off review, but they are manual, easy to forget, and weak for point-in-time comparison. A dependable backup workflow should create repeatable snapshots and store them outside the original Airtable base.
Does Airtable revision history replace an independent backup?
Native history can help explain recent changes inside Airtable, but it is not the same as an independent cloud copy with scheduled snapshots and a separate restore plan.
Where does Airhistory store Airtable backup files?
Airhistory writes snapshot bodies to the user's connected Google Drive or Dropbox account. The app database keeps safe metadata and connection state needed to operate the product.
Can Airhistory restore an Airtable backup?
Airhistory v1 is intentionally cautious: supported snapshot data can be restored into a new Airtable base. It does not overwrite an existing base.
What should I test after the first backup?
Confirm the snapshot completed, check that the expected base appears in history, open a snapshot detail page, and review at least one diff or table view so the team knows how to read backup history before a real incident.