Clarify how to restore a database backup in cluster#3035
Clarify how to restore a database backup in cluster#3035NataliaIvakina wants to merge 13 commits into
Conversation
NataliaIvakina
force-pushed
the
dev-update-restore-docs
branch
from
e18a9a3 to
41c68fd
Compare
Co-authored-by: Natalia Ivakina <82437520+NataliaIvakina@users.noreply.github.com>
Co-authored-by: Natalia Ivakina <82437520+NataliaIvakina@users.noreply.github.com>
NataliaIvakina
force-pushed
the
dev-update-restore-docs
branch
from
5aaf495 to
905ba55
Compare
| ---- | ||
| SHOW DATABASES; | ||
| ---- | ||
| . After the new database is online, you can drop the old database `foo` if it is no longer needed, or put it into read-write mode if you want to keep it for other purposes. |
There was a problem hiding this comment.
To double check - it should be read-write mode? or read-only?
There was a problem hiding this comment.
I would say that depends on what the customer wants to do with it.
I think this might be copied from the SPD documentation for copy and there the first part is setting the database into read-only mode when taking the backup that we then copy from to ensure that we get a consistent backup over multiple shards. In this case the documentation seems to start with the backup and not how that was obtained and then we don't know the status of the database foo. It might even be an old already deleted database that we have a backup of that we now restore using copy to foo-restored.
So not sure if we need this, if we keep it then we could maybe write something like "if the database foo was put into read-only mode before taking the backup it can now be put back into read-write if you want to keep it for other purposes"?
| [[copy-data-store-from-backup]] | ||
| === Copy the data store from a backup | ||
|
|
||
| The following example assumes that you have a backup of your existing database `foo` in an AWS S3 bucket. |
There was a problem hiding this comment.
To double-check: we are speaking about a backup created with neo4j-admin database backup command, aren't we?
There was a problem hiding this comment.
Yes, or if you use the copy command with the new --target-format=backup --target-location=S3 bucket
|
This PR includes documentation updates Updated pages: |
EmelieBondesson
left a comment
EmelieBondesson
left a comment
There was a problem hiding this comment.
Mostly looks good but I have some comments/questions
| [[copy-data-store-from-backup]] | ||
| === Copy the data store from a backup | ||
|
|
||
| The following example assumes that you have a backup of your existing database `foo` in an AWS S3 bucket. |
There was a problem hiding this comment.
Yes, or if you use the copy command with the new --target-format=backup --target-location=S3 bucket
|
|
||
| `--source-location` and `--source-format` cannot be used together with `--from-path-data` and/or `--from-path-txn` due to the conflict in trying to supply data from two different locations at once. | ||
|
|
||
| . Copy the data from a backup of your standard database `foo` into the database `foo-restored`. |
There was a problem hiding this comment.
This will not create a database, only a new backup of the new database named foo-restored. That is because the --target-location=s3://bucket/folder --target-format=backup are specified.
You can still create the database foo-restored as specified below by seeding from the new backup, but the phrasing might be a little confusing, maybe better to say "into a backup for the database `foo-restored`" or something similar
| ---- | ||
| SHOW DATABASES; | ||
| ---- | ||
| . After the new database is online, you can drop the old database `foo` if it is no longer needed, or put it into read-write mode if you want to keep it for other purposes. |
There was a problem hiding this comment.
I would say that depends on what the customer wants to do with it.
I think this might be copied from the SPD documentation for copy and there the first part is setting the database into read-only mode when taking the backup that we then copy from to ensure that we get a consistent backup over multiple shards. In this case the documentation seems to start with the backup and not how that was obtained and then we don't know the status of the database foo. It might even be an old already deleted database that we have a backup of that we now restore using copy to foo-restored.
So not sure if we need this, if we keep it then we could maybe write something like "if the database foo was put into read-only mode before taking the backup it can now be put back into read-write if you want to keep it for other purposes"?
|
|
||
| * `--source-location` -- a path to the full backup of an existing database or the last differential backup in the chain. | ||
| This folder can be located locally or remotely (e.g., an S3 bucket) and must contain the full backup and all the differential backups in the chain, if any. | ||
| * `--source-format=backup` -- the format of the source backup. |
There was a problem hiding this comment.
Quick question why do we specify these options here again since we already have them in the table above for all options for copy?
And the --source-format=backup --source-location does not have to be used together with --target-format=backup --target-location specifying them like this might give that impression?
There was a problem hiding this comment.
yeah, true. I was under impression that it is required to use --source-format=backup --source-location together with --target-format=backup --target-location
|
|
||
| [role=label--new-2026.03] | ||
| [[restore-database-using-copy-command]] | ||
| === Restore a database backup using the `neo4j-admin database copy` command |
There was a problem hiding this comment.
This looks copied from the other page for copy so we should remember to apply the changes made there here as well
4 participants
Our restore documentation is very standalone minded. This PR attempts to cover methods on how to restore a clustered database from a backup or dump file.