Practical guide
Restore a Notion Journal Database: Properties Are Not Entry Text
Restoring a Notion database can restore its pages and properties without restoring the text inside those pages. Inspect the database fields and each journal entry body separately. If an entry’s writing needs an earlier version, use that entry’s own page history; preview changed views and keep current access rules in mind.
Separate database properties from the entry body
In a journal database, Entry date, Status or another column can be a property, while a paragraph opened inside an entry page is its body. They may appear together on screen, but they do not have the same restoration scope.
Notion’s restore help says a database restoration restores all of its pages and properties, while contents such as text inside those pages are not restored. To restore database page contents, it says you need an earlier version of each individual page. Do not treat a returned row or corrected date column as proof that the entry’s writing was recovered.
Sources: [1].
| Part of the record | Relevant restoration scope | Evidence still needed |
|---|---|---|
| Entry row/page and database properties | Database’s earlier version can restore pages and properties | Which rows and property values actually returned. |
| Paragraphs inside an entry page | The individual page’s earlier version | The text actually present after that page’s restoration or selected-block copy. |
| Database view | A restore can change views to earlier settings | The view you now see and whether its fields/filter/layout match the task. |
| Restricted columns | Current column-access rules remain in place according to the help | The operator’s actual authorized visibility; no old access rule automatically restored. |
On a narrow screen, scroll inside the table. Keyboard users can focus the region and use the arrow keys.
Preview the actual database restoration scope
- Identify the database and the missing object: a property value, a row/page, or writing inside one entry. Record the current values and text you want to retain.
- Open the database’s available Version history using the documented controls and required access. Preview the candidate version and the changes before choosing Restore.
- For a page containing an inline database, inspect the actual option to restore or not restore its database pages and properties. Do not assume that option selects every entry’s body text.
- If you restore the database version, compare the resulting rows and property values with the target. Then inspect the important entry bodies separately.
- Keep the database version/time and unresolved body-text questions in different fields; proceed to the individual page’s history when that is the source needed.
Sources: [1].
The separate page and Trash recovery guide explains available history, access and selected-block copying. An inaccessible earlier version remains inaccessible; this page does not create a source or extend a retention window.
Compare two fictional entries field by field
This invented example describes expected inspections, not the output of an actual restore. Entry 1 has an incorrect date property and Entry 2 has lost a body sentence. Both rows are still visible; row count alone cannot diagnose either difference.
| Object being checked | Current versus wanted evidence | Inspection or source needed |
|---|---|---|
| Entry 1 date property | Current date is 10 November; wanted recorded date is 9 November | Check the database property value after any chosen database restoration. |
| Entry 1 body | Current paragraph includes a newer note that should remain | Read the paragraph after the action; do not assume a property correction changed or preserved all text. |
| Entry 2 date property | Date already matches the intended record | Keep it separate from the missing body sentence. |
| Entry 2 body | A sentence exists in an available earlier entry-page version, not in the current body | Use that entry’s own page history and inspect the recovered sentence. |
| Database row count | Two rows before the change; two rows afterward | Equal counts do not establish either correct dates or recovered body text. |
On a narrow screen, scroll inside the table. Keyboard users can focus the region and use the arrow keys.
Recover entry text from the entry’s own version
Open the actual entry page whose writing needs recovery. Inspect its available version and compare the needed passage with current writing. Notion documents either copying selected blocks from a past page version or restoring that page version to become current.
If you need only one sentence while keeping newer notes, compare the selective-copy route before choosing a full page restoration. After the action, read the resulting entry and record which current writing and earlier text remain. A database restoration is not a substitute for that entry-body inspection.
Sources: [1].
Database track
Preview and inspect row/page and property changes.
Entry track
Open the individual page version containing the needed writing.
Preserve current text
Choose selected blocks or a whole-page version deliberately.
Reconcile
Verify properties, entry bodies and current view as separate outputs.
Original explanatory workflow.
Check views, inline options and current access rules
Notion warns that restoring a database can change existing views because the earlier version may use different view settings. A familiar row count or hidden column does not prove that every underlying record matches the intended version. Inspect the actual view and the content you are authorized to see.
The help also says a database with column visibility/editing limits keeps its current column rules after a restoration, rather than bringing back older rules. Do not use restoration as a way to obtain hidden journal information or assume that old permissions return with old property values.
Sources: [1].
Case 1
A database Restore returns the expected two journal rows and date properties. Has the lost sentence inside Entry 2 necessarily returned?
Show answer and explanation for case 1
No. Inspect Entry 2 and its own available page version.
The documented database restoration scope covers pages and properties but does not restore text inside the pages. Matching row counts and dates do not establish recovered body content.
Case 2
An earlier database version used a different view and column-access arrangement. Should the reader assume both return identically?
Show answer and explanation for case 2
No. Inspect the view and retain the current access boundary.
The help says views can change with restoration, while current column-access rules remain. These two effects are different; a restore does not authorize access to a hidden column.
Verify the complete result instead of a row count
Keep a final record of the database identity and version, inspected rows/properties, each entry body checked, current view and unresolved gaps. A successful check means the relevant actual fields and writing match the intended result; it is not merely a completed Restore click.
Use the Notion export guide when you need a separate portable or readable copy. Use the journal file and recovery chooser for other tools and sources.
Notion’s English documentation was checked on 11 November 2026. The examples are illustrative. Match the available version and controls to your actual database and entry pages.
Sources and further reading
- Notion Help: Delete & restore contentComplete written scope: database pages/properties versus individual page contents, inline-database choice, current column-access rules, changed views and selected-block/page restoration. Checked 11 November 2026; no private app test.