Backup Orchestration
Backup Orchestration coordinates consistent MongoDB backups across a replica set: pick a healthy secondary, take an fsyncLock, let a system-level snapshot capture the on-disk state, and release the lock. VisuaLeaf drives the full lifecycle from the UI, tracks progress, and schedules an optional rolling-compact as a post-backup step to reclaim disk space.
A file-level snapshot of MongoDB data files is only useful if the files are consistent. db.fsyncLock() flushes pending writes to disk and blocks further writes until unlocked, giving your snapshot tool a stable on-disk image. Without fsyncLock — or an equivalent WiredTiger checkpoint guarantee — a snapshot can capture a torn state that fails to recover cleanly.
Locking the primary blocks all writes to the replica set until the lock is released. VisuaLeaf defaults to a healthy SECONDARY and will refuse a primary target unless you explicitly override with an incident checkbox. If you must lock the primary — for example, a single-node deployment — schedule it during a maintenance window and expect application-visible write pauses.
For a replica set with multiple secondaries, stagger backups so no two members are locked simultaneously. VisuaLeaf's scheduler enforces this per replica set.
Clicking New backup plan opens a step-by-step dialog:
0 3 * * *).VisuaLeaf scores each candidate secondary and picks the safest by default:
| Signal | Impact on ranking |
|---|---|
| Oplog lag < 5s | Required. Higher-lag members are excluded. |
| Hidden secondary | Preferred — no client traffic to worry about. |
| Priority = 0 | Preferred — ineligible for primary election. |
| Active index build | Excluded. Backup would capture an in-progress index. |
| Already-locked | Excluded to prevent overlapping backups. |
Once a plan starts, the panel streams live state:
fsyncLock call, from which point the snapshot is consistent.fsyncUnlock call.After a successful backup, Rolling compact optionally runs compact on the target secondary to reclaim WiredTiger free-space fragmentation. Because the member is already at a low-traffic state and its snapshot has been captured, this is the safest window to compact. VisuaLeaf can then step-down and roll to the next secondary on subsequent runs so every member gets compacted over time.
Backup Orchestration doesn't ship storage — it wraps the tool you already use. Configured integrations trigger the snapshot between lock and unlock:
Understanding the lock lifecycle is essential for safe operation:
db.fsyncLock() is called. All in-flight writes are flushed; new writes on the target are blocked (secondaries reject writes anyway, but oplog application also pauses).db.fsyncUnlock() on the same session that acquired the lock.A dropped socket in step 2–4 can leave the lock held indefinitely — see the recovery section below.
A stuck fsyncLock shows up as: increasing lag on one secondary, the Backups page marking the plan as Stalled, and db.currentOp() on the target showing a long-lived fsyncLockWorker.
To recover:
fsyncUnlock is a session-scoped counter.db.fsyncUnlock() once per outstanding lock. VisuaLeaf's Force unlock button loops this until the reported lockCount is zero.mongod on the target secondary is safe — it will resync from the primary on startup.ts at lock time to support point-in-time recovery.Download and start managing your MongoDB databases with ease.
Download Free Trial