Security & Data Protection

BackProve backs up your Supabase database and Storage files, and proves those backups can actually be restored. To do that, we need read access to your database and your storage. Here's exactly how we protect what you give us — and, just as importantly, where the limits of that protection honestly lie.

We don't believe in security theater. Below is what's true, not what sounds most reassuring.

All backups are stored on infrastructure located in the European Union. Your backup artifacts never leave EU-based storage, which is kept separate from the servers that run the application itself.

This separation is deliberate: the part of our system that's exposed to the internet (the web application) has no access to the storage where your backups live. Only an isolated internal component can reach backup storage, and it isn't directly reachable from the outside.

Your backups are encrypted from the moment they're created. The encryption happens before a backup ever leaves the environment where it's generated, and it stays encrypted the entire time it's stored. We use modern, industry-standard encryption for this.

In practice this means: even someone with direct access to the underlying storage would see only encrypted data, unreadable without keys they don't have.

Your connection credentials are also encrypted at rest — the connection details you give us to reach your database and storage are stored using authenticated encryption (AES-256-GCM), never in plain text.

You should be skeptical of any backup service that claims it technically cannot ever access your data — because a service that can restore your backups necessarily holds the keys required to do so. Anyone claiming otherwise is either not being straight with you, or isn't actually able to restore your data.

So here's the truthful answer:

• As the operator, we hold the encryption keys the service needs to create and restore your backups. That's unavoidable for a service that does what this one does.
• We do not access your data in the normal course of running the service, and we have no reason or routine tooling to do so. The architecture is built to minimize access at every layer — the internet-facing application can't reach your backups at all; only isolated internal processes can, and only to do their job.
• We minimize what we hold and for how long. Credentials are encrypted; one-time restore credentials are destroyed immediately after use.

If you need a model where the provider mathematically cannot ever access your data, that requires client-side/zero-knowledge encryption where you alone hold the keys — which also means you alone are responsible for those keys, and losing them means losing your backups. That's a different product with different tradeoffs, and we'd rather tell you that clearly than pretend we're something we're not.

This is the core of what we do, and it's a security property in its own right: every backup is automatically restore-tested. We restore it into a disposable, isolated environment and verify the result matches what was backed up. If a backup can't be proven to restore cleanly, we tell you — honestly — instead of showing a reassuring green checkmark over a backup that would fail you when you need it most.

We also alert you when you don't currently have a recently verified, restorable backup — so a silent failure can't leave you unprotected without your knowledge.

A passing restore test is a specific claim, not a general one. Here's exactly what we compare between your source database and the restored copy.

What we check:

• Objects exist: schemas, extensions, tables, sequences, views, materialized views, functions, procedures, and aggregates — matched by name, not just counted.
• Row-level security policies: that each policy is present, and that its USING and WITH CHECK expressions are unchanged. A policy that keeps its name while its condition quietly widens is caught.
• Row-security flags: whether RLS is enabled on a table, and whether FORCE ROW LEVEL SECURITY is set.
• Table-level grants: which roles hold which privileges on which tables.

What we don't check:

• Your rows. We verify that the structure and access rules restore. We do not count or compare the data inside your tables.
• Column-level detail: column types, defaults, generated and identity columns.
• Constraints, indexes, and triggers. A restore missing a unique index or a CHECK constraint would still pass.
• Comments, and grants on columns, sequences, and functions.
• Objects that appear where they shouldn't. We detect things that went missing or changed — not things that were added. A lost grant is caught; an unexpected extra one is not.
• Grants inside Supabase's own schemas (auth, storage, realtime). Those are provisioned by the platform image rather than by you, and comparing them adds noise without signal.

One limit worth stating plainly: comparison can only detect state that changed. It cannot detect state that stayed identical while its meaning shifted. For example: FORCE ROW LEVEL SECURITY being off on both your source and the restored copy is, to us, a match — even though the restored tables are owned by a different role, and that's who "off" now applies to. No amount of additional checks can express that, because it isn't a property either side records. It's a limit of the method, not a gap we're planning to close.

Which restores get verified: every backup is restore-tested automatically, and assisted restore runs the same comparison against your target project afterward — both without you doing anything extra. Self-service restore includes a verification tool you run yourself, against your own target, using the exact same comparison logic — but unlike the other two, it only runs if you run it. That's a real difference between the paths: automatic versus self-directed, not verified versus unverified.

Older backups: verification of policy content and grants requires data we started capturing recently. A backup taken before then still gets its objects checked, and its result is labeled "existence only" rather than presented as a full pass.

When a backup is removed — whether by you, or automatically by retention rules — it's removed completely and consistently: the database record, the encrypted artifact in storage, and the associated file data all go together. We don't leave your data lingering in storage after it's supposed to be gone.

If you believe you've found a security issue, please contact us at security@backprove.com. We take these reports seriously and appreciate them.