SchemaPulse
PricingContact

Platform · Backup & Recovery

Backups you have already restored.

A completed backup job is a hypothesis. SchemaPulse runs backup as an operational system with verification, recovery points and restore runs — so the question “can we recover?” has a recorded answer rather than an assumption.

View supported databasesSee supported engines

Lifecycle

Policy to restore, as one system

  1. 01PolicySchedule, retention, encryption, storage target
  2. 02PreflightCapability detection, node selection, lock acquired
  3. 03RunState machine with leases and retry policy
  4. 04VerifyRestore exercised, not just completion recorded
  5. 05Recovery pointCatalogued, with the window it covers
  6. 06RestoreFull or point-in-time, into an isolated target

Step 4 is the one most backup tooling omits. Recording that a job finished is not the same as demonstrating that its output restores, and the gap between those two facts is where recovery plans fail.

Point-in-time recovery

Any second inside the window

orders-galera — recoverable windowexample data
Point-in-time recovery windowFour nightly full backups across seven days, joined by a continuous chain of binary log segments. Any moment inside that chain is a valid restore target; the example target sits between the third and fourth full backup.FULL BACKUPSD1D3D5D7BINLOG SEGMENTSRECOVERABLE TO ANY SECOND IN THIS RANGE — 7 DAYSRESTORE TARGET 02:47:02Z
Fig. 1Full backups anchor the window; tracked binlog segments form the continuous chain between them. A restore target is any moment inside that chain — not just the last full backup.

Coverage

Engines, targets and policy

MySQL
Percona XtraBackup · mariabackup · mysqldump. Point-in-time recovery from tracked binlog segments.
MongoDB
mongodump, with its own policy and run model for replica sets and sharded clusters.
Storage targets
Local · NFS · S3 · GCS
Encryption
Encryption profiles applied per policy, with credentials held separately from the artefacts.
Retention
Retention profiles independent of schedule, so a policy change does not silently shorten your window.

Reliability

What runs underneath

Backup is a distributed scheduling problem before it is a database problem. This is the part database teams read closely, so it is stated plainly rather than summarised as “enterprise-grade”.

Distributed locking
Two schedulers cannot start the same policy twice against the same node.
Job leases
A worker that dies mid-run releases its lease rather than leaving the job wedged.
Run state machine
Every run has an explicit state and a recorded history of its transitions.
Retry policy
Transient failures retry with backoff; permanent ones surface as incidents.
Node selection
Backups are taken from an appropriate cluster member, not whichever answered first.
Preflight catalogue
Capability, capacity and credentials are checked before a run starts.
Tenant guard
Policies and artefacts are scoped to their organisation and project.

Where to look next