Backup and restore

Everything the system owns sits in one database. There is no second file store to remember, and the system runs no backup mechanism of its own — its database is covered by the backup routine you already run.

What is in there, and what happens if it is lost

What	If lost
Events, windows, the invitations issued and the checklist responses	No other source
Settings, update types and templates, forms, task templates, freeze periods	No other source
Whatever a person recorded or decided: custom field values, notes, a vulnerability's status, an approved exception	No other source
The change log	No other source, and subject to the retention policy
Dashboards, saved views and queries	No other source
Uploaded files — a corporate presentation template, for instance	Held inside the database, so they are covered by the same backup
The capacity measurement series	Cannot be reconstructed from the current state
The inventory reflection: hosts, systems, owners, equipment, databases and the connections between them	Re-read from the source
Exports, reports already sent, and caches	Regenerated

Restoring

A restore returns the database to the state it was in, including the structure it had in the version it came from. Keep a copy of that version's installation package: on a disconnected network there is nowhere to download it again, and see Version upgrades for the forward direction.

What is not in the database

The vulnerability intake directory holds input files. Whatever has been ingested is already in the database, and a file that could not be read stays in the failures directory with a companion file explaining what failed — so the directory is a work queue, not an archive to preserve.

The change log and the retention policy

The default is to keep everything: with no policy set, no row is deleted. Once a retention policy is in place, a backup taken before a purge holds rows that no longer exist in the live system, so the two will not reconcile row for row.