A complete backup starts with everything the API will give

Every tool claims completeness, and no tool can deliver all of it. NotionManager does three things: it takes everything the API will give, it rebuilds the structure between the parts, and it states the limits exactly.

Read everything the API will give

The first half is to read everything and interpret nothing: every root you shared, every page, every database, every property, every block, followed down through the child pages until nothing is left. The copy starts as raw material. Anything you filter or reshape at this stage cannot be recovered later.

Unless you ask for a filter, such as skipping comments or skipping file downloads, NotionManager tries to fetch everything it can so the local backup is complete. The final rendering may differ because of style differences, but the data itself is always complete and reliable.

Then rebuild what the raw data means

The second half puts the structure back. Notion is a graph as well as a tree. Pages point at each other through mentions and relations, rollups compute values across those relations, and databases are read through views that select and order their rows. A folder of JSON keeps the same bytes but loses all of that meaning.

Rebuilding the relations makes the copy browsable and auditable. You can follow a relation to the page it names. You see a rollup as the value it held, not as a formula that no longer resolves. You open a database and read the rows the view was showing.

What the rebuild covers

  • Page structure

    The full page structure, with rendering for every supported block type, such as rich text and callouts.

  • Page references

    A page that mentions another page keeps that link inside the copy, so following it works offline.

  • Database relations

    When a row points at a row in another database, the copy keeps it as a relation between the copied pages, not as a loose identifier.

  • Rollups

    NotionManager keeps computed values as the values they held at the time of the run. A historical copy should show the values from that moment.

  • Views

    Each view is copied together with the data it presents: the rows, their properties and the order the view put them in.

  • External media files

    Images, videos, audio and PDFs, exactly as they appear in Notion.

The checklist, stated plainly

Part of a workspaceIn the backup?
Pages, their blocks and their nestingYes. Read down to the last child page.
Databases, their data sources and propertiesYes, including the properties each row carries.
Rows as pagesYes. Each row is a page with its own content.
Relations and mentions between pagesYes. Rebuilt so the links work inside the copy.
Rollups and other computed valuesYes. Kept as the values they held when the run happened.
The rows and order behind each viewYes. The data the view presented.
The appearance of a view: colours, grouping, layoutPartly. The API does not return all of it, and the copy follows Notion styles as closely as it can.
CommentsPartly. Only unresolved comments are backed up. Backing up comments needs its own switch, because it slows the backup down badly.
External media filesYes. By default every external media file is downloaded locally, for the best offline reading. If you would rather not, you can turn the download off.
Block types the API declines to describePartly. Kept as their declared type and position, with a clear mark on the page, so you can see where data is missing.
Workspace permissions, sharing and guest accessNo. That is Notion’s configuration, not content.
Anything you did not share with the integrationNo. The copy contains exactly what you granted.

Why the checklist is short and honest

A backup tool that claims to store everything has not looked closely at the API. The list above shows what the Notion API can give anyone. The last three rows matter most: they are why a backup adds to Notion instead of replacing it.

The useful test is not whether the copy is complete in theory. It is whether you can open it and check for yourself. That is what the browsable copy is for.

The good news is that, as a user, everything you can see in Notion can be backed up. What cannot be backed up is mostly styling and special structures, and none of that affects the value or the validity of the backup.

Check your own copy

Take a backup, open it offline, and follow a relation or two. What you find should match the checklist above.

Where to go next

Frequently asked questions

Does a complete backup include attached files?

Files are part of the content. Whenever the API offers them, NotionManager reads them in, including files behind an external link. Some file links are issued only temporarily and then stop working, so NotionManager prefers to download every file locally. You can still control that behaviour.

Why are view colours and layouts not backed up?

Because Notion offers no interface that returns them. NotionManager restores view styles as closely as it can, but it does not promise to match Notion exactly.

If rollups are stored as values, are they wrong after a restore?

They are right for the moment the copy was taken. A historical copy should show what the workspace said then, not what a formula would say now.

Is “complete” the same as “everything”?

No. No Notion backup can honestly claim that. Complete means everything the API will give, structured the way Notion structures it, with the parts the API refuses stated openly.