Backups and updates
What the daily backup contains, how long backup sets are kept, how a restore works and what happens to your data while XICBOT is updated.
In plain language
The database and the files are backed up every day. The latest copies are kept for a while. This page says what a backup contains and what it does not. It explains how a restore works. Some things you can also get back or download yourself. After that, the page is about updates. It says what happens to your data when an update is installed.
All documentation topics
XICBOT backs up its database and file storage once a day and keeps the most recent backup sets. This page covers what a set contains and what it leaves out, how long sets are kept, how a restore works and what you can recover or export yourself without a backup. The second part explains where new releases are announced and what happens to your data and running jobs while an update is rolled out.
The daily backup
The backup runs once a day as part of the application's schedule, by default at 02:47 UTC – at night and deliberately off the full hour. Runs do not overlap. Each successful run reports a heartbeat with a 30-hour deadline: one day plus some slack. If a run fails or does not report in, operations get an alert; Availability and monitoring explains how heartbeats and alerts fit together.
| Part | Contents |
|---|---|
| Database | All application data: schema, rows, routines, triggers and events. It is captured in a single transaction so that the rows are consistent with each other. |
| File storage | The private and the public area of the file storage, including the attachments visitors upload during a conversation. |
| Manifest | Creation time, size and SHA-256 checksum of the two archives for the database and the file storage, the row count per table, the number of files backed up and a list of what is left out on purpose. |
Left out on purpose:
- Program code. It comes from the source tree with every update, and a second copy would be a second version of the truth.
- Credentials. An archive holding them would be a copy of the keys, and archives get copied more often than the application itself.
- Log files, caches and installed dependencies. They are regenerated during operation, and restoring them would at best be misleading.
If capturing the database or the files fails, the run deletes the partial set and exits with an error. Older sets stay as they are, because old sets are only cleared out after a successful run. Data security describes how your data is protected in day-to-day operation.
Retention
By default, 14 sets are kept. The limit counts sets, not days: after each successful run the oldest sets are removed until 14 remain. With one successful run a day, the oldest set therefore goes back about two weeks, and further if runs are missed. A failed run removes nothing. Each set is named after its creation time in UTC, and only folders named that way and carrying a manifest are removed.
Restoring a backup
Restoring from a backup is done by operations; there is no button for it in the app. A set holds the data of all accounts and is loaded as a whole: the database, the file storage or both. You can restore individual versions without a backup and export a copy of your data yourself, as the next section shows.
-
Step 1
Verify the set
Before anything is loaded, the SHA-256 checksum of each archive in the set is recalculated and compared with the manifest. If the manifest or an archive is missing, or a checksum does not match, the set is rejected rather than half-loaded.
-
Step 2
Choose the target
Database and file storage are specified separately. A set can be loaded into a separate database created beforehand, so it can be inspected without touching the live data.
-
Step 3
Clear and load
The target database is emptied first and then filled from the set. Afterwards it holds no tables that were not in the set.
-
Step 4
Unpack the files
The file storage is unpacked into the folder given as the target. Unlike the database, this folder is not emptied first: files that are already there but missing from the set stay in place.
Recovering and exporting on your own
Many mistakes can be undone without a backup: assistants and knowledge sources keep versions, and you can export your data as a file. Roles are ranked, so a higher role can do everything a lower one can. See Team and roles for details.
| Where | What you can do | Role |
|---|---|---|
| Assistants → Versions | Every save publishes a new version and keeps the previous one; conversations already in progress stay on their version. Restore publishes the selected version as a new version that is active right away, and discards nothing. The version that is currently active cannot be restored. More under Assistants. | Edit or higher; Owner only if the selected version has a different Handover address from the active one |
| Knowledge → Versions | Each build writes a new version, and the last five are kept. Restore makes an older version that is still kept answer again and discards the newer ones. This is not possible while an intake or refresh for the source is waiting or running. More under Knowledge. | Edit or higher |
| Conversations | Filtered conversations as CSV downloads an overview with one row per conversation: time, assistant, channel, language, status, number of messages, title and escalation reason. Personal data detected in the title and reason is masked. One export holds at most 5000 conversations; if there are more, narrow the date range. This conversation as CSV downloads the history of a single conversation. Pricing shows whether your plan includes exports. More under Conversations. | any role |
| Legal and data → Data export | Export data downloads your account's stored data, split into sections, as the JSON file xicbot-datenausfuhr.json. If a section fails, the file marks it as failed instead of leaving it out, and the page then lists any tables the export does not cover. Since the export contains conversations in plain text, only the owner may run it. More under Privacy and legal. | Owner only |
Updates
Changelog
Changes to XICBOT are listed on the changelog page of the website, the most recent entry at the top; its header and footer link to it, and the bar above the header names the most recent entry as “New”. The API returns the same dated entries without signing in, in German, for instance to post a notice for your own team: website and API read them from the same file, the website at build time. Each of these entries has a version, a date, a kind and a title, plus individual points. The endpoint, its fields and its error cases are covered under Changelog; Public API endpoints lists the other endpoints that need no sign-in.
While an update is rolled out
- What gets transferred is the program code. Attachments in the file storage and the credentials are outside what is transferred and are not overwritten.
- Database schema changes run as a separate step. Additive changes such as new tables, new columns with an empty default or a relaxed requirement can run ahead of the new code, because the current code keeps working with them.
- The background service is stopped with a signal that lets it finish the job it is working on. When it starts, it releases jobs whose process is no longer running so they can be retried; a job that has used up its attempts is marked as failed. Background jobs explains how jobs are processed.
Frequent questions
When does the daily backup run?
The default is 02:47 UTC, once a day as part of the application's schedule. A run does not start while the previous one is still working.
Can I download a backup myself?
A backup holds the data of all accounts, and the app offers no way to download it. As the owner, you get a copy of your own data via Export data under Legal and data.
How long does deleted data stay in the backups?
Until the sets that still contain it expire. 14 sets are kept by default, which is about two weeks with one successful run a day.
I overwrote an assistant version. How do I get the old one back?
Pick the earlier version under Assistants → Versions and choose Restore. It is published as a new version and becomes active right away; the other versions are kept. If the earlier version has a different Handover address, only the owner can restore it.
Does an update cancel jobs that are running?
Usually not. The background service is stopped with a signal that lets it finish its current job. If a job is left behind anyway, the service releases it for another attempt when it starts again, as long as attempts remain.
Ask it yourself, Assistant of this website
Automated assistant