Backups and recovery

Each Ctadel instance is backed up once a day to an object storage space of its own, hosted in France. Restoring is a manual operation by the Ctadel team, to a point in time chosen among the available backups. This page describes both procedures.

The daily backup

A scheduled task on the instance's server runs the backup every day at 03:00. It proceeds in four phases:

1. Export of the instance's database (findings, users, settings, encrypted credentials, audit log), compressed, then verified.
2. Hot copy of the security graph (the inventory and its relationships), compressed, then verified.
3. Cleanup: deletion of local copies older than 7 days, then of remote copies older than 30 days.
4. Verdict: if a phase failed, the backup is reported as failed to the Ctadel team.

Each archive is uploaded as soon as it is ready and verified: a failed graph copy does not prevent the database export already produced from being sent off-site. Remote cleanup is skipped on a night when a phase failed, so the last good backup is not pruned on a night without a new one.

Item	Value
Time	03:00, server time
Destination	Scaleway object storage, Paris region, one space per customer
Content	One database export and one graph copy per day
Local retention	7 days, on the instance's server
Remote retention	30 days, in the storage space
Storage access credentials	Held by Ctadel, reserved to server administration

What the backup does not hold

The cloud credentials' encryption key is not in the archives. It lives in the instance's configuration and in the set of secrets Ctadel keeps for each customer. Restoring onto an instance created with another key leaves every cloud account with "invalid credentials"; the instance creation procedure provides for reusing the original secrets in that case.

Scan orders and updates in transit inside the instance are not backed up: they are regenerated at the next run.

Restoring

Restoring happens on the instance's server, by hand, by the Ctadel team, which picks the backup among those available: a precise point in time or the most recent. The database and the graph are restored to the same point, after an explicit confirmation, since current data is replaced.

1. Download of both archives and verification of each before anything is touched: an empty or corrupt archive stops the procedure without changing anything.
2. Database restore in a single transaction that stops at the first error: an export that does not apply in full is rolled back and the database stays as it was.
3. Graph restore: stop of the components that write to it, extraction of the archive next to the current data, then swap; the current data is removed only once the archive is fully extracted. If the procedure fails while the components are stopped, they are restarted on the current data.
4. Restart of the components and check that the application answers, for one minute at most; otherwise the procedure is reported as failed.

The graph restore causes a short unavailability of the application. The graph is in any case regenerated from the inventory at the next run.

Limits

• The graph copy is taken hot, with no transactional consistency guarantee; this is accepted because the graph is rebuilt at each run. The reference backup is the database export.
• One backup a day: a restore loses at most the day's changes (findings, settings, users, audit log).
• Restoring is global: the database and the graph to the same point, the whole instance. There is no partial restore (one account, one user, one period).
• Restoring is not available from the interface; it requires an intervention by the Ctadel team on the server.
• The archives are not encrypted before upload; their protection rests on the object storage's access control, whose key is held by Ctadel and shared across instances (see Service security). The cloud credentials they hold stay encrypted with the instance's key, which is absent from the archives.
• The failure alert goes to the Ctadel team, not to your channels; the application does not show the state of backups.
• The backup is not watched by the "System status" card: a scheduled task that does not run at all, without an error, is detected only by Ctadel.