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 it is recommended 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. It is recommended 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 Usage.

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.