SingleStore DB

Incremental Backups on Columnstores

Notice

This section does not apply to SingleStore Managed Service or to backups made using the SingleStore Tools sdb-admin create-backup command.

Also, this section does not apply to unlimited storage database backups.

An incremental backup contains only the changes to columnstore data that were made since the previous backup was taken. Incremental backups on columnstore tables can only be targeted on Azure, Google Cloud Storage, NFS, S3, or S3 compatible storage.

You cannot perform incremental backups to a local file system because on failover or any movement of a master partition the incremental backups remain on the old host. Hence they cannot be used for restore anymore. And since the master partition is moved to a different host, when it tries to write the next incremental data it wouldn't have the baseline of the prior incremental backup to build on.

A backup set contains an initial full backup followed by any number of incremental backups. All of the backups in a backup set are stored in the same directory.

Notice

You can make an incremental backup on a database that has rowstore data, but a full copy of the rowstore data will be saved in the backup.

Making Incremental Backups

Suppose you want to store incremental backups for one week in the same backup set.

First, you make an initial full backup by running the BACKUP DATABASE command and include the WITH INIT clause. This is shown in the following example.

BACKUP DATABASE test_db WITH INIT to "/test_db_backups_week_1";

To make the first incremental backup, run the BACKUP DATABASE command and include the WITH DIFFERENTIAL clause. This is shown in the following example.

BACKUP DATABASE test_db WITH DIFFERENTIAL to "/test_db_backups_week_1";

To make the second incremental backup, run the same command again:

BACKUP DATABASE test_db WITH DIFFERENTIAL to "/test_db_backups_week_1";

To view the history of the incremental backups taken in the cluster, query information_schema.mv_backup_history. The output of the following query assumes that the only backups made are those in this section, Making Incremental Backups.

SELECT backup_id, incr_backup_id, database_name, start_timestamp
    FROM information_schema.mv_backup_history
    ORDER BY backup_id;
****
+-----------+----------------+-----------------+---------------------+
| backup_id | incr_backup_id | database_name   | start_timestamp     |
+-----------+----------------+-----------------+---------------------+
|        10 |             10 | test_db         | 2019-08-04 00:00:00 |
|        11 |             11 | test_db         | 2019-08-05 00:00:00 |
|        12 |             12 | test_db         | 2019-08-06 00:00:00 |
+-----------+----------------+-----------------+---------------------+
Restoring an Incremental Backup

Notice

You can restore an incremental backup into 7.1 from all supported releases 7.0 and later.

You can restore an incremental backup from one taken in 7.1 beta (i.e. 7.1.1), 7.0 RC (i.e. 7.0.7) and 7.0 beta 3 (i.e. 7.0.6).

In SingleStore Managed Service, creating or restoring a backup to/from a local filesystem is not supported.

To restore an incremental backup, run the RESTORE DATABASE command, including the WITH FILE clause. In this clause, specify the incr_backup_id of the incremental backup that you want to restore.

The following command assumes the backups in the previous section, Making Incremental Backups, have been made. The command restores the incremental backup with the incr_backup_id12. Internally, SingleStore DB uses the initial full backup with the incr_backup_id10 and applies the changes with the incr_backup_id11 and 12 to restore the backup.

RESTORE DATABASE test_db FROM "/test_db_backups_week_1" WITH FILE = 12;

You can restore any incremental backup from a backup set. You are not limited to restoring the latest incremental backup, as was shown in the previous example.

Making Frequent Incremental Backups and Occasional Full Backups

When you make an incremental backup, it may no longer contain columnstore data that was in a previous incremental backup. This data in the previous backup is not needed once the current backup is made; the data and will occupy extra disk space.

To save space, you can make incremental backups and occasional full backups. The following example explains a schedule you could use.

Example

  • Make incremental backups on every day of the week except Sunday.

  • On Sunday, take a initial full backup (using BACKUP DATABASE ... WITH INIT). This will create a new backup set.

  • Store the backups for each week in a separate directory.

  • When the full backup made on the Sunday of a new week succeeds, delete the backup directory for the previous week (if desired).

Incremental Backup Performance

Generally, making an incremental backup will be significantly faster than making a full backup. This is because an incremental backup contains only the changes that were made since the previous backup was taken.

If you run OPTIMIZE TABLE prior to making an incremental backup, the backup take significantly longer to complete than it normally would. This is because OPTIMIZE TABLE FULL sorts the entire columnstore table.