Page History
...
Introduction
Taking a backup includes to involves consistently store storing the following data in a JS7 environment:
- Configuration Data
- This includes installation options and configuration items that which are updated after installation, for example certificates and settings for HTTPS connections.
- Log Data
- Log files are created and updated continuously and are mainly used for problem analysis. As past log files are not used at run-time many users consider them not be an immediate target of backups.
- Inventory Data
- JS7 - Inventory of workflows, jobs and related objects managed with JOC Cockpit.
- Transaction Data
- JOC Cockpit
- JS7 - History of past order and task executions, of deployments and order submissions.
- JS7 - Daily Plan for future order starts.
- Controller and Agent
- JS7 - Order State Transitions that which are persisted persistent to allow restart capabilities.
- JOC Cockpit
- Log Data
- Log files are created and updated continuously and are mainly used for problem analysis. As past log files are not used at run-time many users consider them not be an immediate target of backups.
JOC Cockpit
Configuration Data
The JOC Cockpit configuration data are is stored to in files in the JETTY_BASE/resources/joc
directory hierarchy, 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 thejs7-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 is created during installation and is optionally are modified by users later on. This suggests This implies that repeated backups of configuration data are only required only in case of changes after changes have been made by users.
Log 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, Transaction Data
All objects managed with the JOC Cockpit are stored in the JS7 - Database.
This includes data that are is managed by the JOC Cockpit GUI:
- Inventory Data
- JS7 - Inventory of workflows, jobs and related objects to that manage dependencies.
- JS7 - Settings that determine the working of the JOC Cockpit.
- JS7 - Controllers and Agents that are managed by the JOC Cockpit.
- JS7 - Identity Services that are managed by the JOC Cockpit.
- JS7 - Profiles that hold user preferences.
- Transaction Data
- JS7 - History of past order and task executions, of deployments and submissions.
- JS7 - Daily Plan for future order starts.
Users should take make backups of the JS7 database on a regular basis.
- The database backup tool is required to create consistent backups
...
- in situations such as concurrent transactions - for example, new items being added to the JS7 History while a backup is being performed.
- The database backup tool should not interfere with JS7 database transactions and should not affect JS7 operations.
- If no decent backup tool is in place then users can shut down the JOC Cockpit and make a backup by exporting the JS7 database.
Log Data
JOC Cockpit log files are stored in the JETTY_BASE/logs
directory.
Log files are not too relevant except for problem analysis, However, compliance reasons can require backups of log files.
Controller
Configuration Data
The Controller's configuration data are is available from in files in the JS7_CONTROLLER_DATA/config
directory hierarchy, for example:
config
controller.conf
(see JS7 - Controller Configuration Items)log4j2.xml
(see JS7 - Log Files and Locations)lib
*.jar
(optional location for thejs7-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 is created during installation and is optionally are modified by users later on. This suggests implies that repeated backups of configuration data are only required only in case of changes by users.
Log 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.
after changes have been made by users.
Transaction Data
Transaction data of Controller instances are available from is available in the Controller's JS7_CONTROLLER_DATA/state
directory that which holds a the journal of JS7 - Deployment of Scheduling Objects operations and JS7 - Order State Transitions. This applies to Standalone Controller instances and to Controller Cluster instances.
- It is pointless to backup There is little point in backing up transaction data as they it can change every millisecond.
- Restoring from a backup that is, for example, 30 minutes back old is of no use as in between times jobs will have been executed and orders will have proceeded which includes . This will result in severe data loss and results in an inconsistent journal.
Standalone Controller
- Use of a cluster file system for the Standalone Controller instance's journal is an option. However, this includes also brings performance penalties and requires user intervention to restart a failed Standalone Controller instance from a clean copy of its journal.
- Should If transaction data of for a Standalone Controller be is lost then this affects will affect the state of orders that which are currently running or for which the and that of orders whose execution status has not yet been reported back to the JOC Cockpit. When a Standalone Controller is started with a new journal then:
- the JOC Cockpit will automatically re-assign the Controller and related Agents,
- users will have to redeploy any related scheduling objects such as workflows from the JOC Cockpit's inventory,
- users will have to resubmit any orders from the JOC Cockpit's Daily Plan.
...
- The JS7 - Controller Cluster guarantees redundancy and consistency of transaction data that are which is synchronized between Active and Standby Controller instances on different machines.
- Should If the Active Controller instance's journal be is lost, for example due to disk failure, then the Standby Controller instance will pick up operation form from a synchronized 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.
Log Data
Log files for the Controller (not: for workflows or jobs) are available in the Controller's JS7_CONTROLLER_DATA/logs
directory.
Log files are not too relevant except for problem analysis, However, compliance reasons can require backups of log files.
Agent
Configuration Data
The Agent's configuration data are is available from in files in the JS7_AGENT_DATA/config
directory hierarchy, 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 is created during installation and is optionally are modified by users later on. This suggests This implies that repeated backups of configuration data are only required only in case of changes after changes have been made by users.
...
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 for Agents is available in the Agent's JS7_AGENT_DATA/state
directory that which holds a the journal of JS7 - Deployment of Scheduling Objects operations and JS7 - Order State Transitions.
- It is pointless to backup There is little point in backing up transaction data as they it can change every millisecond.
- Restoring from a backup that is, for example, 30 minutes back old is of no use as in between times jobs will have been executed and orders will have proceeded which includes . This will result in severe data loss and results in an inconsistent journal.
Standalone Agent
- Use of a cluster file system for the Standalone Agent instance's journal is an option. However, this includes also brings performance penalties and requires user intervention to restart a failed Standalone Agent from a clean copy of its journal.
- Should If transaction data of for a Standalone Agent be is lost then this affects will affect the state of orders currently running orders , until their execution status is has been reported back to the Controller. When a Standalone Agent is started with a new journal then the Controller will automatically forward workflows and orders to bring the Agent's journal in sync with information from the Controller's journal.
- Do not try to restore a version of the Agent's journal that is not in sync with the Controller. If an older version of an Agent's journal is restored then this will be inconsistent with latest changes to the Controller's journal and will prevent the Agent from being coupled. If you have to restore an Agent, for example after disk failure, then you have to accept that currently running orders are lost and you should start the Agent with a new journal. To this end you can remove the contents of the Agent's
state
directory.
Agent Cluster
- The JS7 - Agent Cluster guarantees redundancy and consistency of transaction data that are which is synchronized between the Active and Standby Director Agent instances on different machines. Should If the Active Director Agent's journal be is lost, for example due to disk failure, then the Standby Director Agent will pick up operation form from a synchronized 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.
- Subagents do not make use of a journal as they are used for job execution only. Workflows and order state transitions are managed by the Director Agent only.
Log Data
Log files for the Agent (not: for workflows or jobs) are available from the Agent's JS7_AGENT_DATA/logs
directory.
Log files are not too relevant except for problem analysis. However, compliance reasons can require backups of log files.