Skip to main content

Backing up and restoring Flowable applications

Creating a backup

Hot backup

A hot backup can be performed while the Flowable Work or Engage application is running. As Flowable applications persist data in several places (Database, Elasticsearch and optionally file system), it is recommended to backup the application data while it is idle and no users or background processes are active.

The backup of the data has to be performed strictly in the following order:

  • Database

  • Elasticsearch

  • Content data (e.g. binary content from the filesystem)

Disclaimer: Creating the snapshots for all three systems is not an atomic operation and there will be a certain delay. Only in cases where the application is completely idle and no operation is running a backup will be fully consistent. If there is some data mismatch between the database and Elasticsearch, a reindex would be able to fix them. On the other hand, discrepancies between the content data and database (i.e. a file has been deleted) will require manual intervention for a fix. Cold backups do guarantee a 100% data consistency.

Backing up the database system

Each database type provides different tooling and commands to create backups. Refer to your database vendor documentation to proceed with this step.

Creating an Elasticsearch snapshot

This step is optional but recommended for applications with reasonable amount of data where a full reindex would delay too much the restoration process.

Please refer to the documentation of the installed ES version:

  • If you’re using >6.8 you can follow this link.
  • If you're using 7.x you can follow this link.

Back up the indices defined in (here). Please note that they might appear with a prefix if the property flowable.indexing.index-name-prefix has been set.

If the app makes use of custom indices (See Custom Aliases), they should be included as well.

Content Storage

If your application is using a database content store strategy, the backup will be done as part of the database backup.

By default, Flowable stores binary data under a specific folder. Back up this information by saving the folder contents somewhere. Unless the property has been set, by default this folder is named content and can be found in the user home.

In case you configured another content storage please consider from the third party provider (e.g. AWS S3, Azure Blob Storage).

Cold backup

This type of backup is performed when the application is stopped and cannot be done when the application has strong uptime requirements. The process is as follows:

  • Stop all nodes running Flowable Work/Engage. Database and Elasticsearch nodes can still run.

  • Back up both database and file system. See the procedure of “Hot Backup”. This can be done in parallel.

  • Depending on the system load, allow some time for Elasticsearch to process the pending indexing operations. Then perform a snapshot as described in the “Hot Backup” section.

  • Once all data has been saved, start again all Flowable Work/Engage nodes.

Restoring from a backup

If a system must be restored to a previous state, follow these steps:

  • If Flowable Work/Engage is still running, stop it.

  • Content Storage

    • If the content storage strategy is set to file system, then replace the contents of the root folder ( with the backed up data.
    • If the content storage strategy is set to database, then the restore will happen as part of the database restore.
    • If the content storage strategy is set to neither of both, then restore the content data in your third party provider (e.g. AWS S3, Azure Blob Storage).
  • Restore the database from the backup as described by the database vendor procedure.

  • If an Elasticsearch snapshot is available, you can restore is as described by Elastic: Otherwise a reindex is required (See Reindexing).

  • When all previous steps have been done, Flowable Work/Engage can be started.