Skip to main content

๐Ÿš€ Quick Start

Back up your first database to BackupData.io in about five minutes. You will:

  1. Sign in and get your free workspace
  2. Create an API key
  3. Install and authenticate
  4. Create a database dump
  5. Upload it as a snapshot
  6. Verify the snapshot
  7. What's next?

This quick start uses PostgreSQL as the example. Every other database follows the same shape โ€” only step 4 changes.


1. Sign in and get your free workspaceโ€‹

Open app.backupdata.io and sign in with email + password, Google, or a wallet (SIWE). All three produce the same account.

Your free workspace is provisioned automatically โ€” no setup, no payment. Open Workspaces in the sidebar and copy the Workspace ID, a UUID like 550e8400-e29b-41d4-a716-446655440000. You will need it in step 3.

Free tier

Every new account includes a free workspace with 5 GB of storage. Past 5 GB, upgrade before retaining more backup data โ€” see pricing.


2. Create an API keyโ€‹

This is the credential your backups authenticate with.

  1. Sidebar โ†’ API Keys โ†’ Create New API Key.
  2. Key Name โ€” e.g. quickstart.
  3. Workspace โ€” the workspace from step 1.
  4. Scopes โ€” tick backup:write, backup:read, and snapshots:read. That is everything this quick start needs.
  5. Click Create API Key.
The key is shown once

Copy the raw lh_โ€ฆ key (or click Download .txt) before closing the dialog. Afterwards only its prefix is visible, and a lost key must be revoked and replaced โ€” keys are immutable and cannot be re-scoped.


3. Install and authenticateโ€‹

npm install -g @lighthouse-web3/baas-js-sdk

Log in with the key from step 2 and select your workspace:

baas auth login --api-key      # paste the lh_โ€ฆ key when prompted
baas workspace use <workspaceId>
baas auth whoami # confirms identity and active workspace

For cron or CI, skip the interactive login and set the environment directly:

export BAAS_API_KEY="lh_xxxxxxxxxxxxxxxxxxxxxxxx"
export BAAS_WORKSPACE_ID="550e8400-e29b-41d4-a716-446655440000"
Two different hosts

The portal you clicked around in is app.backupdata.io. The API is api.backupdata.io โ€” that is the value the Go SDK needs for APIURL. The CLI and JS SDK target it internally.


4. Create a database dumpโ€‹

Write the dump into a dedicated directory. BackupData.io uploads the directory, so this is what becomes your snapshot:

mkdir -p ./db-dumps

export PGPASSWORD='your_password'
pg_dump \
--host=127.0.0.1 \
--port=5432 \
--username=postgres \
--format=custom \
--file=./db-dumps/app.dump \
app_db
Use one stable filename

Overwrite the same file on every run rather than adding a timestamp. Backups are content-addressed and incremental, so a stable path means each run uploads only what actually changed โ€” while still producing a fresh, complete restore point.

Backing up something else? The command is the only difference: MySQL, SQLite, MongoDB, DynamoDB, Amazon S3, or the quick reference.


5. Upload it as a snapshotโ€‹

baas backup ./db-dumps --description "first backup" --tag env=dev

The upload runs the full pipeline in one call โ€” scan, chunk, deduplicate, compress, upload, then create the snapshot. It prints a snapshot ID; that is your restore point.


6. Verify the snapshotโ€‹

baas snapshot list --limit 5

You can also see it in the portal: Backup Sources โ†’ your source โ†’ the new snapshot is at the top, with its size, chunk count, and paths.

A backup you have never restored is not a backup

Prove it round-trips before you rely on it. Restore into a scratch directory โ€” never over live data โ€” and check the contents:

baas restore <snapshotId> ./restore-check
find ./restore-check -type f -print

Then load ./restore-check/db-dumps/app.dump into a throwaway database with pg_restore. Full walkthrough: recovery drill.


7. What's next?โ€‹