Airtable backup: records vs schema

“Airtable backup” means two genuinely different jobs, and most people searching for it only have one of them in mind. Getting the distinction right decides which tool you actually need — and whether you need one at all.

Short version. If you are worried about losing records, you want a record backup tool like On2Air or ProBackup — SchemaWard does not do that and is not trying to. If you are worried about a field type change or a deleted field silently breaking your views, filters, and automations, that is a schema problem, and it is what SchemaWard exists for.

Check your schema free

The two kinds of backup

	Record backup	Schema backup
What it protects	Row/record values in your tables	Table + field structure, types, select options
Typical failure it covers	Someone bulk-deleted 4,000 records	Someone changed a field type and broke every automation
Data it must read	Every record value (your actual data)	Schema definitions only — never record values
Restores	Records back into the base	A structural restore plan you apply
Tools	On2Air Backups, ProBackup	SchemaWard

What Airtable already gives you

Airtable has a trash and a revision history, and for small accidents they are often enough — a deleted record or a handful of edited cells can usually be recovered within the retention window on your plan. Two things they do not give you: a durable copy outside Airtable, and any notion of a structural version you can diff. Revision history tells you a field changed. It does not tell you that the change converted a single-select to text and discarded every option definition that four automations depended on.

Why schema is the gap most teams miss

Record loss is loud. Someone notices immediately, and there is a clear recovery path. Schema drift is quiet: a field is retyped or renamed, and nothing appears broken until a Zapier scenario stops firing, a filtered view silently empties, or a sync writes to a field that no longer accepts the value. By the time the symptom surfaces, the change is often days old and nobody remembers making it.

That is the failure SchemaWard watches for: it snapshots your base structure on a schedule, detects renames using stable Airtable field IDs rather than guessing from names, and flags type changes and select-option removals as breaking before you find out from a broken automation.

Zero-PII: why we read schema only

SchemaWard requests schema.bases:read and nothing else. It reads table and field definitions — names, types, select options — and never record values. That is enforced in code and covered by tests, not just stated in a policy. The practical benefit is that adopting it does not widen your data exposure: there is no copy of your customer data sitting in our systems, because we never fetch it.

Which should you use?

Records are your worry — bulk deletes, a bad import, an automation writing garbage. Use On2Air Backups or ProBackup. They do this properly and we do not compete with them.
Structure is your worry — a teammate or app changes field types, deletes fields, or edits select options and breaks downstream tooling. That is SchemaWard.
Both — they are complementary, not alternatives. A record backup restores values into a structure that has to still be correct.

Start with the free inspector. Paste a schema export and get a health report, or compare two exports to see exactly what changed between them. Nothing you paste is stored.

Open the Schema Inspector