Backup And Restore

In 1.0, backup and restore are your responsibility. BareBones Ticketing 1.0 ships no backup or restore tooling — no scheduled backup, no dump command, no restore command, no product-managed recovery. Verified against the product source: there is no pg_dump, pg_restore, or pg_basebackup anywhere in the product, its installers, or its runbooks, and nothing captures the database on your behalf at install or upgrade. The database is stateful and unmanaged; it persists because PostgreSQL persists it, and protecting it is the customer's job.

The recommended approach for 1.0 is a system-level backup of the host (the machine or volume, taken by your infrastructure's normal backup) paired with a PostgreSQL dump and restore owned and run by a qualified DBA. This page tells you what to capture and in what order; the actual database commands are the DBA's, established and rehearsed before an incident.

The product provides no backup or restore tooling. Backup and restore are yours to run, using the guidance below.

A BareBones Ticketing backup is four things captured at one point in time, not a database dump. This page names the four, gives the capture and restore order for each deployment family, and lists the four checks that show a restore worked.

What your backup has to cover — the shape of it

A backup that captures the database alone cannot restore this installation. Hand whoever owns your backup system this shape, and make sure every part is captured at the same point in time — a set that mixes points in time will not restore.

The PostgreSQL database. The whole application database — tickets, users, departments, projects, settings, licence state, and the audit history. Owned and captured by your DBA with their own pg_dump/pg_restore (or snapshot or replication) method.
The attachments. The files behind the attachment records. The database holds pointers; the files live on disk. Lose these and restored tickets point at files that are not there.
The Data Protection key ring folder, whole. It decrypts your protected settings and signs session cookies, and the managed HTTPS certificate lives inside it. Copy the folder, not the key files within it — export the files alone and you silently drop the certificate.
The deployment configuration and its secrets story. The exact versioned package or bundle with its checksum, the environment/config files, and — on Windows — the install directory. Plus a written record of where each secret value is retrieved or re-entered from, because the secret values are deliberately not in the backup.

The rest of this page is the detail: exactly where each of the four lives on Windows and Linux, the capture and restore order, and how to prove a restore worked. If you read nothing else, capture all four together and rehearse the restore once before you need it.

The four continuity classes

Back these up together, at a compatible point in time. A set that mixes points in time is not restorable.

Class	What it holds	If you lose it
PostgreSQL data	Tickets, users, departments, projects, settings, licence state, audit rows	Everything
Attachments	The files behind attachment records	Database rows point at files that are not there
Data Protection key ring folder	The key ring that decrypts protected settings and signs session cookies, and the managed HTTPS certificate file stored inside the same folder	Protected settings stop decrypting; sessions break; the managed certificate is gone
Deployment configuration	The exact versioned package or bundle and its checksum, the environment or configuration file, and on Windows the `install` directory	You cannot rebuild the installation the data belongs to

Copy the whole key ring folder. The managed HTTPS certificate .pfx sits in a subfolder of it. An operator who exports the key XML files instead loses the certificate, and nothing reports the loss.

The fourth class has a part that is deliberately not in the backup: secret values. Record where an authorized operator retrieves or re-enters each protected value. Do not put the values themselves in a backup manifest, a ticket, or a log.

On Windows the four classes live here:

Class	Location
PostgreSQL data	`C:\ProgramData\BareBonesTicketing\postgresql\data` in local database mode; otherwise the external server
Attachments	`C:\ProgramData\BareBonesTicketing\attachments`
Data Protection key ring folder	`C:\ProgramData\BareBonesTicketing\keyring`, complete — it also holds the managed HTTPS certificate
Deployment configuration	`C:\ProgramData\BareBonesTicketing\config`, `C:\ProgramData\BareBonesTicketing\install`, and the versioned package with its checksum

The install tree is part of the backup set, not an optional extra. In local database mode it holds an administrator-only local-database maintenance credential that is recoverable from nothing else. Treat it as secret-bearing.

On Linux the four classes are the PostgreSQL volume, the attachments volume, the key-ring volume, and the package root: docker-compose.yml, .env, configure-database.sh, RUNBOOK.md, artifact-manifest.json, the image artifact, and the recorded checksums. The .env file is secret-bearing.

The PostgreSQL commands are yours, not the product's

BareBones Ticketing does not ship a backup command, and this manual does not name one. The pg_dump, pg_restore, snapshot, or replication method belongs to whoever owns the PostgreSQL server this installation uses. That is the local BareBonesTicketingPostgreSQL18 service on Windows, the db container on Linux — both run PostgreSQL 18 — or an external server your organization already runs.

Establish the exact commands before an incident, not during one. Write them into your own runbook. The commands must satisfy all of the following:

They name the PostgreSQL major version and the database this installation uses.
They capture the complete application database, not selected tables.
The restore command reverses the capture command on that same PostgreSQL version, and someone has run it end to end at least once against a spare target.
Credentials come from your secret store, not the command line.
They state whether the database must be quiesced during capture, and how the application is stopped and started around that.
They produce a recorded recovery point you can name later.

If any of that is missing, you do not have a backup procedure yet. Do not improvise a command during an outage, and do not copy one from a different installation.

Back up a Windows installation

Open your approved maintenance window and stop new work reaching the application, using whatever method your quiesce procedure names.
Record the installed package version and its checksum. You need this to know which package the data belongs to.
Capture the PostgreSQL database using your own established command from the previous section. Record the recovery point.

With the same quiesce still in force, copy these four trees complete:

C:\ProgramData\BareBonesTicketing\attachments
C:\ProgramData\BareBonesTicketing\keyring
C:\ProgramData\BareBonesTicketing\config
C:\ProgramData\BareBonesTicketing\install

Store the package file and its checksum with the same backup set.
Run your backup system's integrity check over the database artifact and all four trees. Verify the stored package against its checksum separately.
Record capture start and finish times, the recovery point, which components were covered, the integrity result, who ran it, and where it is stored.
Resume traffic only after the integrity result is accepted.

Back up a Linux installation

From the package root, verify the bundle, image, and artifact-manifest.json against their recorded checksums.
Open the maintenance window, stop inbound traffic, and apply your quiesce procedure.
Capture the PostgreSQL database or its volume using your own established command. Record the recovery point.
With the same quiesce in force, copy the attachments volume data and the Data Protection key-ring volume data complete.
Copy the package-root .env with its existing file permissions intact. Never copy its contents into an evidence record.
Copy the versioned bundle: docker-compose.yml, .env.example, configure-database.sh, RUNBOOK.md, artifact-manifest.json, the image artifact, and the legal artifacts.
Run your integrity check over every artifact above.
Record the same evidence fields as step 7 of the Windows procedure.
Resume traffic only after the integrity result is accepted.

Restore on Windows

Restore to an isolated target where you can. Restoring over a live installation needs explicit authority for that environment.

Isolate the target and stop application traffic. Preserve the failed state where it is safe to do so — do not overwrite your only remaining copy.
Confirm the recovery point, the PostgreSQL version, the package identity and checksum, and that all four ProgramData trees are present in the set.
Restore PostgreSQL using your own established restore command.
Restore the complete attachments, keyring, config, and install trees from the same recovery point.
Run the matching package's Install-BareBonesTicketing.cmd as Administrator. Do not copy application files into place by hand, and do not start older binaries against a database that has moved forward.
Read the installer result. A nonzero exit or a missing success route is a failed restore. Do not treat it as partial success.
Keep traffic blocked until the checks below pass.

Restore on Linux

Isolate the target and stop application traffic. Preserve the failed state where it is safe to do so.
Confirm the recovery point, the database mode, and the bundle, manifest, image, and checksums.
Restore the exact bundle and the package-root .env.
Restore PostgreSQL using your own established restore command.
Restore the attachments volume data complete.
Restore the Data Protection key-ring volume data complete.
From the restored package root, run:
```
./configure-database.sh
```
For an installation that uses an external PostgreSQL server, run:
```
./configure-database.sh --database-mode external
```
Supply any setup credential through the script's prompt. Do not put it on the command line.
Wait. The script keeps the restored runtime database identity, applies only pending migrations, reconciles privileges on the target, tests the runtime connection, and starts web only after that test passes.

If it fails, do not start web yourself.
Keep traffic blocked until the checks below pass.

Check the restore worked

Run all four, using synthetic or already-authorized records:

The application starts against the restored database.
An administrator signs in through a known recovery path.
An attachment referenced by a restored ticket retrieves and opens.
A protected setting still decrypts with the restored key ring — or your procedure records that you deliberately re-entered it instead.

Then confirm the running package identity matches the recovery point you intended, and open System Diagnostics to see database, storage, background-job, mail, directory, and licence status with no new unexplained failure.

Restoring an earlier database also restores that earlier point's licence state, Customer Portal single sign-on (SSO) grants, project staffing, and audit rows. Those rows are what the installation recorded then. They are not proof of any external system's current state. Keep customer access contained until the owner of that integration accepts the recovery point.

The append-only audit control stops the running application from rewriting historical audit rows. It does not detect that someone restored an older database. Record the recovery point and any resulting audit gap yourself. See Audit and evidence.

If it does not work

A capture, restore, or startup step fails. Keep the target isolated. Work out what the database, files, keys, configuration, package, and migration state actually are before repeating anything. A failed step is not proof that nothing changed.

You need to go backwards. Restore the complete prior set — database, attachments, keys, configuration, and matching package — together. Replacing application files or images alone does not reverse a schema or data change. Never combine a database from one recovery point with files, keys, or a package from another.

A protected setting will not decrypt after restore. The key ring did not come back with the data. Do not generate a replacement key ring to make the error go away; that discards every value it protected. Follow your key recovery or secret re-entry procedure.

An attachment is missing. The attachment tree or volume was not captured at the same point as the database. Do not change the attachment storage path to point somewhere else — saving a new path does not move files. See Diagnostics and logs for reading storage status.