Owner setup — turning on off-host backups¶

Everything on the engineering side is built, tested and deployed. Two values are missing, and only you can supply them.

Right now every backup of AIM GOLD sits on the same disk as the database it protects. If that server is lost, both go together. These steps fix that.

There are four steps. Do them in order. Take your time — nothing here is urgent-dangerous, and nothing you type is irreversible.

Step 1 — Create the encryption key¶

This key locks the backup before it leaves the server, so that whoever stores your backups cannot read your customers' data.

Run this on any computer (your laptop is fine):

openssl rand -base64 48

It prints one long line of random characters, something like:

K7x2mQ...............................................=

That is your key.

Now save it in two places, immediately:

Your password manager, in a new entry called AIM GOLD backup key (k1).
One more place that is not your laptop and not the server — a printed copy in a safe, or a second password manager.

Cost: free.

Read this before continuing¶

If you lose this key, every off-host backup becomes permanently unreadable. Not "hard to read" — impossible. There is no vendor to call and no recovery procedure. That is the point of the key: it is what makes the backups safe to store somewhere you do not control.

Never put this key in the same place as the backups themselves. If someone obtains both, the encryption has achieved nothing.

Step 2 — Choose where backups will be stored¶

You need somewhere off the server to put them. I have deliberately not chosen this for you: it is a copy of every customer's identity and bank details, and where it lives is your decision, not an engineering one.

Any S3-compatible storage works. Common options:

Option	Roughly what it costs	Notes
Backblaze B2	~US$6 per TB/month; first 10 GB free	Simplest. Your database is currently ~30 KB, so this is free in practice.
Cloudflare R2	10 GB free, then ~US$15 per TB/month	No charge for retrieval.
AWS S3	~US$23 per TB/month	Most complex signup of the three.
A second server you own	—	Also fine; rclone supports SFTP.

Whichever you choose, create:

An account.
A private bucket named aimgold-backups. It must not be public.
An access key and secret for that bucket.

Cost: effectively free at your current data size, on any of the above.

Stop here and tell me which one you picked. I will give you the exact rclone config commands for that provider — they differ per provider and I do not want you guessing at prompts.

Step 3 — I configure rclone on the server¶

Once you tell me the provider, I will give you a short block to paste into the server terminal. It will ask for the access key and secret from Step 2.

Your key and secret go only into the server's rclone config. They are never committed to the repository, never printed in any log, and never shown in any report.

Step 4 — Add the two values to the server¶

I will give you the exact commands. In outline, you will edit /opt/aim/deploy/.env.production and add:

OFFSITE_BACKUP_REMOTE=aimgold-backups:aimgold-backups
BACKUP_ENCRYPTION_KEY=<the key from Step 1>
BACKUP_ENCRYPTION_KEY_ID=k1

Then we run the backup once, by hand, and watch it work.

How you will know it worked¶

Run the production-db-sanity workflow from the GitHub Actions tab. Look for the BACKUP STATUS section. Today it says:

offsite destination configured : NO
RECOVERABLE OFF-HOST: NO — every backup is on the disk it protects.
RESULT: OFFSITE_BACKUP_NOT_READY

After these four steps it will say:

offsite destination configured : yes
last OFFSITE remote verify     : 0h 3m ago
RECOVERABLE OFF-HOST: yes, as of 0h 3m ago
RESULT: OFFSITE_BACKUP_READY

OFFSITE_BACKUP_READY appears only after the system has uploaded a backup, downloaded it again, checked it byte-for-byte, and decrypted it. It will not say READY because an upload command exited quietly.

Your key is never printed by any of this. The checks report only whether a key is present and how long it is.

A second thing worth knowing¶

There is another key, FIELD_ENCRYPTION_KEY, which already exists on the server and protects three columns: customers' PAN, Aadhaar and bank account numbers.

It exists in exactly one place — that server — and it is deliberately not inside the backups, because a key stored inside the thing it locks protects nothing.

If the server is lost and you do not have a copy of that key, those three columns can never be read again, even from a perfect backup. Everything else recovers; those do not.

Copying it out is a separate one-line step and I will walk you through it after Steps 1–4. Mentioning it now so it is not a surprise later.

What I need from you next¶

One thing only: which storage provider from Step 2.

Reply with the name, and I will give you Step 3.