Backup and restore
This feature is not available in AuraDS. |
This feature is in the alpha tier. For more information on feature tiers, see API Tiers.
In the Neo4j Graph Data Science library, graphs and machine learning models are stored in-memory. This is necessary mainly for performance reasons but has the disadvantage that data will be lost after shutting down the database. There are already concepts to circumvent this limitation, such as running algorithms in write mode, exporting graphs to csv or storing models. The back-up and restore procedures described in this section will provide a simple and uniform way of saving graphs and models in order to load them back into memory after a database restart.
Note, that there exists only one backup at the same time. Calling backup will override the previous backup. For multiple users, it is recommended that an admin user performs the backup and restore operations, as they have access to all graphs and models.
The |
Syntax
CALL gds.backup(configuration: Map)
YIELD
backupId: String,
backupTime: LocalDateTime,
exportMillis: Long
Name | Type | Optional | Description |
---|---|---|---|
configuration |
Map |
yes |
Additional parameters to configure the backup. |
Name | Type | Default | Description |
---|---|---|---|
concurrency |
Integer |
4 |
The number of concurrent threads used for performing the backup. |
includeGraphs |
Boolean |
true |
Flag to decide whether only models or also graphs should be backed up. |
useLabelMapping |
Boolean |
true |
Flag to decide whether to use node label mapping when exporting the graph. See exporting graphs to csv for details. |
Name | Type | Description |
---|---|---|
graphName |
String |
The name of the persisted graph or an empty string if a model was persisted instead. |
modelName |
String |
The name of the persisted model or an empty string if a graph was persisted instead. |
exportPath |
String |
Path where the backups are stored at. |
backupTime |
LocalDateTime |
Point in time when the backup was created. |
exportMillis |
Long |
Milliseconds for creating the backup |
status |
String |
Status of the persistence operation. Either |
CALL gds.restore(configuration: Map)
YIELD
restoredGraph: String,
restoredModel: String,
status: String,
restoreMillis: Long
Name | Type | Optional | Description |
---|---|---|---|
configuration |
Map |
yes |
Additional parameters to configure the restore. |
Name | Type | Default | Description |
---|---|---|---|
concurrency |
Integer |
4 |
The number of concurrent threads used for performing the restore. |
Name | Type | Description |
---|---|---|
restoredGraph |
String |
The name of the restored graph or an empty string if a model was restored instead. |
restoredModel |
String |
The name of the restored model or an empty string if a graph was restored instead. |
status |
String |
Status of the restore operation. Either |
restoreMillis |
Long |
Amount of time restoring took in milliseconds. |
Examples
All the examples below should be run in an empty database. The examples use Cypher projections as the norm. Native projections will be deprecated in a future release. |
First we need to create a graph in the corresponding Neo4j database.
CREATE
(alice:Person {name: 'Alice'}),
(bridget:Person {name: 'Bridget'}),
(alice)-[:KNOWS]->(bridget)
Now we need to project an in-memory graph which we want to back-up.
MATCH (n:Person)-[r:KNOWS]->(m:Person)
RETURN gds.graph.project('myGraph', n, m)
We can now run the back-up procedure in order to store the in-memory graph on disk.
CALL gds.backup()
YIELD graphName, status
graphName | status |
---|---|
|
|
It is now safe to drop the in-memory graph or shutdown the db, as we can restore it at a later point.
CALL gds.graph.drop('myGraph')
If we want to restore the backed-up graph, we can simply run the restore procedure to load it back into memory.
CALL gds.restore()
YIELD restoredGraph
restoredGraph |
---|
|
As we can see, one graph with name myGraph
was restored by the procedure.