Sign inTry Free

Important

Self-managed SingleStore will soon transition from version 9.1 RC to version 10. This new semantic versioning scheme will provide SingleStore with finer control over engine and feature releases that were not possible with the current versioning scheme.

In the interim, SingleStore 9.1 RC can be used to preview, evaluate, and provide feedback on the new and upcoming features in SingleStore 10 prior to its general availability. Ahead of this transition, SingleStore 9.0 is recommended for production workloads, which can later be upgraded to SingleStore 10.

Backups versus Snapshots

A backup contains all the rowstore data in-memory (of committed transactions) as well as the columnstore blobs.

A snapshot contains only the rowstore data in-memory (of committed transactions).

Backups are a safety measure for restoring the cluster in case some major cluster-wide issue occurs. For example if you perform some host maintenance and the cluster gets into a failure state, it may be easier to restore from a recent backup rather than trying to fix the cluster. This is why SingleStore recommends to take backups before any kind of maintenance activities. It is also a good idea to take backups regularly so that you always have a recent backup from which you can restore.

The BACKUP command is intended as a way to store a copy of your data that you can use to RESTORE from. However it is an expensive operation, so it should be run during typically low traffic times.

SNAPSHOT truncates the transaction log. SingleStore recommends to run a snapshot after you make large changes to a schema (for example, ALTER TABLE), or before you perform maintenance operations that require restarting the leaf nodes. This is to make the recovery faster as the leaf comes back up and replays the transaction logs. For more details see How Snapshots and Logs are Used.

Another recommendation is to take a backup of the databases involved beforehand, then after any schema and data changes have been performed successfully, take snapshots as well to ensure that the next time you recover a cluster, it does not have to replay all the recent changes.

Snapshots run in a matter of minutes, unlike backups which can take several hours.

Restoring from a snapshot is not supported, it can be done only from a backup.

Last modified:

Was this article helpful?

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.

Sign UpLog In