Backups

A backup in strackt is a point-in-time snapshot of an environment that you can restore onto any compatible server in your workspace. You choose where the snapshots go and how often they're taken; strackt handles taking them and putting them back.

Where your backups go

There are two destinations, and you can use either:

• A backup destination on a server you own. You set up a receiver on one of your own servers, and strackt replicates snapshots to it. Everything stays on infrastructure you control.
• Your own object storage. Point strackt at an S3-compatible bucket — Hetzner Object Storage, AWS S3, Backblaze B2, or anything that speaks the same protocol — using your own credentials. Snapshots are encrypted before they leave your server.

You hold the key

When you back up to your own object storage, strackt generates one encryption key for your workspace and shows it to you once to save. From then on, every backup is encrypted with it. strackt stores the key only in its secret vault and never writes it into a backup — which means the backups are yours in the strongest sense: with your key and your storage credentials, you can restore your own data using standard open-source tooling, even if strackt itself were unavailable. The point of customer-owned encryption is that strackt doesn't have to be in the loop for you to get your data back.

Scheduling

Each backup runs on a schedule you pick — anything from every fifteen minutes up to weekly, or a custom schedule if you need something specific — in the timezone you choose. When you set it up, strackt shows you the next several times it will run, so you can confirm the timing before saving.

Restoring

To restore, open an environment's backups, pick a snapshot, and choose the server to restore it onto. strackt stops the running services on the target, puts the snapshot's data back in place, and redeploys the environment so it comes back up on the restored data. A restore is a tracked operation you can watch, the same as a deploy.

Restores can land on a different server than the one the backup came from, as long as it's a connected server in the same workspace — useful when you're recovering onto fresh hardware.

When a scheduled backup fails

If a scheduled backup run doesn't complete, strackt tells you which destination it was writing to and lets the schedule carry on — one missed run doesn't stop future ones. The important thing to know is that a failed run means that point in time wasn't captured, so it's worth clearing the cause rather than waiting.

The two most common reasons a run fails:

• The destination can't be reached. If you back up to a server you own, check that server is online. If you back up to object storage, check the bucket still exists and your credentials are still valid — a rotated access key or a bucket that filled up will stop runs until it's sorted.
• The source server was busy or briefly offline. A transient blip during the run can cause it to fail. These usually clear on their own by the next scheduled run.

What to do: fix whatever the notification points at — most often the destination — then either wait for the next scheduled run or take a manual snapshot to capture the current state right away. If runs keep failing while the destination looks healthy, reach out and we'll take a look with you.

When a restore doesn't complete

A restore is a tracked operation, so if it can't finish you'll see where it stopped, the same as a deploy. A restore that fails part-way doesn't leave you worse off: your other environments and servers are untouched, and you can pick another snapshot or another target and try again.

What to do:

1. Check the target server. A restore needs the server you're restoring onto to be connected, online, and with enough room for the environment's data. A target that's offline or short on disk is the most common cause.
2. Try a different target if you have one. Because a restore can land on any connected server in the workspace, you're not stuck if one server won't take it — pick another and restore there.
3. Try the restore again. Transient issues during the copy often clear on a second attempt from a clean state.

If a restore keeps failing on a healthy server, reach out — recovering your data is exactly the moment we want to help directly.