How to check GlusterFS geo-replication status

A GlusterFS geo-replication status check shows whether each primary brick worker is still moving changes to the secondary volume. A session can exist but still leave recovery data behind when one worker is Faulty, stuck in a crawl, or no longer advancing its last synced time.

Geo-replication runs from a primary volume to a secondary target in the form user@host::volume. The gluster volume geo-replication status command runs from a primary trusted-pool node and reports one row per relevant worker, including the primary brick, secondary target, worker state, crawl mode, and last synced timestamp.

Read the table per row instead of treating the session as one binary state. Active and Passive can both be normal in replicated layouts, while Faulty needs log review. Detailed status adds pending ENTRY, DATA, and META counters plus FAILURES and checkpoint fields when a checkpoint is configured.

1. List all geo-replication sessions from a primary cluster node.

   $ sudo gluster volume geo-replication status
   PRIMARY NODE  PRIMARY VOL   PRIMARY BRICK  SECONDARY USER  SECONDARY              SECONDARY NODE  STATUS   CRAWL STATUS     LAST_SYNCED
   pnode1        gvol-primary  /bricks/b1     geoaccount      snode1::gvol-secondary  snode1          Active   Changelog Crawl  2026-06-16 10:12:44
   pnode2        gvol-primary  /bricks/b2     geoaccount      snode1::gvol-secondary  snode2          Passive  Changelog Crawl  2026-06-16 10:12:41

   Run the command on a node that belongs to the primary trusted pool. Empty output usually means no geo-replication sessions are configured for that cluster.

2. Check one geo-replication session by primary volume and secondary target.

   $ sudo gluster volume geo-replication gvol-primary \
     geoaccount@snode1::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::gvol-secondary  snode1          Active   Changelog Crawl  2026-06-16 10:12:44
   pnode2        gvol-primary  /bricks/b2     geoaccount      snode1::gvol-secondary  snode2          Passive  Changelog Crawl  2026-06-16 10:12:41

   Use the same user@host::volume target that was used when the session was created.

3. Request detailed status for counters, failures, and checkpoint fields.

   $ sudo gluster volume geo-replication gvol-primary \
     geoaccount@snode1::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 10:12:44  0      0     0     0         N/A
   pnode2        /bricks/b2     Passive  Changelog Crawl  2026-06-16 10:12:41  0      0     0     0         N/A

   ENTRY, DATA, and META are pending file, data, and metadata operations. FAILURES should stay at 0 during ordinary replication.

4. Review the STATUS field for every row.

   Active means the gsyncd worker is syncing data. Passive can be normal for the replica partner of an active worker. Created means the session exists but has not started, Stopped means it was stopped, and Faulty needs log review.

5. Review the CRAWL STATUS and LAST_SYNCED fields.

   Changelog Crawl indicates incremental changelog processing. History Crawl usually means backlog changelogs are being processed after a worker restart, and Hybrid Crawl means gsyncd is crawling the filesystem to generate sync work.

6. Compare LAST_SYNCED against the recovery point expected for the secondary volume.

   A stale LAST_SYNCED value can leave the secondary volume behind the primary even when at least one row still reports Active.

7. Get the session log path when any row reports Faulty or a nonzero FAILURES count.

   $ sudo gluster volume geo-replication gvol-primary \
     geoaccount@snode1::gvol-secondary config log-file
   /var/log/glusterfs/geo-replication/gvol-primary/gsyncd.log

   Open the log on the node that owns the affected worker.
   Related: How to check GlusterFS geo-replication logs

8. Check checkpoint completion fields when a checkpoint was set for the session.

   CHECKPOINT COMPLETED should read Yes for completed checkpoints. N/A is normal when no checkpoint is configured.
   Related: How to set a GlusterFS geo-replication checkpoint