How to resume a GlusterFS geo-replication session

A paused GlusterFS geo-replication session leaves the secondary volume at the last synchronized point while primary writes continue. Resume the session after the maintenance or snapshot window ends so gsyncd workers can catch up before the disaster-recovery copy is trusted again.

Geo-replication is controlled from the primary cluster and targets one configured relationship by primary volume plus a user@host::volume secondary target. The resume command returns a Paused session to worker activity without recreating SSH keys, mountbroker settings, checkpoints, or other session configuration.

Catch-up can create disk and network load while pending changes move to the secondary cluster. Confirm the exact secondary target before resuming, use the normal resume path unless both volumes were restored from matching snapshots, and watch status until STATUS, CRAWL STATUS, LAST_SYNCED, and failure counters make sense for the volume layout.

1. Check the selected geo-replication session from a primary cluster node.

   $ sudo gluster volume geo-replication gvol-primary geoaccount@snode1.example.com::gvol-secondary status
   PRIMARY NODE    PRIMARY VOL    PRIMARY BRICK    SECONDARY USER    SECONDARY                          SECONDARY NODE    STATUS    CRAWL STATUS       LAST_SYNCED
   pnode1          gvol-primary   /bricks/b1       geoaccount        snode1.example.com::gvol-secondary  snode1            Paused    N/A                2026-06-16 08:41:05
   pnode2          gvol-primary   /bricks/b2       geoaccount        snode1.example.com::gvol-secondary  snode2            Paused    N/A                2026-06-16 08:41:05

   Use the same user@host::volume target that was used when the session was created.
   Related: How to check GlusterFS geo-replication status

2. Resume the selected session on the primary cluster.

   $ sudo gluster volume geo-replication gvol-primary geoaccount@snode1.example.com::gvol-secondary resume
   Resuming geo-replication session between gvol-primary geoaccount@snode1.example.com::gvol-secondary has been successful

   Resuming replication can send accumulated changes to the secondary volume. Schedule the command for a window where catch-up I/O is acceptable.

3. Use force only for a coordinated snapshot-restore resume path.

   $ sudo gluster volume geo-replication gvol-primary geoaccount@snode1.example.com::gvol-secondary resume force
   Resuming geo-replication session between gvol-primary geoaccount@snode1.example.com::gvol-secondary has been successful

   Run the force form instead of the normal resume command only after restoring matching snapshots on both the primary and secondary volumes.

4. Verify that worker rows return to a running state.

   $ sudo gluster volume geo-replication gvol-primary geoaccount@snode1.example.com::gvol-secondary status
   PRIMARY NODE    PRIMARY VOL    PRIMARY BRICK    SECONDARY USER    SECONDARY                          SECONDARY NODE    STATUS    CRAWL STATUS       LAST_SYNCED
   pnode1          gvol-primary   /bricks/b1       geoaccount        snode1.example.com::gvol-secondary  snode1            Active    Changelog Crawl    2026-06-16 09:05:22
   pnode2          gvol-primary   /bricks/b2       geoaccount        snode1.example.com::gvol-secondary  snode2            Passive   Changelog Crawl    2026-06-16 09:05:22

   Active means the worker is syncing. Passive can be normal for a replica partner that is ready to take over if the active worker fails.

5. Check detailed status while the backlog drains.

   $ sudo gluster volume geo-replication gvol-primary geoaccount@snode1.example.com::gvol-secondary status detail
   PRIMARY NODE    PRIMARY BRICK    STATUS    CRAWL STATUS       LAST_SYNCED          ENTRY    DATA    META    FAILURES    CHECKPOINT COMPLETED
   pnode1          /bricks/b1       Active    Changelog Crawl    2026-06-16 09:05:22  0        0       0       0           N/A
   pnode2          /bricks/b2       Passive   Changelog Crawl    2026-06-16 09:05:22  0        0       0       0           N/A

   FAILURES should stay at 0 after resume. If a row reports Faulty or failures increase, review the geo-replication logs on the affected node.
   Related: How to check GlusterFS geo-replication logs