Skip to content

Clarify backup/restore strategy regarding system db #2521

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: dev
Choose a base branch
from
Open

Clarify backup/restore strategy regarding system db #2521

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1c96dcb
Clarify backup/restore strategy regarding system db
NataliaIvakina Aug 4, 2025
9c7147b
Update planning.adoc
NataliaIvakina Aug 12, 2025
c670af6
Edit the note
NataliaIvakina Aug 15, 2025
a8d7711
Change the note
NataliaIvakina Aug 15, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
79 changes: 45 additions & 34 deletions modules/ROOT/pages/backup-restore/planning.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ If you have zero tolerance for downtime and data loss, you might want to conside
** use SSL/TLS for the backup network communication (online only).
** keep your databases as archive files (online or offline).
* How many backups you want to keep.
* Where the backups will be stored — drive or remote server, cloud storage, different data center, different location, etc.
* Where the backups will be stored — drive or remote server, cloud storage, different data center, different location, etc.
+
[TIP]
====
Expand All @@ -51,15 +51,14 @@ This ensures that if for some reason your Neo4j DBMS crashes, you will be able t
== Backup and restore options

Neo4j supports backing up and restoring both online and offline databases.
It uses xref:neo4j-admin-neo4j-cli.adoc[Neo4j Admin tool] commands, which can be run from a live, as well as from an offline Neo4j DBMS.
It uses xref:neo4j-admin-neo4j-cli.adoc[Neo4j Admin tool] commands that can be executed on a Neo4j DBMS, whether it is running or offline.
All `neo4j-admin` commands must be invoked as the `neo4j` user to ensure the appropriate file permissions.

