mariabackup vs rsync SST: Choosing a State-Transfer Method

This comparison extends mariabackup Streaming SST & Backups and answers one precise question: when a MariaDB Galera node needs a full State Snapshot Transfer, should the donor serve it with mariabackup or with rsync? The two methods differ in the property that matters most in a live multi-master cluster — whether the donor keeps serving traffic while it copies — and in speed, in-transit encryption, and tooling footprint. Picking wrong means either a production write stall every time a node rejoins, or an unnecessary dependency on an air-gapped LAN you no longer have. This page lays out the trade-offs, the exact configuration for each, and the decision rule that ties the choice to your donor-availability and encryption requirements.

Context: Why the SST Method Is a Production Decision #

Every node that joins with no usable state pulls a full copy of the dataset from a donor, and the donor is a live cluster member. The method Galera uses for that copy decides whether the donor merely gets busier or actually stops accepting writes. On a small lab cluster the difference is invisible; on a production node holding hundreds of gigabytes, an SST that locks the donor for the duration is a multi-minute write outage on whichever member the provider happens to pick as donor. Because a rejoin can be triggered by any node restart, an unplanned crash, or a gcache gap too large for an Incremental State Transfer, the SST method is effectively a standing decision about how much a routine rejoin is allowed to hurt.

The two methods embody opposite philosophies. rsync is a file-level copy: the donor takes a global read lock so the on-disk files are consistent, then rsync ships them byte for byte. It is simple, has no database-level dependencies, and is fast on a quiet LAN — but the read lock means the donor cannot commit for the whole transfer. mariabackup is a hot physical backup: it copies InnoDB pages while the donor keeps writing, records the concurrent changes in the redo log, and reconciles them at prepare time, so the donor stays writable. That single distinction drives almost the entire decision.

Solution: The Decision Rule and How to Configure Each #

The rule is short. Use mariabackup for any production cluster where a donor is also serving application traffic — which is almost all of them. Reach for rsync only in narrow cases: a fully isolated maintenance window where no node is taking writes, an environment where installing mariadb-backup is genuinely impossible, or a tiny dataset on a fast LAN where the lock duration is negligible and simplicity wins.

Configure mariabackup (the production default):

[mysqld]
wsrep_sst_method = mariabackup
wsrep_sst_auth   = sstuser:REPLACE_WITH_VAULT_SECRET

[sst]
streamfmt   = xbstream
transferfmt = socat
parallel    = 4
encrypt     = 4
tca         = /etc/mysql/ssl/ca.pem
tcert       = /etc/mysql/ssl/server-cert.pem
tkey        = /etc/mysql/ssl/server-key.pem

The encrypt=4 block wraps the socat stream in TLS using the named certificates, so the full-dataset copy never crosses the network in clear text — the detail that makes mariabackup viable across security zones where rsync is not.

Configure rsync (only for the narrow cases):

[mysqld]
wsrep_sst_method = rsync
# no wsrep_sst_auth is needed: rsync is a file copy, not a DB login

rsync needs no SST database account precisely because it never logs into MariaDB — it copies files. That is its one genuine advantage and the reason it survives as a fallback: there are no privileges to grant and no mariabackup binary to keep version-matched, which the least-privilege model in Securing mariabackup SST Credentials & Privileges shows is non-trivial to get right.

When the deciding factor is transfer time on a very large dataset rather than donor availability, the parallel-compression tuning and method benchmarks in Choosing the Right SST Method for Large Datasets refine this rule further.

What actually drives the speed difference #

The intuition that rsync is “lighter” and therefore faster is misleading, because the two methods are bottlenecked by different resources. rsync reads the on-disk files sequentially and pushes them through a single stream, so its throughput is capped by one CPU core and the raw file size — including any bloat and fragmentation in the tablespaces. mariabackup reads InnoDB pages, can copy multiple tablespaces concurrently with parallel, and pipes through a multi-threaded compressor, so on a dataset with many tables and idle cores it moves data faster in wall-clock terms even though it does more work per byte. The redo-log reconciliation mariabackup performs at prepare time is paid on the joiner, off the donor’s critical path, so it does not extend the donor’s busy window.

Where rsync genuinely wins is the degenerate case: a single small dataset, a quiet cluster with a maintenance window so no writes are lost to the lock, and a fast LAN where neither compression nor parallelism helps. There, rsync’s zero database overhead and absence of a prepare step make it marginally quicker end to end, and its format-agnostic copy sidesteps the version-matching that mariabackup demands. That combination is rare in production, which is why mariabackup is the default recommendation and rsync is the documented exception rather than a coin-flip.

Parameter & Flag Reference #

Verification #

After switching methods, force a controlled rejoin and confirm the donor stayed healthy. On the donor, watch that it never leaves a servable state during a mariabackup SST:

# On the donor during an SST — mariabackup should never report a write stall
watch -n1 "mysql -N -B -e \"SHOW GLOBAL STATUS WHERE Variable_name IN \
  ('wsrep_local_state_comment','wsrep_flow_control_paused')\""
# Expect: Donor/Desynced (not blocked), flow_control_paused near 0

Confirm the joiner certified into the group rather than starting standalone:

SHOW GLOBAL STATUS WHERE Variable_name IN
  ('wsrep_local_state_comment','wsrep_cluster_status','wsrep_cluster_size');
-- expect Synced, Primary, and the full node count

For an encrypted mariabackup transfer, verify TLS is actually in force by checking the donor log records socat with an OPENSSL address rather than a plain TCP one during the transfer.

Edge Cases & Gotchas #

• rsync’s read lock is invisible until a node rejoins. A Galera cluster configured with wsrep_sst_method=rsync runs fine for months, then the first unplanned rejoin freezes the donor’s writes for the whole copy — surfacing as an application-wide write stall with no obvious cause. If you inherit a Galera cluster, check the method before you need an SST, not during one.
• Mixed methods across nodes are legal but dangerous. Galera lets each node set its own wsrep_sst_method, and the donor’s method governs a given transfer. A stray rsync on one node means an unpredictable subset of rejoins block. Render the method from one source of truth so every node agrees, per the precedence discipline in the wsrep.cnf Configuration Deep Dive.
• mariabackup version skew fails the transfer, rsync does not. Because mariabackup reads InnoDB’s physical format, a donor and joiner running different mariabackup versions can fail a transfer that rsync’s format-agnostic file copy would have completed. Keep mariadb-backup version-matched to the server across the fleet, especially during a rolling upgrade.

Related #

• mariabackup Streaming SST & Backups — the parent guide to the non-blocking streaming transfer in full
• Securing mariabackup SST Credentials & Privileges — the SST account and TLS setup that mariabackup requires and rsync does not
• Choosing the Right SST Method for Large Datasets — method selection when transfer time is dominated by data size
• gcache Sizing for IST & Fast Recovery — avoiding a full SST entirely by keeping rejoins incremental