How to create a GlusterFS snapshot

Maintenance on a GlusterFS volume is easier to recover from when a point-in-time snapshot already exists. A snapshot captures the volume state before upgrades, risky configuration changes, or recovery tests, while off-cluster backups still protect against node loss, backend storage failure, and site-level incidents.

The gluster snapshot create command coordinates snapshot creation through glusterd and records the result in cluster metadata. The volume must exist, the volume must be started, and all bricks for that volume must be online before the command can create a complete snapshot.

GlusterFS snapshots depend on thin-provisioned LVM backing for the bricks, so snapshot capacity belongs to the storage layer as well as the GlusterFS configuration. Heavy write activity after creation can consume snapshot space quickly, and a snapshot that exhausts its backend space can stop being useful for restore or clone work.

Steps to create a GlusterFS snapshot:

Open a terminal on a node in the trusted storage pool.
List volumes to confirm the target volume name.
```
$ sudo gluster volume list
volume1
```

Confirm the volume is started.

$ sudo gluster volume info volume1

Volume Name: volume1
Type: Replicate
Volume ID: 53dc227f-05be-407d-a4f3-b27cdf2c8e98
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: gfs1:/bricks/volume1/brick1
Brick2: gfs2:/bricks/volume1/brick1
##### snipped #####

Snapshot creation fails when the target volume is stopped.

Check that every brick for the volume reports Online as Y.

$ sudo gluster volume status volume1
Status of volume: volume1
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick gfs1:/bricks/volume1/brick1            49152     0          Y       2314
Brick gfs2:/bricks/volume1/brick1            49153     0          Y       2197
Self-heal Daemon on gfs1                     N/A       N/A        Y       2055
Self-heal Daemon on gfs2                     N/A       N/A        Y       1988

Resolve offline bricks before creating the snapshot, because the deprecated force path should not be used for normal snapshot creation.

Review snapshot limits and activation behavior for the volume.

$ sudo gluster snapshot config volume1
Snapshot Volume Configuration:
snap-max-hard-limit 256
Effective snap-max-hard-limit 256
Effective snap-max-soft-limit 90%

Snapshot System Configuration:
snap-max-soft-limit 90%
auto-delete disable
activate-on-create disable

snap-max-hard-limit blocks new snapshots once reached. activate-on-create is disabled by default, so activate a snapshot later before mounting or cloning it.

Create the snapshot with a descriptive, unique name.

$ sudo gluster snapshot create snap-volume1-20260616 volume1 no-timestamp description "Before storage maintenance"
snapshot create: success: Snap snap-volume1-20260616 created successfully

Omit no-timestamp when GlusterFS should append a timestamp to the supplied snapshot name automatically.

List snapshots for the volume to confirm it exists.

$ sudo gluster snapshot list volume1
snap-volume1-20260616

Inspect the snapshot details before relying on it for a rollback window.

$ sudo gluster snapshot info snap-volume1-20260616
Snapshot                 : snap-volume1-20260616
Snapshot UUID            : 3c1a9d8a-92b1-46d0-9e2f-2e90103a2e8c
Volume Name              : volume1
Created                  : 2026-06-16 02:15:44
Status                   : Deactivated
Description              : Before storage maintenance
##### snipped #####

Activate the snapshot with gluster snapshot activate snap-volume1-20260616 before clone or read-only access workflows that require an activated snapshot.