docs/getting-started-guide/persistence_and_backup.rst

   1 Persistence and Backup
   2 ======================
   3
   4 Set Persistence Script
   5 ^^^^^^^^^^^^^^^^^^^^^^
   6
   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.
  10
  11 .. note::
  12
  13   The script can be used at any time, even before the controller is started
  14   for the first time.
  15
  16 Usage:
  17
  18 .. code-block:: bash
  19
  20    bin/set_persistence.sh <on/off>
  21
  22 Example:
  23
  24 .. code-block:: bash
  25
  26    bin/set_persistence.sh off
  27
  28 The above command will disable the config datastore persistence.
  29
  30 .. _cluster_backup_restore:
  31
  32 Backing Up and Restoring the Datastore
  33 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  34
  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::
  38
  39     POST  /restconf/operations/cluster-admin:backup-datastore
  40
  41     or
  42
  43     POST  /rests/operations/cluster-admin:backup-datastore
  44
  45 RPC input JSON::
  46
  47     {
  48       "input": {
  49         "file-path": "/tmp/datastore_backup"
  50       }
  51     }
  52
  53 .. note::
  54
  55   This backup can only be restored if the YANG models of the backed-up data
  56   are identical in the backup OpenDaylight instance and restore target
  57   instance.
  58
  59 To restore the backup on the target node the file needs to be placed into the
  60 ``$KARAF_HOME/clustered-datastore-restore`` directory, and then the node
  61 restarted. If the directory does not exist (which is quite likely if this is a
  62 first-time restore) it needs to be created. On startup, ODL checks if the
  63 ``journal`` and ``snapshots`` directories in ``$KARAF_HOME`` are empty, and
  64 only then tries to read the contents of the ``clustered-datastore-restore``
  65 directory, if it exists. So for a successful restore, those two directories
  66 should be empty. The backup file name itself does not matter, and the startup
  67 process will delete it after a successful restore.
  68
  69 The backup is node independent, so when restoring a 3 node cluster, it is best
  70 to restore it on each node for consistency. For example, if restoring on one
  71 node only, it can happen that the other two empty nodes form a majority and
  72 the cluster comes up with no data.