Skip to content

BACKUPS AND RECOVERY

What happens to your data

What we back up, the restores we have tested, and where our current setup has limits.

Last updated .

What we back up, and how often

Each workspace gets a daily backup of its BookStack database and files, including pages, attachments and images. Backups are encrypted with age and authenticated with an HMAC signature. We remove local backups older than seven days at the next daily retention run; with scheduled runs, this can add up to 24 hours. A first backup is triggered directly after a workspace is provisioned.

A restore returns the workspace to the state of its last nightly backup. Work saved after that run is not in the backup, so a recovery can cost up to a day of changes. If you are about to make a large change and want a fresh restore point beforehand, ask us and we will take one.

Since 10 September 2026, the nightly backup runs while the service stays running. We check database and file consistency around the backup. If consistency cannot be confirmed after three attempts, the process automatically falls back to the previous method, which briefly stops the service. The earlier nightly method caused around ten seconds of interruption per workspace each day.

How we check a restore

We restore encrypted backups into isolated test instances on a private network. The HMAC is checked before decryption. We compare the restored data and files with the original and check the restored instance over HTTP.

— demo restore: The restored database matched the original counts for 11 pages, three books and 17 page revisions. Roles, permissions, settings, and the hash of page titles and update times matched. This demo had no uploaded attachments or images. HTTP retrieval was not verified in this first test.

— attachment and image restore: A separate temporary workspace supplied real test uploads. The restored attachment and image files matched byte-for-byte using SHA-256 comparisons; the upload manifest matched all 21 files, including generated image variants. Attachment and image database rows also matched. The restored login page, content page and image each returned HTTP 200; the page title and content, and the image content type, were checked.

— checks on a schedule: Until this date a restore check ran when we started one. It is now scheduled nightly and picks the workspace whose last check is the oldest, so every workspace comes round in turn. That is a rotation, not a check of every backup of every workspace every night, and it does not change the limits above. The first two runs of that rotation, started by hand to verify it, restored a demo workspace of 16 pages in four books and a test workspace, each serving its login page and a content page over HTTP; the live instances kept running and the temporary resources were removed.

The live demo’s before-and-after fingerprints were identical in both tests. The isolated test resources were removed afterwards.

When something goes wrong

Monitoring runs every ten minutes. When a backup has stopped the service, we restart the workspace and check that it is running and ready to serve requests before reporting the backup as successful. A failed recovery is reported as an error.

For support or help restoring a backup, email info@productivity-boost.com.

What we do not promise today

Backups currently live on the same server as the workspaces. A copy at a second location is in preparation and is not yet in operation.

We do not offer a contractual availability commitment.

“Ask your wiki” is available in beta to workspace owners and admins. It searches your own pages and shows the passages it found. Its AI answers are live: asking a question sends the question and those passages to the same external model as intake — with no upload involved — under the same documented conditions (processing in Dublin and Helsinki, zero retained prompts and completions under the vendor DPA), and you stay the controller for what your workspace holds.

Document intake is available in beta. Each upload sends extracted text, not the original file, to TensorX (Ireland) for AI drafting. Source text is removed on publication or rejection; intake records and drafts are deleted after 30 days from creation in the next hourly cleanup. TensorX’s documented GPU infrastructure is in Dublin and Helsinki, and its vendor DPA provides zero retention of prompts and completions in ephemeral processing. The vendor’s processing conditions are documented in our privacy policy and DPA, and you stay the controller for what your workspace holds. See our Privacy Policy for the processing conditions.