This document provides practical details of using the point-in-time backup functionality in QuestDB along with filesystem backup as means to prevent data loss. Alongside backup details, this document describes how to restore from backups and hints for performing filesystem backups on common cloud providers.
QuestDB provides two strategies for creating backups:
- Point-in-time (PIT) backup
- Filesystem backup
There are some limitations of creating backups that users should note about the types of supported filesystems and what data is included in backups:
- QuestDB officially supports EXT4 or XFS or any filesystem that supports mmap feature.
A backup includes contents of the database up to the point of executing a backup. Any data inserted while a backup is underway is not stored as part of the backup.
Users can't use NFS or a similar distributed filesystem directly with QuestDB, but users may copy a backup to such a filesystem after a backup has been made.
When creating a point-in-time (PIT) backup in QuestDB, you can specify that the
whole database or specific tables should be backed up. This process will create
a backup in a directory specified by the user in the
configuration key. For more details on passing
configuration in this manner, see the
A backup can then be triggered via SQL command and the backup is complete as soon as the SQL query has finished executing:
Note that calling
BACKUP TABLE <table_name> will only copy table data and
metadata to the destination folder. This form of backup will not copy entire
database configuration files required to perform a complete database restore.
Alternatively, the REST API can be used to execute the SQL for a database backup:
To run a reliable filesystem backup without database downtime, you should use
The most common ways to perform cloud-native filesystem snapshots are described in the following resources, which rely on similar steps but have minor differences in terminology and services:
- AWS - creating EBS snapshots
- Azure - creating snapshots of a virtual hard disk
- GCP - working with persistent disk snapshots
In order to restore a backup, the QuestDB executable must be provided with the
directory location of an existing backup as the root directory. This can
done via the
-d flag as
-d /path/to/backup when starting up QuestDB.
Users who are starting QuestDB via
systemd or the official AWS AMI may refer
for reference. To verify that database information has been successfully
imported, check logs via
journalctl -u questdb which will contain a list
Docker instances may have a backup directory mounted to the root directory as follows:
The database backup must contain database metadata files and directories (
config etc.). The contents of these directories is described in more detail in
the root directory documentation.
The following example sets up a cronjob which triggers a daily backup via REST API:
This example shows how to compress a backup using the
tar utility. An archive
questdb_backup.tar.gz will be created in the directory that the command
The backup file can be expanded using the same utility: