Back up, retain, and prove what happened to your data

What is DataFrugal?

DataFrugal sits between your applications and cloud object storage. You send it the data you need to keep — database dumps, VM and system backups, log archives, compliance records, contracts, long-term archives — and it stores that data on secure, DataFrugal-managed storage with retention, access control, and auditing applied for you.

You work with DataFrugal through a web app, a REST API, or the df-agent CLI. All three follow the same rules: the same roles, the same retention, the same audit trail. Your teams never handle raw storage credentials or cloud SDKs.

Why Teams Use DataFrugal

Most teams can already store data. What they struggle with is proving what happened to it — the day a customer, auditor, or incident asks.

Use Cases

Who uses DataFrugal, and for what. Each case links to the part of these docs that covers it.

Set Up Your Organisation

• Sign in. Use email and password (with email verification), or continue with Google or Microsoft.
• Create or join an organisation. If your company already uses DataFrugal, request to join — an administrator approves the request. Otherwise, create a new organisation.
• Choose a plan and region. The plan decides your storage provider (AWS or Wasabi). Pick the region your data should live in, for example Mumbai, Singapore, or Virginia.
• Set up your organisation. Add its name, contact details, and your default retention period. Administrators can also set an IP allowlist here.
• Complete payment. A one-time setup fee activates your organisation's storage.
• Invite your team. Add users and assign roles. For automation, create a Service Identity.
• Start protecting data from the dashboard, the REST API, or df-agent.

Business and individual accounts

Sign up with a work email and you get a business organisation with its own dedicated storage, your choice of region, retention settings, and IP allowlisting. Sign up with a personal email and you get an individual workspace on DataFrugal's shared, Wasabi-hosted storage, with a simpler setup. See the Storage Model for how the two differ.

Copy a download command

The Download URI action copies a ready-to-run curl command to your clipboard, so you can fetch a file straight from a terminal or server. The command carries a short-lived access token and is meant for one-off use — for recurring jobs, use df-agent or the API with a Service Identity.

WORM Storage: Immutable Retention with Object Lock

WORM (Write Once, Read Many) storage lets data be written once and read as often as needed, but not changed or deleted until its retention period ends. DataFrugal enforces WORM with S3 Object Lock on your organisation's storage, so the protection holds at the storage layer as well as in the app.

How to protect a file

In business organisations, users with the WORM role see a retention step when they upload. They choose either:

• Your organisation's default (recommended) — the retention period set by your administrators, or
• A custom date — keep the file until a specific day.

From df-agent, add -crt with a duration such as 30d, 6m, or 7y (see command examples).

What protection means

• The file can't be modified or deleted until its retention date.
• Retention can be extended at any time. It can only be shortened through Break Glass.
• Uploading a file with the same name adds a new protected version. Earlier versions stay locked and unchanged.
• Protection stays in place even if the uploader's role changes later.
• In the dashboard, protected files show a lock icon and their retention date, and Delete is blocked while retention is active.

Where WORM is used

Retention Policies

A retention policy sets how long protected data must be kept. Administrators set your organisation's default retention period during setup; it applies whenever a WORM user uploads with the organisation default, and to clones of protected files.

• While retention is active: the file can be read and downloaded, but not changed or deleted.
• After retention ends: the file is managed like any other file and can be deleted normally.
• Deleted files go to the Restore view first, where they can be recovered before permanent removal.

Protecting Backups from Ransomware

Ransomware increasingly goes after backups first: if attackers can encrypt or delete your backup copies, you have nothing clean to recover from. WORM retention takes that option away.

• Protected backups can't be encrypted, overwritten, or deleted before their retention date — even from a compromised user or administrator account.
• Earlier versions stay locked, so a clean recovery point remains available.
• Removing retention early needs two separate administrators to approve, which limits what one compromised account or insider can do.
• Every attempt to download data is audited, which helps you see what was accessed during an incident.

Approved Early Deletion (Break Glass)

Sometimes a protected file genuinely has to go before its retention date — sensitive data uploaded by mistake, the wrong file protected, or a legal instruction to delete. Break Glass is DataFrugal's controlled exception for these cases: no one can remove retention on their own, and every step is recorded.

