Data and backup

Two roots: the data directory — freely chosen — and the installation directory, to which all other relative paths refer.

The service sets its reference point explicitly to the program directory

As a Windows service the working directory would otherwise be System32, and every relative path would end up there.

What sits where — and what belongs in the backup

Path	Content	Backup
<data directory>\portal.db	accounts, tenants, memberships, invoice data, number ranges, master data, quota counters, activity log	yes
<data directory>\tenants\{id}\invoices\	archived invoice files per tenant	yes
<data directory>\tenants\{id}\templates\	each tenant’s own Word templates	yes
<data directory>\pdf-import-lexicon.custom.json	your own PDF-import field labels, if created	yes
<target directory>\keys\api-keys.json	API keys — hashes only, the plaintext exists nowhere	yes, otherwise all keys have to be reissued
<target directory>\.aspnet\DataProtection-Keys\	the key ring for the sign-in cookie, form protection and the timing trap	yes, otherwise all sessions are dropped
<target directory>\appsettings.Production.json	the configuration	yes
<target directory>\usage\	the usage log, including contents when switched on	optional
<target directory>\logs\	log files, 30 days	no

Two folders in the program directory are worth backing up

keys\ and .aspnet\ do not sit in the data directory. Anyone who backs up only the data directory loses, on restoring, all API keys and all sessions — the data is then there, but nobody can get in and no integration keeps running.

What must survive an update

appsettings.Production.json, the data directory, keys\, .aspnet\, usage\ and logs\.

The Windows installer replaces only the program files and respects this. Anyone building their own deployment route has to reproduce these exceptions.

Stop the service briefly for a consistent backup

The SQLite database runs in WAL mode; a file copy taken during operation can be incomplete.

sc stop Invoiceflair
:: … back up …
sc start Invoiceflair

Restoring

1. Stop the service
2. Copy the backed-up files back
3. Start the service

The database schema is brought up to the installed version’s level automatically on startup.

The application cleans up after itself

Once at startup and every 24 hours thereafter, expired sign-in tokens and unaccepted invitations older than 30 days are removed. A failure in that process does not take the service with it — it is logged and retried on the next pass.