Introduction

Taking a backup includes to consistently store the following data in a JS7 environment:

• Configuration data such as installation options and configuration items that are updated after installation, for example certificates and settings for HTTPS connections.
• JS7 - Inventory of workflows, jobs and dependencies.
• JS7 - History of past order and task executions, of deployments and submissions.
• JS7 - Daily Plan for future order executions.

JOC Cockpit

Configuration Data

The following JOC Cockpit configuration data are stored to files in the JETTY_BASE/resources/joc directory, for example:

• joc
  • start.ini (Jetty Servlet Container settings)
  • joc.properties (installer options, see JS7 - JOC Cockpit Configuration Items)
  • log4j2.xml (see JS7 - Log Files and Locations)
  • *.p12 (keystore and truststore files, see JS7 - JOC Cockpit HTTPS Connections)
  • lib
    • *.jar (optional location for JDBC Driver .jar files and the js7-license.jar file, see JS7 - Database).
  • license
    • *.pem, *.crt (license certificate files, see JS7 - How to apply a JS7 License Key)
  • patches
    • *.jar (patched libraries, see JS7 - Patches for JOC Cockpit)

Configuration data are created during installation and optionally are modified by users later on. This suggests that backups of configuration data are required only in case of changes by users.

Logging Data

JOC Cockpit log files are stored in the JETTY_BASE/logs directory.

Except for problem analysis log files are not too relevant, However, compliance reasons might suggest to backup log files.

Inventory Data, History Data, Daily Plan Data and Settings

All objects managed with JOC Cockpit are stored in the JS7 - Database. This includes any data that can be managed by the JOC Cockpit GUI such as Inventory, History, Daily Plan and Settings.

Users should take backups of the JS7 database on a regular basis. 

Controller

Configuration Data

All configuration data are available from files in the Controller's JS7_CONTROLLER_DATA/config directory, for example

• config
  • controller.conf (see JS7 - Controller Configuration Items)
  • log4j2.xml (see JS7 - Log Files and Locations)
  • lib
    • *.jar (optional location for the js7-license.jar file, see JS7 - How to apply a JS7 License Key)
  • license
    • *.pem, *.crt (license certificate files, see JS7 - How to apply a JS7 License Key)
  • patches
    • *.jar (patched libraries, see JS7 - Patches for Controller
  • private
    • private.conf (see JS7 - Controller Configuration Items)
    • *.p12 (keystore and truststore files, see JS7 - Controller HTTPS Connections)

Configuration data are created during installation and optionally are modified by users later on. This suggests that backups of configuration data are required only in case of changes by users.

Logging Data

Log files of the Controller (not: of workflows or jobs) are available from the Controller's JS7_CONTROLLER_DATA/logs directory.

Except for problem analysis the log files are not too relevant, However, compliance reasons might suggest to backup log files.

Transaction Data

Transaction data of Controller instances are available from the Controller's JS7_CONTROLLER_DATA/state directory that holds journal information about JS7 - Deployment and JS7 - Order State Transitions. This applies to Standalone Controller instances and to Controller Cluster instances.

• It is pointless to backup transaction data as they can change every millisecond.
• Restoring from a backup that is for example 30 minutes back is of no use as in between jobs will have been executed and orders will have proceeded which includes severe data loss and results in an inconsistent journal.
• Use of a cluster file system for the Standalone Controller instance's journal is an option. However, this includes performance penalties and requires manual intervention to restart a failed Standalone Controller instance from a clean copy of its journal.

The JS7 - Controller Cluster guarantees consistency of transaction data as they are synchronized between Active and Standby Controller instances on different machines. Should the Active Controller instance's journal be lost, for example due to disk failure, then the Standby Controller instance will pick up operation form a consistent copy of the journal. If the failed Controller instance is started later on then it will be assigned the standby role and will synchronize its journal from the Active Controller Instance.

Agent

Configuration Data

All configuration data are available from files in the Agent's JS7_AGENT_DATA/config directory, for example

• config
  • agent.conf (see JS7 - Agent Configuration Items)
  • log4j2.xml (see JS7 - Log Files and Locations)
  • patches
    • *.jar (patched libraries, see JS7 - Patches for Agent
  • private
    • private.conf (see JS7 - Agent Configuration Items)
    • *.p12 (keystore and truststore files, see JS7 - Agent HTTPS Connections)

Configuration data are created during installation and optionally are modified by users later on. This suggests that backups of configuration data are required only in case of changes by users.

Logging Data

Log files of the Agent (not: of workflows or jobs) are available from the Agent's JS7_AGENT_DATA/logs directory.

Except for problem analysis the log files are not too relevant, However, compliance reasons might suggest to backup log files.

Transaction Data

Transaction data of Agents are available from the Agent's JS7_AGENT_DATA/state directory that holds journal information about JS7 - Deployment and JS7 - Order State Transitions.

• It is pointless to backup transaction data as they can change every millisecond.
• Restoring from a backup that is for example 30 minutes back is of no use as in between jobs will have been executed and orders will have proceeded which includes severe data loss and results in an inconsistent journal.
• Use of a cluster file system for the Standalone Agent instance's journal is an option. However, this includes performance penalties and requires manual intervention to restart a failed Standalone Agent from a clean copy of its journal.

The JS7 - Agent Cluster guarantees consistency of transaction data as they are synchronized between Active and Standby Director Agent instances on different machines. Should the Active Director Agent's journal be lost, for example due to disk failure, then the Standby Director Agent will pick up operation form a consistent copy of the journal. If the failed Director Agent instance is started later on then it will be assigned the standby role and will synchronize its journal from the Active Director Agent.