Prepares the database for a full backup or a filesystem (disk) snapshot.
Snapshot statements are not supported on Windows OS.
Snapshot recovery mechanism requires a snapshot instance ID to be specified
A snapshot instance ID may be an arbitrary string value, such as string representation of a UUID.
Database snapshots may be used in combination with filesystem snapshots or together with file copying (full backup). Collecting a snapshot involves the following steps:
SNAPSHOT PREPAREstatement to acquire reader locks for all database tables, create table metadata file copies in the
snapshotdirectory, and flush the committed data to disk.
- Start a filesystem snapshot or copy the root directory to the backup location on the disk. Refer to the next section to learn how to create a filesystem snapshot on the most common cloud providers.
SNAPSHOT COMPLETEstatement to release the reader locks and delete the metadata file copies.
For some cloud vendors, filesystem snapshot creation operation is asynchronous,
i.e. the point-in-time snapshot is created immediately, as soon as the operation
starts, but the end snapshot artifact may become available later. In such case,
SNAPSHOT COMPLETE statement (step 3) may be run without waiting for the
end artifact, but once the snapshot creation has started.
In case you prefer full backups over filesystem snapshots, you should keep in
mind that the database will retain older partition and column file files on disk
SNAPSHOT COMPLETE. This means that you may run out of disk space if your
disk doesn't have enough free space at the time you call
No DDL statements, such as
CREATE TABLE, should be run in parallel with the
above steps. Otherwise, the snapshot may contain corrupted metadata making it
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 case of a full backup, you should also delete the old root directory and copy the files from your backup to the same location or, alternatively, you can point the database at the new root directory.
To start the database on a filesystem snapshot, you should make sure to configure a different snapshot instance ID.
When the database starts, it checks the current instance ID and the ID stored in
snapshot directory, if present. On IDs mismatch, the database runs a
snapshot recovery procedure restoring the metadata files from the snapshot. When
this happens, you should see something like the following in the server logs:
Snapshot recovery can be disabled using the