diff --git a/modules/ROOT/pages/backup-restore/online-backup.adoc b/modules/ROOT/pages/backup-restore/online-backup.adoc index e8eb175e7..995d65cc7 100644 --- a/modules/ROOT/pages/backup-restore/online-backup.adoc +++ b/modules/ROOT/pages/backup-restore/online-backup.adoc @@ -66,7 +66,8 @@ For more information, see xref:backup-restore/online-backup.adoc#online-backup-c ---- neo4j-admin database backup [-h] [--expand-commands] [--prefer-diff-as-parent] [--verbose] [--compress[=true|false]] [--keep-failed[=true|false]] - [--parallel-recovery[=true|false]] [--additional-config=] + [--parallel-recovery[=true|false]] [--remote-address-resolution + [=true|false]] [--additional-config=] [--include-metadata=none|all|users|roles] [--inspect-path=] [--pagecache=] [--temp-path=] [--to-path=] [--type=] [--from=[,...]]... [...] @@ -164,6 +165,10 @@ Note: this is an EXPERIMENTAL option. Consult Neo4j support before use. |label:new[Introduced in 2025.04] When performing a differential backup, prefer the latest non-empty differential backup as the parent instead of the latest backup. |false +|--remote-address-resolution[=true\|false] +|label:new[Introduced in 2025.09] Allow the DBMS to automatically determine which servers are eligible to serve as backup sources, instead of requiring manual selection. +|false + |--temp-path= |Provide a path to a temporary empty directory for storing backup files until the command is completed. The files will be deleted once the command is finished. | @@ -358,10 +363,26 @@ To view the latest processed transaction IDs (and other metrics) in Neo4j Browse ==== ==== Targeting multiple servers + It is recommended to provide a list of multiple target servers when taking a backup from a cluster, since that may allow a backup to succeed even if some server is down, or not all databases are hosted on the same servers. If the command finds one or more servers that do not respond, it continues trying to backup from other servers and continues backing up other requested databases, but the exit code of the command is non-zero, to alert the user to the fact there is a problem. If a name pattern is used for the database together with multiple target servers, all servers contribute to the list of matching databases. +[role=label--new-2025.09] +==== Using `--remote-address-resolution` + +Starting from 2025.09, the `--remote-address-resolution` option is available. +When enabled, the DBMS automatically selects the most appropriate servers to act as backup sources for a given database. + +By default, the online backup command requires the user to determine which servers host the target database and direct the command to one of them. +With remote address resolution enabled, the DBMS performs this mapping automatically, removing the need for manual server selection. + +The server selection occurs in the following order: + +* The DBMS first selects all servers hosting the database in secondary mode. +* If it is not possible to back up from one of the secondaries, the DBMS attempts to take a backup from the primary followers before finally trying the database primary writer. + + [[online-backup-example]] == Examples diff --git a/modules/ROOT/pages/backup-restore/planning.adoc b/modules/ROOT/pages/backup-restore/planning.adoc index d7ad162bb..bb05e236b 100644 --- a/modules/ROOT/pages/backup-restore/planning.adoc +++ b/modules/ROOT/pages/backup-restore/planning.adoc @@ -183,6 +183,9 @@ Backing up a database in a clustered environment is not essentially different fr Use `SHOW 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. +Starting from 2025.09, you can use the `--remote-address-resolution` option to let the DBMS select which servers to use as backup sources. +See xref:backup-restore/online-backup.adoc#_using_remote_address_resolution[Back up an online database -> Cluster configurations] for more details. + Restoring from the command line involves putting a copy of the database on disk on each server that will need it. That can be awkward to achieve. The recommended way to restore a database in a cluster is to xref::database-administration/standard-databases/seed-from-uri.adoc[seed from URI].