Reliability and disaster recovery
The platform stores certain data that must be backed up and restored in the event of a disaster.
Backup
Backup of the platform is carried out by the system administrator, ensuring that the following elements are backed up:
| Element | Criticality level | Recommended backup frequency |
|---|---|---|
| Postgresql | ➕➕➕ ⚠️ Critical ⚠️ | Daily |
| S3 | ➕➕ Moderate | Weekly |
| Agents | ➕➕ Moderate | (can be backed up by SSC to ensure optimal service continuity) |
| Redis | ➕ Low (stateless) | (can be backed up by SSC to guarantee optimum service continuity) |
| Frontend | Null (stateless) | None |
| Backend | Nulle (stateless) | None |
Postgresql
In kubernetes deployment, backup can be configured using helm bitnami backup functionality
By default with the QALITA helm, this backup is not active, once activated, the backup is performed in a PVC which must itself be backed up in cold or semi-cold storage.
S3
S3 storage is less critical than the database, as it only contains logs or archives of packages whose code is already versioned in a system like gitlab. In the event of a failure, restoring S3 storage and losing data is therefore less critical.
In kubernetes deployment, S3 storage is backed up by backing up the PVC containing the data.
PVC and backup : Backing up PVCs is generally the responsibility of the Kubernetes cluster administrator. If you are not in charge of managing your Kubernetes cluster, be sure to check that PVCs are backed up by contacting the cluster administrator.
Agent
Agents need to store information about :
- The sources (file
qalita-conf.yaml): to reach file paths or query databases, this information is not stored in the platform, so it's important to save this file or guarantee its persistence. In qalita deployment, it is possible to activate the deployment of a local agent, and to activate the persistence of the~/.qalita/folder to guarantee the persistence of this information. - At platform connection (file
.agent) contains information about the last connection to the platform. See agent configuration documentation,
It is strongly recommended to use environment variables for authentication. However, in file-based authentication mode, a .env-<login> file containing platform login information for a certain <login> user, these files are temporary, contain sensitive information and ⚠️ should not be saved ⚠️.
- To pack execution results (folder
~/.qalita/agent_temp_run/) contains pack execution results, it is possible to configure the folder~/.qalita/agent_temp_run/to be persistent and saved.
Restore
Postgresql
To restore a Postgresql backup, please refer to Bitnami documentation
S3
To restore an S3 backup, please refer to SeaweedFS documentation
Agents
- Agent re-registration in the platform:
To restore an agent's information, simply restart the agent,
qalita agent loginand copy the agent's~/.qalita/folder. - Restore sources:
Next, restore the source configuration file
qalita-conf.yaml. - Source id synchronization with the platform:
To synchronize source ids with the platform, use the
qalita source pushcommand. This will reassign the source ids to the local sources, allowing you to associate the tasks to be carried out on the sources, as well as their results.