* `neo4j-admin database backup/restore` (Enterprise only) -– used for performing online backup (xref:backup-restore/modes.adoc#full-backup[full] and xref:backup-restore/modes.adoc#differential-backup[differential]) and restore operations.
The database to be backed up must be in **online** mode.
The command produces an immutable artifact, which has an inspectable API to aid management and operability.
This command is suitable for production environments, where you cannot afford downtime.
+
The command can also be invoked over the network if access is enabled using `server.backup.listen_address`.
* `neo4j-admin database backup/restore` label:enterprise[Enterprise Edition] – used for performing online backup (xref:backup-restore/modes.adoc#full-backup[full] and xref:backup-restore/modes.adoc#differential-backup[differential]) and restore operations.
** The database to be backed up must be in **online** mode.
** The command produces an immutable artifact, which has an inspectable API to aid management and operability.
** This command is suitable for production environments, where you cannot afford downtime.
** The command can also be invoked over the network if access is enabled using `server.backup.listen_address`.
+
[NOTE]
====
Expand All @@ -73,9 +72,9 @@ For more information, refer to the xref:backup-restore/online-backup.adoc#backup
When using `neo4j-admin database backup` in a cluster, it is recommended to back up from an external instance as opposed to reuse instances that form part of the cluster.
====
* `neo4j-admin database dump/load` –- used for performing offline dump and load operations.
The database to be dumped must be in **offline** mode.
The dump command can only be invoked from the server command line and is suitable for environments where downtime is not a factor.
The command produces an archive file that follows the format _<databasename><timestamp>.dump_.
** The database to be dumped must be in **offline** mode.
** The dump command can only be invoked from the server command line and is suitable for environments where downtime is not a factor.
** The command produces an archive file that follows the format _<databasename><timestamp>.dump_.
* `neo4j-admin database copy` –- used for copying an offline database or backup.
This command can be used for cleaning up database inconsistencies and reclaiming unused space.

Expand All @@ -84,23 +83,9 @@ This command can be used for cleaning up database inconsistencies and reclaiming
File system copy-and-paste of databases is not supported and may result in unwanted behavior, such as corrupt stores.
====

=== Considerations for backing up and restoring databases in a cluster

Backing up a database in a clustered environment is not essentially different from a standalone backup, apart from the fact that you must know which server in a cluster to connect to.
Use `SHOW DATABASE <database>` to learn which servers are hosting the database you want to back up.
See xref:clustering/monitoring/show-databases-monitoring.adoc#show-databases-monitoring-listing-single[Listing a single database] for more information.
The following table summarizes the commands' capabilities and usage.

However, _restoring_ a database in a cluster is different since it is not known in advance how a database is going to be allocated to the servers in a cluster.
This method relies on the seed already existing on one of the servers.
The recommended way to restore a database in a cluster is to xref::database-administration/standard-databases/seed-from-uri.adoc[seed from URI].

[NOTE]
====
The Neo4j Admin commands `backup`, `restore`, `dump`, `load`, `copy`, and `check-consistency` are not supported for use on xref:database-administration/composite-databases/concepts.adoc[Composite databases].
They must be run directly on the databases that are associated with that Composite database.
====

.The following table describes the commands' capabilities and usage.
.`neo4j-admin` commands for backing up and restoring databases
[cols="<,^,^,^",frame="topbot",options="header"]
|===
| Capability/ Usage
Expand Down Expand Up @@ -184,18 +169,44 @@ They must be run directly on the databases that are associated with that Composi
| {check-mark}
|===


[NOTE]
====
The Neo4j Admin commands `backup`, `restore`, `dump`, `load`, `copy`, and `check-consistency` are not supported for use on xref:database-administration/composite-databases/concepts.adoc[Composite databases].
They must be run directly on the databases that are associated with that Composite database.
====


== Considerations for backing up and restoring databases in a cluster

Backing up a database in a clustered environment is not essentially different from a standalone backup, apart from the fact that you must know which server in a cluster to connect to.
Use `SHOW DATABASE <database>` to learn which servers are hosting the database you want to back up.
See xref:clustering/monitoring/show-databases-monitoring.adoc#show-databases-monitoring-listing-single[Listing a single database] for more information.

However, _restoring_ a database in a cluster is different since it is not known in advance how a database is going to be allocated to the servers in a cluster.
This method relies on the seed already existing on one of the servers.
The recommended way to restore a database in a cluster is to xref::database-administration/standard-databases/seed-from-uri.adoc[seed from URI].

[IMPORTANT]
====
When backing up a clustered database, be aware that the xref:clustering/introduction.adoc#clustering-introduction-operational[cluster topology] metadata is not included in the backup.
The cluster topology is stored in the `system` database and describes how the copies of a database should be spread across the servers in a cluster.

Because this metadata is excluded from backups, restoring to a new cluster environment requires manual reconfiguration of servers modes and database allocations.
====

[[backup-planning-databases]]
== Databases to backup
== Databases to back up

A Neo4j DBMS can host multiple databases.
Both Neo4j Community and Enterprise Editions have a default user database, called `neo4j`, and a `system` database, which contains configurations, e.g., operational states of databases, security configuration, schema definitions, login credentials, and roles.
In the Enterprise Edition, you can also create additional user databases.
Both Neo4j Community and Enterprise Editions have a default user database named `neo4j` and a `system` database.
The `system` database contains configurations, e.g., operational states of databases, security configuration, schema definitions, login credentials, and roles.

In the Enterprise Edition, you can also create multiple user databases.
Each of these databases is backed up independently of one another.

[NOTE]
====
It is very important to store a recent backup of your databases, including the `system` database, in a safe location.
====


[[backup-planning-additional]]
== Additional files to back up
Expand All @@ -215,4 +226,4 @@ If you have a cluster, you should back up these files for each cluster member.

For any backup, it is important that you store your data separately from the production system, where there are no common dependencies, and preferably off-site.
If you are running Neo4j in the cloud, you may use a different availability zone or even a separate cloud provider.
Since backups are kept for a long time, the longevity of archival storage should be considered as part of backup planning.
Since backups are kept for a long time, the longevity of archival storage should be considered as part of backup planning.