Backups
Retention tiers and cross-provider copies.
Backup policies with retention tiers and the option to copy a backup to a second provider — because a backup that lives only where the thing it protects lives is no backup when that place is the outage. Off by default where it doubles cost, on by an explicit choice.
The advantages
The outcomes this product is built around.
Policy, not cron
Retention tiers decide how long each generation is kept, applied by the platform as policy — no scripts a person maintains and nobody forgets.
One outage cannot take both copies
An explicit durability flag copies a backup to a second provider, so the thing you protect and its backup are never lost to the same event.
Cost honesty by default
Cross-provider copies are off by default because they double cost — turning one on is an explicit, audited choice with the price consequence visible.
Restores from a recorded source
Every restore comes from a recorded backup, so recovery is a defined operation — not a search for whatever copy might exist.
How it fits together
What happens between your request and a running resource.
You attach a backup policy to a resource. The platform takes each backup on schedule, keeps generations by retention tier, optionally copies them to a second provider, and every restore names the recorded backup it came from.
- Backup policy: schedule + retention (You)
- Backup runs: on schedule (The platform)
- Recorded backups: restorable points (The platform)
- Same provider: retention tiers (Where copies live)
- Second provider: opt-in copy (Where copies live)
- Backup policy to Backup runs: applied
- Backup runs to Recorded backups
- Backup runs to Same provider: kept
- Backup runs to Second provider: durability flag
Who it is for
The teams and situations this product was built for.
Compliance-driven teams
Retention obligations with evidence the policy was followed.
Retention tiers applied as platform policy, every action on the audit chain.
Disaster recovery planners
A backup that survives the loss of its provider.
Cross-provider copies enabled by one explicit, audited flag.
Operators before a change
A defined way back before upgrades and migrations.
Recorded backups every restore can name as its source.
What it does
The core capabilities, live in the product today.
Backup policies
Retention tiers that decide how long each generation is kept, applied as policy rather than a cron a person maintains.
Set the tiers once — how many generations, kept how long — and the platform applies them. There is no script to rot, no job to silently stop running, and every action lands on the audit chain.
Cross-provider copies
A durability flag that copies a backup to a second provider, off by default because it doubles cost and on by an explicit, audited choice.
A backup that lives only where the thing it protects lives is no backup when that place is the outage. One flag puts a copy at a second provider — visibly priced, explicitly chosen, and recorded.
The ideas behind it
The words this page uses, explained once.
- Retention tier
- How long each generation of backup is kept — daily, weekly, monthly — applied by the platform as policy rather than by a script someone maintains.
- Cross-provider copy
- An explicit choice to keep a copy with a second provider, so one outage cannot take the original and its backup together. Off by default, because it doubles the cost.
- Archive tier
- A colder, cheaper place for backups you must keep but rarely read, with a stated retrieval time.
In depth
The detail an evaluation asks for.
Policy, not scripts
Schedules and retention are properties of the policy, so there is no cron job to forget and no copy kept forever by accident.
Restores you can name
Every restore comes from a recorded backup, so recovery is a defined operation with a defined source — not a search for whatever copy might exist.
Databases and volumes too
Databases keep continuous backups for point-in-time recovery, and volumes take snapshots on a schedule — the same idea, built into each resource.
How it works
- Console
Set a policy
Retention tiers decide how long each generation of backups is kept — policy, not a cron job someone maintains.
- Policy
Let the platform apply it
Generations are kept and expired by the policy itself, with every action on the audit chain.
- Console
Copy to a second home
An explicit durability flag copies a backup to a second provider, so one outage cannot take both.
- API
Restore when it matters
Restores come from a recorded source, so a wrong timestamp costs a throwaway copy, not the original.
In code
The same task in the CLI and both SDKs. Every call shown exists in the API.
prx CLI
Set a backup policy and list the backups it took
prx cloud backup-policy set tracking-db-data --body '{"hour_utc":2,"retention":{"keep_daily":7,"keep_weekly":4,"keep_monthly":12},"cross_provider_copy":true}'prx cloud backup-policy backups tracking-db-dataTypeScript SDK
Set a backup policy and list the backups it took
await client.cloud.backupPolicy.set('tracking-db-data', { hour_utc: 2, retention: { keep_daily: 7, keep_weekly: 4, keep_monthly: 12 }, cross_provider_copy: true });const { backups } = await client.cloud.backupPolicy.backups('tracking-db-data');Python SDK
Set a backup policy and list the backups it took
client.cloud.backup_policy.set("tracking-db-data", {"hour_utc": 2, "retention": {"keep_daily": 7, "keep_weekly": 4, "keep_monthly": 12}, "cross_provider_copy": True})backups = client.cloud.backup_policy.backups("tracking-db-data")["backups"]The difference
The way this job usually goes, and the way it goes here.
The usual way
With ProjectX
A cron job and a script named backup-final-v2.sh.
Retention tiers applied as platform policy — nothing depends on a person remembering.
The backup lives in the same provider as the thing it protects.
One explicit flag copies a backup to a second provider, so one outage cannot take both.
You find out what the backup strategy costs when the invoice arrives.
Cross-provider copies are off by default, and their cost is visible when you choose them.
Works with your tools
Every surface below drives the same product — script it, click it, or hand it to your existing tooling.
- Console
- API
- TypeScript SDK
Questions, answered
How long are backups kept?
As long as your retention tiers say. The policy decides how long each generation is kept, and the platform applies it — nothing depends on a person remembering.
Can a backup survive losing a whole provider?
Yes, if you enable the cross-provider durability flag for that backup. It is off by default because it doubles cost, and turning it on is an explicit, audited choice.
How do I know a restore will work?
Every restore names the recorded backup it comes from, so recovery is a defined operation with a known source rather than a search.
How is it billed?
By the gigabyte stored at the published rate, with the cross-provider copy adding its visible cost when you choose it. The rates are on the pricing page.
Products it works with
Same platform, same console, same invoice.
Start with ProjectX today.
Create a company in minutes and add this product to your invoice at the published rate.