Storage

Airtable backup to Google Drive or Dropbox

What should live in your cloud folder, what stays in Airhistory metadata, and how to avoid exposing provider internals.

7 min guide

Guide status

ContentPractical launch guide

FocusAirtable cloud backup storage

UpdatedMay 31, 2026

In this guide

Overview

Quick answer

Use Google Drive or Dropbox as the user-owned storage layer for Airtable backup files. Airhistory should write snapshot JSON to the selected cloud folder, keep tokens and provider internals server-side, and show only safe folder labels and backup status in the browser.

A backup folder is not just a file destination. It answers a business question: who owns the copy if the original Airtable base or app account has a problem?

For Airhistory, Google Drive and Dropbox are the user-owned storage options. The snapshot body belongs in the connected cloud account. The app keeps safe metadata so it can list history, run schedules, and open the correct snapshot later without exposing raw provider internals to the browser.

This guide explains how to choose the storage owner, organize backup folders, and review a snapshot destination without turning cloud paths, provider IDs, or OAuth details into user-facing copy.

Before you start

What to confirm before setup

Decide whether Google Drive or Dropbox is the standard backup destination for the account.

Use a cloud account controlled by the business or client, not a temporary personal folder.

Create a simple folder structure that a non-technical owner can understand later.

Connect cloud storage before creating schedules.

Do not paste OAuth codes, provider IDs, raw cloud paths, or tokens into chat, tickets, or public docs.

Expect old backup files to remain where they were created unless a later file-migration pass is explicitly approved.

Step-by-step

Follow the workflow in order

Choose the cloud owner

The storage owner should be the person or organization that needs long-term access to the backup files. For client work, that is usually the client-controlled cloud account.

Avoid folders owned by a contractor who may leave later.
Use a shared business account or shared drive structure when appropriate.
Document who can access the folder.

Connect Google Drive or Dropbox

Use the dashboard connection flow. Airhistory handles provider OAuth server-side and should only return safe connection status to the browser.

Connect one active cloud provider for the account.
Reconnect if the provider scope or access model changed.
Treat lost-connection alerts as backup health issues, not cosmetic warnings.

Pick destination folders per Airtable base

Each protected Airtable base should have a clear destination folder. This prevents one busy account from becoming a pile of unnamed snapshot files.

Use labels like Client CRM Backups or Operations Base History.
Keep production and test backup folders separate.
Use safe labels in the browser instead of raw cloud paths or file IDs.

Run a manual snapshot

A manual snapshot proves that the selected folder can receive backup files. It also gives the team a concrete file and history entry to inspect.

Run one snapshot per protected base before scheduling.
Confirm the snapshot appears in Airhistory history.
Confirm the cloud destination is the one you expected.

Keep metadata and backup bodies separate

The backup body should live in the connected cloud provider. The app database should store only what it needs to operate safely: ownership, status, timing, and safe references.

Do not expose provider file IDs in the interface.
Do not show raw provider errors to users.
Use safe destination labels when a human needs context.

Plan folder cleanup manually

Cloud files are user-owned. If an account is deleted or a base is no longer protected, the user should decide whether to keep or delete old backup files in Google Drive or Dropbox.

Do not assume app deletion should delete cloud folders.
Keep retention rules written down for clients or regulated workflows.
Review old backup folders during offboarding.

Checklist

Use this before you call the backup ready

1The cloud provider is connected from the dashboard.

2The folder owner is the organization that should retain the backup files.

3Each protected base has a readable destination folder label.

4A manual snapshot has written to the selected destination.

5Browser-visible status uses safe labels only.

6Support messages avoid provider IDs, raw cloud paths, OAuth codes, tokens, and raw provider errors.

7Manual cleanup expectations are documented before account deletion or client handoff.

FAQ

Questions people ask before trusting this workflow

Should Airtable backups go to Google Drive or Dropbox?

Use the provider your business already controls and audits. Google Drive and Dropbox can both work as user-owned storage destinations when the folder owner, access, and cleanup process are clear.

Can I choose a folder for each Airtable base?

Yes. Airhistory's dashboard flow is designed around saved destinations for protected bases so manual and scheduled snapshots can use the right folder without asking for a path every time.

Should raw cloud paths or file IDs appear in the browser?

No. The browser should show safe labels and status text. Provider file IDs, raw paths, tokens, OAuth codes, and raw provider errors should stay out of browser-visible pages and support copy.

What happens to backup files if an account is deleted?

Cloud files remain user-owned. The user should manually delete any Airhistory folders or snapshot files they no longer want in Google Drive or Dropbox.