For small Postgres setups. Not for every database stack.
Fits
- You run self-managed Postgres.
- A 1h default backup interval is sufficient for your setup.
- You want a restore baseline you can explain and audit.
Resistro Cloud
Resistro Cloud Backup for self-managed Postgres
Resistro Cloud Backup is built for solo developers and small teams that need a narrow backup baseline for self-managed Postgres, with bounded logical-dump support for self-managed MySQL/MariaDB.
- 1h default backup interval
- AES-GCM encryption
- Customer-held key
- EU-only storage on Hetzner, without the US-provider CLOUD Act path
- Daily restore test as an operating check
- Customer-triggered restore drills
- Compliance PDF export for audit evidence
- Deduplicated agent uploads
- Stale-backup alerting after roughly one day
Requires
- A reachable Linux host where the Resistro Cloud agent can run.
- A customer-held encryption key that you store and protect yourself.
- Operator-assisted restore handling instead of a self-service restore portal.
Not for
- You need hard uptime/support guarantees, service credits, or a fixed restore time.
- You need hosted or managed database support (managed MySQL/MariaDB, RDS, Supabase), or fully automated self-service restore.
Engine boundary
What each engine gets today
Postgres is the product anchor. MySQL/MariaDB are bounded logical-dump paths, not PITR or physical-backup parity.
Engine
Backup today
Restore evidence
PITR today
Not covered
PostgreSQL
Logical backup with a 1h default agent interval for small self-managed setups.
Daily restore-path check and customer-triggered restore drills.
Engineering validation only; not sold as a current recovery promise.
No hard RTO/RPO guarantee; real-size PITR restore is still being hardened.
MySQL/MariaDB
Logical mysqldump backup for small self-managed databases.
Customer-triggered restore drills when an online agent and a successful backup exist.
No.
No PITR, no physical/native backup guarantee, no managed database platforms.
Promise summary
What Resistro explicitly covers today
Postgres backup baseline with a 1h default agent interval
Point-in-time recovery for Postgres is in progress; WAL archiving is proven on staging and deployed to production, but not yet destructively verified against live customer tenant data, and it is not a current product promise
MySQL and MariaDB logical-dump backup for self-managed databases; no PITR or physical backup promise
AES-GCM encryption
Customer-held key
EU-only storage on Hetzner instead of an AWS Frankfurt setup under US-provider jurisdiction
Daily restore test as an operating check
Customer-triggered restore drills with compliance PDF export
Deduplicated agent uploads for repeated backup data
Stale-backup alerting after roughly one day; current monitor threshold: 28h
Daily `/healthz` smoke test for public product paths
Roadmap
Roadmap for regulated setups
These items are intentionally marked as roadmap. They are not part of today's operating promise, but they show which procurement questions Resistro needs to close next.
BYOK / customer-managed key control
Today, backup keys stay on the customer side. The next enterprise step is a clear BYOK flow with auditable rotation, key status, and explicit responsibility when a key is lost.
SOC 2 Type II
SOC 2 Type II is the evidence enterprise and regulated buyers expect for continuously operated controls. Resistro treats SOC 2 Type II as roadmap, not as an existing certification.
FAQ
Hard questions, narrow answers
Who is Resistro Cloud for?
Resistro Cloud is for solo developers and small agencies with self-managed Postgres setups. Typical cases are 1 to 10 databases in environments where a 1h default backup interval is sufficient and there is no dedicated backup team.
What is explicitly covered today?
A Postgres backup baseline with a 1h default agent interval, bounded MySQL and MariaDB logical-dump backup for self-managed databases, AES-GCM encryption, customer-held keys, EU-only storage on Hetzner, a daily restore test, stale-backup alerting after roughly one day with a current 28h monitor threshold, and a daily `/healthz` smoke test.
Does the daily restore test mean my specific database is fully validated every day?
No. The daily restore test is an operating check of the defined restore path. It ensures the restore mechanism does not silently break, but it does not mean every customer database is individually validated every day in a full emergency scenario.
Is point-in-time recovery available?
Not as a current product promise. WAL archiving and basebackup paths are proven on staging and deployed to production, but not yet destructively verified against live customer tenant data; until the restore contract is production-ready, PITR remains roadmap, not a sales promise.
Why is Hetzner EU different from AWS Frankfurt?
The storage location is not the whole jurisdiction question. Resistro stores backups with Hetzner, a German provider in the EU. That avoids the US-provider CLOUD Act path that exists with US cloud providers using an EU region. This is not legal advice, but it is a clearer DACH procurement check than a generic GDPR claim.
What is the target RPO?
Around one hour in normal operation for the default agent setup. It is derived from the configured backup interval and is not a hard guarantee.
How does restore work?
Restore is manual and operator-assisted. There is no self-service button. Customers can trigger restore drills on demand to verify the restore path and download a compliance PDF as audit evidence.
What does the compliance PDF show?
The compliance PDF documents the result of a customer-triggered restore drill: which backup was tested, when, and whether the restore path succeeded. It is evidence packaging for audit purposes, not a legal certification.
Is there a support guarantee or a fixed restore time?
No. There is no support guarantee, uptime guarantee, service-credit model, or fixed RTO commitment.
How does Resistro detect backup failure?
Resistro uses heartbeat- and Prometheus-based monitoring. The current stale-backup alert threshold is 28 hours without a successful backup signal.
What does customer-held key mean in practice?
Backup data is encrypted with AES-GCM and the key stays on the customer side. That is the entire promise, including no key recovery if the customer loses the key.
Which setups are outside the intended scope?
Hosted or managed database platforms such as managed MySQL/MariaDB, RDS, or Supabase, requirements outside the defined small Postgres ICP, and any MySQL/MariaDB requirement beyond bounded logical dumps. Self-managed MySQL and MariaDB databases are supported through mysqldump only.
Does the daily `/healthz` smoke test mean full platform monitoring?
No. It verifies basic reachability of central public product paths, not a full uptime or end-to-end guarantee.
Why is the communication so narrow?
Because Resistro Cloud is sold through bounded promises that are real today, not through broad security rhetoric or implied guarantees.
For small Postgres backups. Not for every stack.
Resistro Cloud Backup fits when you run self-managed Postgres, a 1h default backup interval is sufficient, and you need a restore baseline you can explain. MySQL/MariaDB fits only as bounded logical-dump support. It does not fit when you need hard uptime/support guarantees, hosted or managed database support (managed MySQL, RDS, Supabase), or fully automated self-service restore.