Real-Time Backup
Stream database changes to your destination in real time using Devpilot's change data capture (CDC) backup mode.
Real-Time Backup
Real-time backup keeps your destination continuously in sync with your source database by streaming every change as it happens. Instead of running a full dump on a schedule, Devpilot captures each insert, update, and delete from the database's own change log and forwards it to your chosen destination. This gives you a much smaller recovery point objective than interval or cron backups and lets you restore to a specific moment in time.
Supported Databases
Real-time backup is a change data capture (CDC) feature, so it is only available for engines that expose a change log Devpilot can read.
| Database | Supported |
|---|---|
| MySQL | Yes |
| PostgreSQL | Yes |
| MongoDB | No |
| Redis | No |
If you select a MongoDB or Redis source, the Real-time schedule option is not offered. Use Interval or Cron scheduling instead.
Key Concepts
CDC Stream
When you set a backup plan to Real-time, Devpilot automatically creates a paired CDC stream. The stream is what continuously watches your source for changes and pushes them to the destination. You manage the plan in the UI; the stream follows it.
Initial Snapshot
The very first time a real-time stream starts, Devpilot takes a baseline snapshot of the source — the full current state — and ships it to the destination. After that snapshot completes, the stream switches to following the live changes from that point forward.
If the stream is stopped and restarted later, it resumes from where it left off — Devpilot does not re-dump the whole database.
Stream Lifecycle
A CDC stream moves through a predictable set of statuses. You can see the current one in the real-time panel for the plan.
Pending
The stream has been created but has not yet begun processing. This is a brief transitional state right after you create a real-time plan or click Start.
Starting
Devpilot is bringing the stream online: connecting to the source, verifying replication permissions, and running the initial snapshot if this is the first start.
Running
The stream is tailing the change log and forwarding events to the destination. This is the healthy steady state.
Stopped
You (or a paused plan) stopped the stream. No events are being captured. You can start it again at any time — it will resume from its last recorded position.
Error (Failed)
The stream hit a problem it could not recover from on its own. Open the stream to read the error message, fix the underlying issue (credentials, permissions, connectivity), and start it again.
What You See in the UI
Each real-time stream shows a small set of live metrics so you can tell at a glance whether it is healthy.
| Field | What it means |
|---|---|
| Status | The current lifecycle state (Pending, Starting, Running, Stopped, Failed). |
| Events captured | Total number of change events the stream has shipped since it started. |
| Lag (ms) | How far behind the source the stream currently is, in milliseconds. A healthy stream holds lag near zero. |
| Last event at | Timestamp of the most recent event the stream processed. |
| Started at / Stopped at | When the stream was last brought up or taken down. |
| Error message | Populated only when the stream is in the Failed state. |
A small Start / Stop control lets you take the stream up or down without touching the plan itself.
Creating a Real-Time Plan
Pick a Supported Source
In Backups > Plans > New Plan, choose a MySQL or PostgreSQL source. Make sure the database user you configured has the replication permissions your engine needs (for example, REPLICATION SLAVE and REPLICATION CLIENT on MySQL).
Choose the Real-Time Schedule
Under Schedule, select Real-time. Devpilot hides interval and cron options once this is chosen — a real-time plan does not need them.
Select a Destination
Pick any active destination. The destination is where the captured events will be archived for restore.
Save the Plan
When you save, Devpilot creates the plan and its paired CDC stream automatically. You do not create the stream separately.
Watch the Stream Come Up
The stream moves through Pending > Starting > Running on its own. The first transition to Running can take longer than later restarts, because Devpilot ships the baseline snapshot before tailing live changes.
How the Plan and Stream Stay in Sync
The plan is the thing you manage; the stream follows it.
| Action on the plan | What happens to the stream |
|---|---|
| Create a real-time plan | A paired CDC stream is created automatically. |
| Pause the plan | The stream is stopped. No new events are captured. |
| Resume the plan | The stream restarts and resumes from its last position. |
| Delete the plan | The stream is deleted with it. |
You never need to create, pause, or delete the stream separately from the plan.
Point-in-Time Restore
A real-time stream records a continuous timeline of every change, which means you can restore your database to any moment the stream was running — not just to the last scheduled backup.
Open the Stream
Go to Backups > Plans, open the real-time plan, and switch to the Stream tab.
Choose "Restore to Point"
Click Restore to Point. A dialog asks where to restore to and, optionally, the exact moment in time.
Fill in the Target
Provide the destination database connection: host, port (optional), username, password, and the target database name. You can restore back to the original server or to a fresh one.
Pick a Moment (Optional)
Leave Restore to empty to replay everything up to now, or set it to a specific timestamp to replay changes only up to that moment. This is the "point" in point-in-time restore.
Run the Restore
Devpilot replays the captured events against the target. Progress appears in the restore history for the plan.
For the general restore flow (from a completed backup file rather than a stream), see Restore.
Limits and Edge Cases
- Only MySQL and PostgreSQL sources can run in real-time mode.
- The baseline snapshot is taken once per stream. If you need a fresh snapshot, delete the plan and create a new real-time plan in its place.
- While a stream is in Starting, metrics like events captured and lag will not yet be populated.
- If the source database changes its replication configuration (for example, binlog format or slot name), the stream may enter Failed and need a manual restart after the source is fixed.
- Real-time plans have their own pricing tier — see Pricing and Billing.
Next Steps
Restore from Backup
Restore a completed Devpilot backup to its original location or a new target, and track restore progress from the backup history panel.
Pricing and Billing
Understand how Devpilot measures backup storage, calculates monthly cost for each plan, and charges the payment method attached to the plan.