7 This script is used to enable or disable the config datastore persistence. The
8 default state is enabled but there are cases where persistence may not be
9 required or even desired. The user should restart the node to apply the changes.
13 The script can be used at any time, even before the controller is started
20 bin/set_persistence.sh <on/off>
26 bin/set_persistence.sh off
28 The above command will disable the config datastore persistence.
30 .. _cluster_backup_restore:
32 Backing Up and Restoring the Datastore
33 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
35 The same cluster-admin API described in the :ref:`cluster guide <cluster_admin_api>`
36 for managing shard voting states has an RPC allowing backup of the datastore in a single
37 node, taking only the file name as a parameter::
39 POST /restconf/operations/cluster-admin:backup-datastore
45 "file-path": "/tmp/datastore_backup"
51 This backup can only be restored if the YANG models of the backed-up data
52 are identical in the backup OpenDaylight instance and restore target
55 To restore the backup on the target node the file needs to be placed into the
56 ``$KARAF_HOME/clustered-datastore-restore`` directory, and then the node
57 restarted. If the directory does not exist (which is quite likely if this is a
58 first-time restore) it needs to be created. On startup, ODL checks if the
59 ``journal`` and ``snapshots`` directories in ``$KARAF_HOME`` are empty, and
60 only then tries to read the contents of the ``clustered-datastore-restore``
61 directory, if it exists. So for a successful restore, those two directories
62 should be empty. The backup file name itself does not matter, and the startup
63 process will delete it after a successful restore.
65 The backup is node independent, so when restoring a 3 node cluster, it is best
66 to restore it on each node for consistency. For example, if restoring on one
67 node only, it can happen that the other two empty nodes form a majority and
68 the cluster comes up with no data.