Skip to content

KAZOO Support Channels

This documentation is curated by 2600Hz as part of the KAZOO open source project. Join our community forums here for peer support. Only features in the docs.2600hz.com/supported space are included as part of our 2600Hz Support Services plan.

Snapshots#

Overview#

Snapshots provide a way of saving the state of various entities for later restoration. This capability is very powerful and also very flexible. However incorrectly used, or used without a full understanding of the effects WILL cause system state problems and WILL lead to reported "issues".

Because the ability to restore arbitrary states to the system has such a high potential for causing undefined behavior if not correctly used it is HIGHLY RECCOMENDED THAT YOU DO NOT USE THIS FEATURE UNLESS ABSOLUTELY NECESSARY.

Snapshots will affect ALL accounts and ALL entities that are local to the node being run in.

Currently Supported Entities#

Recipients#

Recipient snapshots will save all current stats / login state / away state for a recipient. Current wrapup state / call state / offer state will NOT BE SAVED. Recipients will remain logged in after the snapshot is taken.

Due to the extremely noticable nature of restoring a snapshot to recipient state, restoration is only allowed for LOGGED OUT recipients. When restoring a snapshot all recipients contained in the snapshot will be logged back in, and restored to the state when the snapshot was taken.

Important Information / Caveats#

Currently a snapshot will save the state of all recipient processes that are locally primary in whichever node it is run on.

When restoring a snapshot it will restore all saved recipients in whichever node it is run on. This does not need to be the same node they were saved on. This could be dangerous if misused.

The restore will start the recipient process, and restore the state. Restoration will not work if the recipient process is already running.

NOTE after taking a snapshot you MUST shutdown the qubicle app GRACEFULLY

Usage#

Saving a snapshot#

Snapshots can be created with arbitrary ID's, it is useful to include the date and reason for creating the snapshot however.

# sup qubicle_maintenance save_snapshot {SNAP_ID}

Restoring a snapshot#

# sup qubicle_maintenance restore_snapshot {SNAP_ID}

Deleting a snapshot#

# sup qubicle_maintenance delete_snapshot {SNAP_ID}

Listing all current snapshots#

# sup qubicle_maintenance list_snapshots

Purging all snapshots#

WARNING, there is no confirmation for this. Only run this command if you are REALLY sure you want to do this.

# sup qubicle_maintenance purge_snapshots

Use Cases / Examples#

Restarting a node#

Please note that in all of these cases it is VERY VERY important that you run the stop_app qubicle to gracefully shut down the node you are snapshotting before you attempt to restore the snapshot.

If a Qubicle note needs to be restarted, snapshots can be used to save the state of all recipients that are primary on that node.

# sup qubicle_maintenance save_snapshot {SNAPID}

# sup kapps_maintenance stop_app qubicle


<RESTART OF SERVER OR NODE OR JUST QUBICLE>


# sup qubicle_maintenance restore_snapshot {SNAPID}

# sup qubicle_maintenance delete_snapshot {SNAPID}

Taking a node out of service#

If a node must be taken out of service, a snapshot can be used to move the recipient processes to a different node manually.

# sup qubicle_maintenance save_snapshot {SNAPID}

# sup kapps_maintenance stop_app qubicle


ON DIFFERENT NODE RUNNING QUBICLE:

# sup qubicle_maintenance restore_snapshot {SNAPID}

# sup qubicle_maintenance delete_snapshot {SNAPID}