Automatic Backups

Backups are one of those features nobody thinks about until the one day they suddenly care very, very much. sp00ky Cloud is built so that day is a quiet one.

Set a schedule, take a manual snapshot before you do something risky, or do both. When you need to go back, one command walks you there. No pager, no support ticket, no late-night rummaging around in a dashboard looking for the option that admits defeat.

The old way, and why it never feels fresh

Self-managed database backups usually mean a cron job, a shell script that was written by someone who has since left the company, a bucket with access rules nobody fully understands, and a quiet prayer that the thing has actually been running. The scariest part is never the backup, it is the restore, because nobody has tested it since the day it was set up.

How sp00ky does it

Everything is a single command. You can run them locally, from a CI job, or wire them into whatever deployment flow you already have.

1. Take a backup right now with spky cloud backup create.
2. Name it if you are about to do something you want to be able to undo: --name before-migration.
3. Schedule recurring backups with a cron expression, like "0 2 * * *" for 2am daily.
4. Set a retention policy so old backups clean themselves up once you have enough newer ones.
5. List them, delete them, or restore any of them with one more command.

The best moment to take a backup is right before you do the thing you are nervous about. sp00ky makes that moment cost one command.

Name the scary ones

Scheduled backups are great. Named backups are better when you are about to do something specific. Before a migration, before a risky data import, before you merge the pull request nobody fully reviewed, run:

• spky cloud backup create --name before-migration

The name shows up in the list next to the backup id, so when you come back looking for "the one from right before we changed the schema," it is there, labeled, ready.

Restores you can actually trust

The part of backups that usually goes sideways is the restore. sp00ky takes this seriously, so the restore path is deliberately boring:

• New writes are paused while the restore runs. You will not race the restore and leave the database in a weird middle state.
• Every layer of the database is reloaded from the same backup file, so nothing ends up out of sync.
• In-flight buffers, pending writes, and live connections are cleared. When traffic resumes, it resumes against the restored state, not a half-version of it.
• Your migrations run again against the restored database, so the schema ends up where your code expects it.
• The CLI shows progress as the restore moves through its phases. You know what is happening, not just that something is happening.

If something goes wrong partway through, sp00ky refuses to serve traffic from a half-restored database. That sounds scary but it is the correct answer: half-restored is how you ship wrong data to production.

Reset, with a safety net

Sometimes you do not want a restore, you want a clean slate. The reset command wipes the database and re-runs your migrations, which is great for dev environments and terrifying for any database that matters. sp00ky handles both cases:

• It warns you, in plain language, that everything is about to go away.
• It offers to take a backup first, and waits for it to finish before continuing.
• If this is truly a throwaway project, --no-backup skips the prompt.

What you don't have to do

• Write a backup script that only one person on the team understands.
• Set up a bucket, rotate credentials, and argue about retention in a spreadsheet.
• Find out in production that nobody has ever tested the restore.
• Remember to back up before a migration. You can, but you also have the schedule already.
• File a ticket and wait. The CLI is the dashboard.