Features — clouderra

Schedules and windows

A job is described by its start time and a maximum duration. If a copy doesn't fit the window, it isn't aborted — it's flagged as having overrun the window. You see this in the weekly report and can either widen the window or split the job.

Minimum interval — 15 minutes for WAL, 1 hour for file copies.
The time zone is set per account; daylight-saving transitions don't shift the windows.
A missed run (the server was unreachable) is caught up once, not accumulated.

Incrementals and deduplication

After the first full copy, only changed blocks are transferred. Deduplication works within a single account: identical blocks across ten similar servers are stored once and counted once toward volume.

A full copy is reassembled on our side from the incremental chain every 30 days so the chain doesn't grow without bound. This is invisible to you and doesn't consume your bandwidth.

Restore verification

This is the one feature that makes us worth choosing over a home-grown rsync script. Once a week we restore a randomly selected copy in an isolated environment and reconcile the result against the source.

File copies: checksums over a random 2% sample of files plus every file changed during the period.
PostgreSQL: cluster startup, amcheck over indexes, row-count reconciliation for named tables.
MySQL: startup and CHECK TABLE over all InnoDB tables.
The verification result is kept for 12 months and available as an export.

A mismatch during verification opens an incident with higher priority than a failed copy. A copy that didn't run is a known problem. A copy that ran and won't restore is an unknown one — and that's more dangerous.

Retention

Tier	Default depth	Configurable
Hourly points	48 hours	up to 7 days
Daily points	30 days	up to 90 days
Weekly points	12 weeks	up to 52 weeks
Monthly points	12 months	up to 84 months

Deleting a point is irreversible and runs on the retention schedule, not on a button press: 72 hours pass between removal from the interface and physical deletion.

Encryption

The key is generated by the agent on first run and printed once. We never receive it and cannot recover it: losing the key means losing access to your copies — not a clause in a contract, but a direct consequence of the scheme.

Metadata — job names, schedules, sizes and run times — is not encrypted, or we couldn't plan load. The contents of files and dumps are always encrypted.

Access and roles

Owner: billing, account deletion, role management.
Engineer: jobs, restores, viewing reports.
Observer: reports and status only, no right to start a restore.
Two-factor authentication is mandatory for the owner, optional for the rest.

Technical detail on each point is in the documentation. Cost and per-plan limits are on the pricing page.