NotionManagerNotionManager
Back to Home

Data integrity statement

Last updated: 2026-09-24

This document answers three questions: what is actually inside your backup, whether you can trust it, and when it will not be complete.

Summary

  • Every backup is a full backup.
  • A backup contains pages, databases and data sources, database views, database rows, blocks, comments (with a switch), users, file attachments and external media files (with a switch).
  • The same content is stored once. Both the data itself and standalone files are deduplicated, so deleting one version does not break files that other versions still reference.
  • Every backup produces a full backup report, with counts for pages, databases, database rows, blocks, comments, views and users, plus any warnings or errors.
  • Export and import of an archive both carry an integrity check.
  • Integrity has limits: anything outside the integration's permissions, fields the Notion API does not return, a few known issues on Notion's side, and the per-run object cap on the free tier.

1. What a backup contains

One backup contains:

  • Pages: body content, properties, icon, cover and their place in the hierarchy
  • Databases and data sources: the property schema, options and relations
  • Database views: the configuration of table, board, calendar, timeline, gallery and list views, along with their filters, sorts and groups
  • Database rows: the property values of every row
  • Blocks (body content): inline formatting and nested structure
  • Comments: unresolved comments on a file or a block. The Notion API does not return resolved comments, so they cannot be backed up. Whether comments are backed up at all has its own switch
  • Users: the collaborator information that appears in the content, used to restore who wrote what
  • Attachment files: images and files hosted by Notion
  • External media files: external files linked in a page, such as PDFs, images and videos. Whether these files are downloaded has its own switch

Every file downloaded to your machine is rewritten to a relative reference inside the repository, so moving the repository directory or changing machines does not break those references.

All of it is stored in the repository directory you chose. The structured snapshots are in the local database file inside the repository, and the downloaded files are under the attachments directory in the repository.

2. How integrity is ensured

Full crawl. Every backup walks the whole range you shared with the integration and re-reads the current state of each object, one by one. The Notion API offers no reliable change feed, so an incremental backup cannot be guaranteed complete in principle.

Skipping at the write layer. A full crawl is not a full rewrite: a snapshot whose content has not changed does not need rewriting, and the same content is not stored twice. The changed and skipped counts in the report describe exactly that difference.

Crash safety. If the machine loses power or the program crashes mid-backup, the task can be re-entered safely without damaging the integrity of existing data.

Content-addressed deduplication. Block content is stored by content hash, and references to it are counted.

Standalone file deduplication. Attachments are deduplicated by a stable file identity.

Backup report. When a backup ends it gives you counts for pages, databases, database rows, blocks, comments, views and users, plus changes and skips, failures and warnings.

Archive export and import. Before a full-repository archive (the single-file export for cold backup) is written, pending writes to the repository database are flushed to disk, so the archive holds a complete, consistent state. On import, the database inside the archive is checked for integrity first. If the check fails, the import is refused with an error.

3. Integrity limits

Backup scope. NotionManager gives you finer control, so you choose what to back up. Anything not shared with the integration, or not selected into the backup scope, is never walked.

Known limits of the Notion API:

  • Unsupported block types. The Notion API documentation states that some block types are not supported, and the data in those blocks is unavailable to any app that depends on the Notion API.
  • View styling and which properties can be displayed: these affect only how the copy looks when you browse it locally.

Management information on Notion's side. Version history (page history) and trash data are outside what the Notion API provides, and therefore outside the backup.

4. License limits

You can use NotionManager for free, but features are limited. The limits that concern data integrity are these:

  • Free tier: a cap on the number of objects in a single backup task, and a cap on view browsing (you can open one view only). The object cap counts per task, so you can create several profiles and split a large workspace across several backups; within each task's limit, the data is backed up in full.
  • Personal licenses (Basic and Premium): full-repository archive export and import are not supported.

Other features are tied to particular licenses and do not concern data integrity, so they are not discussed here.

5. What we ask of you

  • Keep copies on the 3-2-1 rule: copy the whole repository directory to another medium (an external drive, a NAS, object storage). Your license has nothing to do with this step. A local backup also disappears with a failed disk, a deleted directory or ransomware, and the offsite or offline copy is the one you keep for exactly that. Teams and enterprise users can also use a full-repository archive (a single-file package) for archiving and for moving to another machine.
  • Check the backup report and confirm that the counts match the size of your workspace. If a count looks wrong, find out why before you rely on that backup.
  • Watch the health of your disks. Bad sectors on the disk that holds the backup repository damage the backup directly, so keep the repository on reliable storage and put the offline copies on different media.