Six tools, one backup file. Each one works because the backup keeps your workspace's full structure.
Counts and named exceptions for every backup — databases, rows, pages, views, relation links, files, comments, and the scope you picked. No percentages: a skipped file gets its name, its size, and its reason, because "99.8%" hides the one thing you needed to see. Anything that wasn't checked reads unknown, never a green check.
Below it, the Restore Simulator answers the next question without touching your workspace: how many pages this backup would rebuild, how many relations it would relink, and how long it would take — as a range anchored to real measured runs, not a made-up number.
Compares your backup to the live workspace and flags every structural difference — deleted or emptied databases, removed properties, retyped fields. Read-only; it never touches your live data. Run it anytime from the Restore screen.
The MIT-licensed CLI runs locally, on your schedule, and streams backups straight to your Google Drive, any S3-compatible bucket (R2, B2, Wasabi, Spaces), or a folder — your files never touch our servers. Setup takes about two minutes:
npx @restora/cli setup
Prefer hands-off? Restora Pro runs these same backups server-side — even when your laptop's off, and integrity-checks every one on arrival — files present and decodable, relations resolving. Same store-nothing model: your files still land only in your own Drive or S3.
Uses Notion's internal-integration token instead of OAuth. It never expires, meaning scheduled backups never hit the 30-day reconnect wall, and the token never leaves your local machine.
Uses Google's strict drive.file OAuth scope. The Restora CLI can only see and manage files and folders that it created. It cannot read any other files in your Google Drive.
Your credentials are encrypted and stored locally in ~/.restora/config.json (owner-only permission 0600). Backups stream directly from Notion to your storage; no intermediate server is ever involved.
| Command | Description |
|---|---|
| npx @restora/cli setup | Launches the interactive setup wizard: link Notion, connect Google Drive, and schedule daily backups. |
| restora status | Displays connection status, storage destination, local schedule, and last backup status. |
| restora backup | Triggers an immediate backup and streams it to your configured Google Drive. |
| restora backup --databases <id1>,<id2> | Backs up a specific subset of Notion databases (remembered for subsequent scheduled runs). |
| restora backup --to local --dir ./bk | Performs an instant backup directly to a local directory instead of cloud storage. |
| restora connect s3 | Launches the wizard to connect a custom AWS S3, R2, B2, Wasabi, or DigitalOcean bucket. |
| restora backup --to s3 | Runs a manual backup streaming directly to your custom S3-compatible bucket. |
| restora backup --keep 30 | Retention policy: maintains only the newest 30 backups in your target storage. |
| restora backup --keep-weeks 8 | Retention policy: prunes backups older than 8 weeks (the absolute newest is always retained). |
| restora schedule --daily 02:00 | Configures or removes (--remove) the local system daemon for daily backups at the specified time. |
The CLI streams your workspace straight to disk as it's fetched — each database and file is written out and released, so even multi-GB workspaces back up without eating your RAM (it also raises Node's memory automatically as a safety net). Because it paces itself to Notion's rate limit (~3 requests/sec), a big workspace simply takes a while — that's normal, just let it run.
Want to back up only part of it? List your databases and pick a subset — the selection is remembered for scheduled runs too:
restora databases # list your databases + ids
restora backup --databases id1,id2 # back up just those~/.restora/backup.log.Don't want to use Google Drive? Restora seamlessly connects directly with any S3-compatible storage provider. All authorization keys, access credentials, and database backups are stored completely locally. Your data remains completely under your control, even if restora.cc vanished tomorrow.
When you run restora connect s3 in your terminal, the wizard will ask for these 5 standard parameters. Your keys are encrypted locally and never transmitted to a Restora server.
| Provider | Target Endpoint URL | Required IAM Bucket Permissions |
|---|---|---|
| Amazon S3 | https://s3.<region>.amazonaws.com | PutObject, ListBucket, DeleteObject |
| Cloudflare R2 | https://<account-id>.r2.cloudflarestorage.com | Read / Write (API Token) |
| Backblaze B2 | https://s3.<region>.backblazeb2.com | Read and Write (Application Key) |
| Wasabi | https://s3.<region>.wasabisys.com | s3:PutObject, s3:ListBucket |
| DigitalOcean | https://<space-name>.<region>.digitaloceanspaces.com | Full Control / Custom Token |
Generate a standard IAM user key inside your AWS Console. Ensure your policy restricts access strictly to your backup bucket target to follow zero-trust best practices.
Navigate to your R2 Dashboard and click "Manage R2 API Tokens". Create a new token scoped to your target backup bucket with Edit access. Restora uses your custom Cloudflare Account ID to route the encrypted local stream.
Log into your Backblaze dashboard, go to "App Keys", and generate a new Application Key restricted to your specific your-backups-bucket bucket. Restora will automatically prompt you for your S3-compatible gateway credentials.
• Required inputs: Endpoint, Region, Bucket Name, Access Key ID, and Secret Access Key.
•
Security Best Practice: We highly recommend using access keys scoped strictly to a single bucket with only PutObject, ListBucket, and DeleteObject privileges active.
A local, read-only MCP server lets Claude Desktop, Cursor, Cline, Continue, or Zed read your backup files — instant, offline, no API calls. Restora makes no AI calls and holds no API key; your agent can never modify, delete, or even see your live Notion. "What was in Projects last week?" · "What changed since this backup?"
restora mcp --print-config
You now have access to my Notion backups via the Restora MCP server. Available tools: • list_backups — list local backup files with dates and sizes • describe_backup — full workspace map: databases, schemas, relations, views • query_database — rows of a database with resolved relations • get_page — a page's content rendered as Markdown • search — find pages by keyword across titles, properties, and content • read_id_map — old→new id map from a restore (for fixing broken links) • run_drift_audit — compare a backup against your CURRENT Notion (deleted/changed items) Everything is read-only. You cannot change my Notion or my files. Start by calling describe_backup to show me what's in my latest backup.
Agents and bulk-edit scripts can rewrite your whole workspace in seconds. restora guard is the seatbelt: one command before the agent runs takes a full snapshot, one command after diffs everything it touched — rows added, edited, removed, schema changes — entirely offline. Broke something? The snapshot is a full backup: restore it. For pipelines, --json and --fail-on-changes make it a CI gate.
A backup protects you; an alert tells you when to use it — before Notion's 30-day trash window empties permanently. Restora registers deletion events via Notion's webhooks the moment they happen (e.g. "A bulk deletion just ran against the database 'Tasks'") and emails you a direct link to restore. Privacy-centric: we're notified that a deletion occurred, never the contents.
A Notion export gives you files you can keep and read. But files alone don't recreate how your workspace worked — relations, rollups, views, and connected structure still need to be rebuilt.
Restora rebuilds databases, reconnects relations, restores views and hierarchy, and tells you what couldn't be recreated.
A disaster recovery tool is only worth trusting if it's completely transparent about its limits. Here are ours, up front.
All databases (properties, relations, rollups, views, filters), standalone pages & wikis with their nesting hierarchy, and attachments (up to 20MB per file on Free, 150MB on Pro).
A page's edit history — Notion's API doesn't expose it to any backup tool. Files over your plan's per-file cap (20MB on Free, 150MB on Pro) are skipped and named in the Coverage Report, alongside any whose download failed — counted separately, because only one of the two is a limit. Page comments are captured, and replayed on restore as new comments with the original author named — resolved threads and comments anchored to selected text can't be re-anchored.
Restored databases generate new page IDs in Notion, meaning edit history and authorships reset.
Restora protects you going forward. It cannot recover data you never backed up. No tool can once Notion's 30-day trash window closes. We prefer to tell you this upfront rather than surprise you later.
What a Notion export gives you, what most backup tools give you, and what Restora rebuilds. The figures in the Restora column are from our own July 4 validation run on a test workspace, not customer data.
| Capability | Notion Export (Markdown/CSV) | Other backup tools | Restora |
|---|---|---|---|
| Databases & Pages | Exported | Stored | Backed up & restored |
| Relations after restore | Lost | Relink by hand | Reconnected (138/138 in our test) |
| Rollups & Formulas | Empty | Not rebuilt | Recalculated (incl. rollup-of-rollup) |
| Views, Filters & Sortstable, board, list, calendar, timeline & gallery — page layouts named in the report | Lost | Not restored | Rebuilt (9/9 in our test) |
| Page hierarchy | Flattened | Varies | Restored 15 levels deep |
| Recovery effort | Days of manual re-linking | Days of manual re-linking | One click — minutes, not days |
| Backup verification | — | — | Pro backups self-checked on every run (files present & decodable, relations resolve; check any backup free) |
| Drift detection | — | — | Free Drift Auditor |
| AI-agent snapshot guard | — | — | restora guard |
| Ask-your-backup (MCP) | — | — | Local & read-only — your AI reads backups |
| Open-source CLI | — | Rarely | MIT-licensed |
| Where your data lives | Your ZIP | Their servers, usually | Your disk / your cloud — we store nothing |
Databases & Pages
Relations after restore
Rollups & Formulas
Views, Filters & Sorts
table, board, list, calendar, timeline & gallery — page layouts named in the report
Page hierarchy
Recovery effort
Backup verification
Drift detection
AI-agent snapshot guard
restora guardAsk-your-backup (MCP)
Open-source CLI
Where your data lives
Store-nothing by design. We can't read, sell, or lose what we never hold — and the CLI is free, MIT-licensed, and runs entirely on your machine, so you can verify it yourself.
For manual backups it lives only inside an encrypted, http-only session cookie — never written to a database, disk, or our logs. Turn on automatic scheduled backups and we keep one encrypted copy (AES-256-GCM, its own key) so runs can happen while you’re away — decrypted in memory for the run, and deleted the moment you disconnect. Everyone gets their own connection; there’s no shared key sitting on a server.
No backups or page content sit on our servers: the web app downloads straight to your device, the CLI writes to your own cloud. If you turn on automatic scheduled backups, that's the one exception: your content still never touches our servers — the backup streams through and lands only in your Google Drive or S3 — but to run it while you're offline, we store your Drive/S3 connection keys encrypted (AES-256-GCM), plus schedule and run metadata (when it ran, how many rows, nothing about what's in them). Outside of that opt-in feature, the only thing we store is an optional alert opt-in — your email, a workspace ID, a plan reference. Your data never depends on our uptime.
Prefer zero middleman? npx @restora/cli runs entirely on your machine — Notion straight to your disk, Google Drive, or S3, never touching our infrastructure. Backups are plain, open JSON you keep — and if Restora ever went dark, your data doesn’t go with it: the MIT-licensed npm package still reads, searches and verifies every backup from your own disk. Converting one to Markdown, CSV/Excel or an Obsidian vault runs in your browser with our free tools — nothing uploaded. No lock-in.
Images, PDFs, attachments, icons and covers are captured as actual bytes (up to 20MB each on Free, 150MB on Pro) — so a restore rebuilds your workspace, not just the words in it.
The one thing we won't hide: when a backup or restore runs in the web app, your content passes through our server's memory for that moment before it streams to you — never saved, never logged, but in-flight. That's true of any hosted tool. Your content is never stored on our servers — scheduled backups stream through and land only in your Drive/S3. To run backups while you're offline we store your connection keys encrypted (AES-256-GCM), plus schedule/run metadata. If even the in-flight moment is past your line, the CLI keeps everything on your own machine. Same engine, zero middleman.
No invented testimonials, no stock-photo customers. Here's what you can verify yourself, right now.
A live counter, straight from npm. We couldn't fake it if we wanted to.
The CLI that touches your data is public on npm. Read it, audit it, fork it.
Every restore claim on this page traces back to one real, logged run. See the logs ↑
"I built Restora after watching Notion users lose database schemas that no export could put back. So this is the tool that puts them back."
— Founder of Restora