Data Directories & Backup

An Athena server keeps its state in a handful of directories on disk: the database, the PKI, all bulk file storage (uploaded packages, agent and helper installers, session recordings), the Windows Update scan catalog, logs, audit files, the settings you save in the console, and a few keys the server needs to stay itself across restarts. This page is the single map of what those directories are, which setting points at each, where they live on the virtual appliance, and exactly what you must back up before an upgrade, a disaster, or a move to a new host.

The server data directory (Server:DataDirectory)#

Besides bulk storage, the server writes a small set of files at runtime that it needs to stay itself: the settings you save in the console, per-install secrets, its encryption keys, database backups and the uploaded WSUS catalog. All of these go to one data directory, set by the Server:DataDirectory key (environment variable Server__DataDirectory). The appliance keeps it in /data/athena, the same directory that holds the SQLite database and the appliance's install.json.

The appliance also points two other files into the same directory through their own keys: the database (Database:ConnectionString → /data/athena/athena.db) and the licence file (Licensing:FilePath → /data/athena/license.lic.cer, see Licensing).

Without a data directory (direct install)#

When Server:DataDirectory is not set, which is typical for a direct install, the data directory is the server's application folder (for example, next to Athena.Server.exe). Settings are still saved to appsettings.local.json there, and secrets.json and DataProtection-Keys sit beside it. Three items keep their older application-folder locations:

• Database backups: Backups\ in the application folder.
• WSUS catalog: Data\wsusscn2.cab in the application folder.
• Deployment package folders: Data\Deployments\ in the application folder.

The server never writes to the shipped appsettings.json. That file holds the defaults and can be replaced safely on upgrade. Your changes live in appsettings.local.json. For how the two files are layered, see Configuration sources.

The data map#

Every persistent location is controlled by a setting you can override through configuration (an appsettings.json key or the matching environment variable). The appliance ships with defaults for each, so the server comes up with no extra configuration. The paths shown are where each item lives on the appliance; on a direct install the same settings resolve relative to the server's working directory unless you set an absolute path.

Placing storage with Storage:DataRoot#

Storage:DataRoot is the one key that decides where all bulk storage lives. Set it once and each area is placed in a named subdirectory beneath it:

For each area, the server resolves the location in this order, taking the first that is set:

1. The area's own override key (the right-hand column above). Set this only when you want to move a single area onto its own disk or volume; it beats the data root for that one area.
2. Storage:DataRoot — the area lands in its named subdirectory beneath the root. This is what the appliance uses (/data/storage), and it's the setting to reach for in almost every deployment.
3. An operating-system default — used only when nothing above is configured. On a bare Windows service install this preserves the historical <CommonApplicationData>\Athena\<area> location so existing data is still found.

# Put all bulk storage on a dedicated data volume (env-var form)
Storage__DataRoot=/mnt/athena-data

# …or in appsettings.json
"Storage": {
  "DataRoot": "/mnt/athena-data"
}

# Relocate just one area (recordings) onto its own disk, leaving the rest under the root
Recording__StoragePath=/mnt/recordings

A note on the database#

With the default SQLite provider the whole database is a single file (/data/athena/athena.db), so backing up /data/athena captures it. If you run PostgreSQL instead, the data lives in your PostgreSQL server rather than in /data/athena (the appliance's optional local PostgreSQL keeps its data in /data/postgres) — back it up with your database's own tools (for example a pg_dump), and treat the directories on this page as everything except the database. Either way, the built-in database backup writes timestamped copies to /data/athena/backups, where the appliance also keeps the database backup it takes before every update. They sit on the same disk as the live database, so copy them off the appliance regularly for real disaster recovery.

What to back up#

For a full recovery you need the database plus the on-disk state that isn't reconstructable. The table below groups each directory by how important it is to a restore.

Restoring or moving to a new host#

To rebuild the server on new hardware or after a disaster:

1. Restore the backed-up directories into place — at minimum the database and the PKI, plus the whole data directory (saved settings, secrets and data-protection keys) and any others you kept. On the virtual appliance, contact support@sealgrid.ai for a guided restore.
2. Start the server with the same Server:PublicUrl so it presents the same externally-reachable address. Because the Root CA is restored, existing agents keep trusting the server without re-enrollment.
3. If the new server has a different address, redirect your agents to it — see Agent Server Migration.

Keeping directories from filling up#

Several of these directories grow over time — recordings, logs, audit files, and accumulated backups. Athena prunes some of them automatically and lets you schedule the rest; the settings, defaults, and which cleanups are automatic versus manual are covered in Data Retention & Housekeeping. In short: session recordings age out on a retention window, database backups are not pruned automatically (rotate them yourself), and log/audit files roll by date.

Related#

• Installation — importing the appliance and the first-boot wizard.
• Configuration — every setting and how to pass it as an environment variable.
• Database Backup & Maintenance — on-demand and scheduled database backups.
• Data Retention & Housekeeping — what removes the data that grows.
• Certificates & PKI — the Root CA and issued agent certificates.
• Agent Server Migration — repointing agents at a moved server.