Backing up the server
OpenBI Server keeps everything of its own in one data folder, and its records in SQLite there unless you moved them to a database server. Back up the folder, and that database, and you can bring the server back as it was.
Where the server keeps its records
The data folder is C:\ProgramData\OpenBI Server on Windows and /Library/Application Support/OpenBI Server on a Mac. It is open to administrators and the services only.
| In the data folder | What it is | Back it up |
|---|---|---|
server.db | The server’s records in SQLite: workspaces and who has access, published versions’ details, schedules, data sources and their sealed credentials, lakes, alerts, Excel passwords’ hashes, AI agents’ settings, who may see formulas, favourites, activities and the audit log (with the DuckDB findings accepted) | Yes |
database.json | Where the records are, when you moved them to SQL Server or PostgreSQL, its connection sealed | Yes |
accounts\ | OpenBI Accounts: its address and name, its people (their passwords’ hashes and authenticators, invitations), its e-mail settings, the AI agents’ apps and connections, and its records’ database | Yes |
content\ | Every published version (.openbimodel) and each refresh’s data, by workspace and item | Yes |
license\ | Each domain’s licence key, sealed, and its signed licence file | Yes |
keys\ | The keys behind people’s sessions in the portal and the report passes, sealed (OpenBI Accounts keeps its own in its records) | Yes |
signin.json, settings.json | Where people sign in (its secret sealed), and the server’s settings, such as engine limits | Yes |
lakes\ | Workspace lakes kept on this server, their catalogs and files | Yes, or with lake backups |
cluster.json, certs | On a cluster’s node: its cluster and the cluster’s key, sealed. On a Mac: the front door’s certificates | Yes, when there |
work\ | The engines’ unpacked versions, made again when needed, and in work\drafts the report pages people are editing in the browser and haven’t saved | Only work\drafts, if unsaved drafts matter |
duckdb\, logs\, backups\ | DuckDB’s extensions (lake setup downloads them again), the logs (kept 30 days), earlier copies of IIS’s web.config | No need |
Outside the data folder:
- The records’ database, when you moved the server’s records or OpenBI Accounts’ to SQL Server or PostgreSQL (
OpenBI.Server.exe database statusandaccounts database statussay where they are): back it up with its own tools, at the same time as the folder. - Shared lakes on your shares or buckets: with lake backups.
- IIS and its certificates on Windows: Let’s Encrypt’s certificates are renewed by themselves; a certificate of your own is backed up as your IT keeps certificates.
- The cluster’s key, if you run a cluster: kept by IT, apart from the servers.
Sealed for this machine
The secrets in the data folder (the licence keys, the sign-in’s secret, the data sources’ and lakes’ credentials, the keys behind sessions) are sealed for this machine: with Windows’ DPAPI machine key, or on a Mac with a key of OpenBI’s that only the service reads, kept outside the data folder (/Library/Application Support/OpenBI/seal.key). So the secrets in a copy of the data folder can’t be unsealed on another machine, and a backup restores the server on the machine it came from. What is published is not encrypted: keep backups as you keep the server itself, since anyone who can read one can read the published models and their data.
Make a backup
Stop both services for a copy that is whole (the server is down while it copies), copy the data folder without what isn’t needed, and start them again. Back up every day, and before every upgrade.
On Windows
cd "C:\Program Files\OpenBI Server"
OpenBI.Server.exe service stop
OpenBI.Server.exe accounts service stop
robocopy "C:\ProgramData\OpenBI Server" "<backup folder>" /E /COPY:DATS /XD "C:\ProgramData\OpenBI Server\work" "C:\ProgramData\OpenBI Server\duckdb" "C:\ProgramData\OpenBI Server\logs"
OpenBI.Server.exe accounts service start
OpenBI.Server.exe service start/COPY:DATS keeps the files’ permissions, so the backup stays closed to everyone but administrators. robocopy’s exit code 0 to 7 means it copied what it should; 8 or more is a failure. If the records are in a database server, back it up now too, while the services are stopped.
On a Mac
sudo openbi-server service stop
sudo openbi-server accounts service stop
sudo rsync -a --exclude /work --exclude /duckdb --exclude /logs "/Library/Application Support/OpenBI Server/" "<backup folder>/"
sudo openbi-server accounts service start
sudo openbi-server service startA cluster
The shared database holds the records, OpenBI Accounts’ records, what is published and the sign-in’s keys: back it up with its own tools, as its high availability asks. Each node’s own is small: its license folder, settings.json and cluster.json, and its front door. A node lost is replaced by a new server that joins the cluster (see Each other node).
Restore
Restore only what is damaged or lost, on the machine the backup came from:
- Stop both services. If OpenBI Server itself is gone, install the version the backup was made with first.
- Put the data folder back from the backup, in place of the damaged one. If the records are in a database server, restore it to the same moment: the records name what is in
content\, so both must come from the same backup. - Start both services, then check:
version,status,doctor, and a report opens with its data.
Frequently asked questions
Can we back up while the server runs?
Copying server.db while the service writes it can give a copy that isn’t whole. Stop the services for the minute the copy takes, or keep the records in a database server, whose own tools back it up while it runs.
Can we restore onto a new machine?
Not as a working server: the secrets in the backup are sealed for the machine it came from. Run a cluster to survive the loss of a machine.