Concepts
Scheduling
Configure replication schedules, maintenance windows, and cron-based job timing in Datamotive.
- Product
- Datamotive Platform
- Version
- v1.0
- Documentation status
- Published
- Last updated
- Updated
- Reading time
- 1 min read
Scheduling controls when replication cycles run, when maintenance tasks execute, and how Datamotive handles conflicts between overlapping jobs.
Replication interval
The primary schedule for a protection plan is the replication interval, which sets how often an incremental cycle runs. A shorter interval improves RPO at the cost of more frequent API calls and slightly higher CPU usage on the appliance.
| Interval | Maximum RPO | Typical use case |
|---|---|---|
| 5 minutes | 5 minutes | Tier 1 databases, financial transaction systems |
| 15 minutes | 15 minutes | Business-critical applications, ERP systems |
| 30 minutes | 30 minutes | Standard enterprise workloads |
| 1 hour | 1 hour | Development, test, or low-priority systems |
| 4 hours | 4 hours | Archive workloads or low-churn file servers |
Maintenance windows
Maintenance windows restrict when certain job types run. Use them to prevent resource-intensive tasks (initial seeds, consistency checks) from running during peak business hours.
Configure maintenance windows in Settings then Schedules. Each window specifies:
- Days of the week (for example: Monday through Friday)
- Start and end time in UTC
- Job types allowed within the window (initial seed, consistency check, or both)
Incremental replication cycles are not affected by maintenance windows: they always run on the configured interval to maintain RPO.
Cron expressions
For consistency checks and maintenance tasks, Datamotive supports standard five-field cron expressions:
minute hour day-of-month month day-of-week
0 2 * * 0 → Every Sunday at 02:00 UTC
0 22 * * 1-5 → Monday to Friday at 22:00 UTCCron scheduling is available under Plans then Advanced settings then Consistency check schedule.
Job conflict handling
If a scheduled job would start while the previous cycle is still running, the control plane skips the new instance and logs a Skipped: cycle in progress event. The next scheduled instance runs normally. This prevents overlapping cycles from competing for the same snapshot resources.
For one-off manual triggers (for example, Run now in the console), the job is queued and starts immediately after the in-progress cycle completes.
Related docs
Was this page helpful?