How it works

• Request. A user with the WORM role tries to delete a protected file, is told it is under retention, and submits a Break Glass request with a business justification and two System Administrators to approve it. They can't name themselves.
• Review. Both administrators receive the request in their Notifications and review it independently. Each can approve or reject.
• Decision. If either rejects, the request is closed and the file stays protected; a new request is needed to try again. If both approve, retention is removed from that file — across all of its current versions — and nothing else.
• Delete. The file can now be deleted, provided no other retention applies.

Break Glass at a glance

Audit History Retention

You get a minimum of 100 days of live, searchable audit history, which exceeds a typical 90-day requirement. History is kept in calendar quarters, so most events stay searchable for longer than 100 days.

• Older history is archived, not deleted, with a checksum recorded so its integrity can be verified.
• The process fails safe: if archiving fails, DataFrugal keeps the data rather than dropping it.

Evidence for Audits & Security Questionnaires

When a customer questionnaire, security review, or auditor asks for evidence, this is where DataFrugal's answers come from.

Give reviewers the Auditor role so they can gather this evidence themselves, without being able to change anything.

REST API

The DataFrugal REST API covers folders, uploads (including multipart uploads for large files), downloads, versions, labels, and sharing. The interactive API reference lets you explore and try every endpoint.

df-agent (Command-Line Agent)

df-agent is DataFrugal's command-line tool for scripted and scheduled work: upload whole directories, download by ID, share, delete, replace versions, and apply WORM retention on upload. It talks to DataFrugal over HTTPS and never needs storage credentials. It runs on Linux and Windows with Java 8 or later.

Installation

df-agent is built from source with Java 8+ and Maven, together with the df-core-api SDK. Request access below and we'll help you get set up.

Command examples

Every command authenticates with a Service Identity using -sid and -secret.

List dashboard resources

./df-agent -sid <service-id> -secret '<secret>' -fd

Upload a file

./df-agent -sid <service-id> -secret '<secret>' -up -f file.pdf -l <folder-id>

Upload a whole directory

./df-agent -sid <service-id> -secret '<secret>' -up -f ./Documents -l <folder-id>

Create a folder

./df-agent -sid <service-id> -secret '<secret>' -up -folder -f "Images" -l <parent-folder-id>

Upload with WORM retention (WORM role)

-crt takes a duration in days, months, or years, such as 30d, 6m, or 7y.

./df-agent -sid <service-id> -secret '<secret>' -up -f report.pdf -l <folder-id> -crt 7y

Download

./df-agent -sid <service-id> -secret '<secret>' -d -id <resource-id> -f ~/Downloads

Share with a colleague

./df-agent -sid <service-id> -secret '<secret>' -share -id <resource-id> -user colleague@example.com

Delete

./df-agent -sid <service-id> -secret '<secret>' -x -id <resource-id>

Service Identity

A Service Identity is a machine login for agents, cron jobs, background services, and CI/CD pipelines. Each one has a named owner and can be rotated or revoked on its own, without touching anyone's personal account — and its activity is audited like any user's.

Create and manage a Service Identity

• Sign in as a System Administrator.
• Open Settings → Service Identity & API Credentials.
• Choose the person responsible for the identity.
• Enter a name. This becomes the -sid value in df-agent.
• Click Create credentials and copy the secret straight away — it is shown only once. It becomes the -secret value.
• Use Rotate to issue a new secret. The old one stops working immediately, so update your scripts first.
• Revoke identities you no longer need.

Connector Key

Alongside individual Service Identities, each organisation has one shared Connector Key that df-agent and other integrations can use to connect. Use a Service Identity when you want a named owner per integration; use the Connector Key for a single organisation-wide connection.

System Administrators generate and regenerate it under Settings → Connector Key Management.

Automating Backups (Cron, CI/CD, Bacula)

Already use a backup scheduler? Keep it. Call df-agent or the API as the final step of your existing jobs — for example, after a database dump or a Bacula run — and DataFrugal adds retention, access control, and auditing to the copies you already produce. Downstream systems can be given scoped access to read what they need, without broad storage permissions.