N Nightship
Guides / Operations
// operations

Back up and restore

The whole server is one data directory. Back that up and you’ve backed up everything; restore it and the server is whole again.

What to back up

The data directory holds users, tokens, channels, groups, invites, the license, the signing key, and — for Cargo channels — the builds themselves. Back it up and you’ve captured the server. For Tide channels, the build chunks live in your object storage bucket, so include that in your backup plan (or rely on the bucket provider’s own durability and versioning).

Built-in: encrypted backups to your own bucket

nightshipd backup pushes the data directory to a bucket you own as an encrypted snapshot. Every file is chunked, compressed and sealed on the server before it leaves (XChaCha20-Poly1305); the bucket never sees plaintext, not even the chunk names. Snapshots share unchanged chunks, so a daily backup costs only what changed. Backups are opt-in: nothing is written anywhere until you set them up.

Set up from the client

As an admin, open Admin → Storage and click Set up backups…. You choose between the same bucket Tide already uses (snapshots go under a backups/ prefix, no second credential to manage — the server’s storage key must be allowed to write) and a separate bucket with its own credential. The server generates the encryption key and shows it once.

nightship backup init --shared                     # same bucket, under backups/
nightship backup init --endpoint https://<account>.r2.cloudflarestorage.com \
  --region auto --bucket my-nightship-backups --access-key <KEY> --secret-key <SECRET>
nightship backup forget                            # stop backing up (snapshots stay in the bucket)

Store the printed key in your password manager. Every snapshot is encrypted with it; without it a backup cannot be restored — not by you, not by us. On Nightship Cloud this is the whole setup: we run the daily backup and, should you ever need it, the restore — but only with the key you kept.

Set up on the box (self-hosted)

The same, offline. The key is written outside the data directory and shown a single time:

nightshipd backup init --data-dir /var/lib/nightship \
  --endpoint https://<account>.r2.cloudflarestorage.com --region auto \
  --bucket my-nightship-backups --access-key <KEY> --secret-key <SECRET>

Then, whenever you like (the server can keep running):

nightshipd backup --data-dir /var/lib/nightship
nightshipd backup list --data-dir /var/lib/nightship
nightshipd backup prune --keep 14 --data-dir /var/lib/nightship

In Docker, prefix with docker compose exec nightshipd; the Drydock demo configures this for you against its local Garage.

Restore

On a fresh machine, restore a snapshot into an empty data directory with the key and the bucket details, then start the server on it. Tokens, channels, license and storage credentials return exactly as they were.

nightshipd restore snap-20260904-133448 --data-dir /var/lib/nightship \
  --key /root/nightshipd-backup.key \
  --endpoint https://<account>.r2.cloudflarestorage.com --region auto \
  --bucket my-nightship-backups --access-key <KEY> --secret-key <SECRET>

If the backups live in the shared build bucket, add --prefix backups/ and use the build-storage bucket and its credentials. (On the old machine --from backup.json works too; it carries the prefix.) The restored backup.json still names the key file’s old path — check it before the next backup.

Plain copy (the alternative)

A file copy of the data directory is equally valid:

Keep such copies owner-only — unlike the encrypted snapshots they contain the license, the signing key and the bucket credentials in the clear.

Automate it

The server has a built-in schedule. Set it once and it backs itself up every day at that time (server local) and keeps the newest N snapshots — from the client (Admin → Storage), from the CLI, or on the box:

nightship backup schedule 03:00 --keep 14        # via the API (admin)
nightshipd backup schedule 03:00 --keep 14 --data-dir /var/lib/nightship

Admin → Storage also shows the last result and every snapshot, and has a Back up now button; nightship backup and nightship backups do the same from a terminal. keep applies after every run, manual ones included, so the bucket stays bounded. One bucket per server: pruning goes by snapshot name, so two servers sharing a backup bucket would prune each other’s snapshots.

Prefer your own scheduler? A cron line works too:

0 3 * * * nightshipd backup --data-dir /var/lib/nightship \
  && nightshipd backup prune --keep 14 --data-dir /var/lib/nightship

Where you can, use a separate credential for backups so the key your CI holds for pushing builds can’t touch them (with the same-bucket setup, restrict the CI key from the backups/ prefix if your provider supports prefix policies). Where your provider supports it, add object versioning or a deny-delete policy on the backup bucket: a credential that can write can usually also delete, and that is the one thing encryption doesn’t protect against. See Security and hardening.

← All guides