What this means for your team

Restore points that outlive the 35-day window

Push a dump weekly, monthly or at each quarter end and keep each one for as long as your policy says — three years, seven, longer. Every copy stays exactly as it was written, and earlier versions are never overwritten by a later upload.

Outside the account under attack

Snapshots kept in the same cloud account share its fate: one set of stolen credentials, one closed account, one bad automation script. A copy in DataFrugal is immutable for its retention period, and deleting it early needs approval from two different administrators.

Evidence that the copy is the copy

When someone asks whether last March's backup could have been altered, you have an answer: it was locked when written, and every download since is recorded against the person who requested it.

Predictable cost for cold copies

You pay for the data you keep, not per database or per server. On plans without download fees, pulling a large backup back for a test restore doesn't produce a surprise bill — which is usually why nobody tests restores.

Where the provider limits actually bite

The gap is not that cloud backups are bad. It is that they are short, and they live next door to the thing they protect.

35 days, then manual work

RDS automated backups are capped at 35 days. Keeping a quarter-end copy for seven years means copying snapshots yourself and remembering to keep them — a job that quietly stops when the person who set it up leaves.

Same account, same blast radius

Azure SQL and Cloud SQL can hold backups for years, but they still sit inside the same cloud account and the same permissions. Long retention is not the same as being out of reach.

Provider-shaped copies

A snapshot is only useful inside that provider. A dump you keep yourself can be restored wherever you need it, which is the difference between an inconvenience and an outage.

What DataFrugal does not do

  • It does not do point-in-time recovery. Restoring to 14:07 last Tuesday is your database's job, inside its own backup window.
  • It does not take the backup. You schedule the dump; df-agent or the API uploads it.
  • It does not restore into your database. You download the copy you need and restore it with your own tools.

Think of it as the long tail of your backup strategy. Your provider covers the last few weeks, in detail. DataFrugal holds the copies you must still produce years later, in a place the provider's permissions do not reach.

The restore points are whatever you choose to push: nightly, weekly, month end, or every release.

Frequently Asked Questions

Do we stop using our cloud provider's backups?

No. Keep them for fast, recent recovery — that is what they are good at. DataFrugal holds the long-retention copies your compliance policy needs, where a mistake in the cloud account cannot reach them.

How large can a database dump be?

Up to 5 TB per file, with multipart upload handled for you. Bigger databases are usually split by schema or table by the dump itself.

Can we delete a copy if we keep it by mistake?

Within its retention period, only with a request approved by two different administrators, and the whole exchange is recorded. That is deliberate: it is the same control that stops an attacker deleting it.

How do we test a restore?

Download the copy you want and restore it into a test instance with your usual tooling. On plans without download fees there is no per-restore cost, so testing quarterly does not become a budget conversation.

Start with one month-end dump

Push a single month-end copy and set a retention period on it. Nothing else in your backup setup changes.

Talk to us