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.

1. Open a terminal on a node in the trusted storage pool.
2. List volumes to confirm the target volume name.

   $ sudo gluster volume list
   volume1

3. 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.

4. 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.

5. 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.

6. 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.

7. List snapshots for the volume to confirm it exists.

   $ sudo gluster snapshot list volume1
   snap-volume1-20260616

8. 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.