Restore a backup over its app, then restart it

Every chunk's SHA-256 is verified before anything on the server is touched. The data being replaced is then moved aside — not deleted — into data.replaced-<timestamp>, and the restored files land in the same data directory, so a running container's bind mount stays valid. The app is restarted once the files are in place.

The displaced copy keeps using disk until POST /backups/{id}/discard-previous removes it; the job's replaced_path names it.

Naming a destination copies the app instead of restoring it, which is how an app moves between servers. Deploy the same app on the other server first, then pass its id as target_deployment_id. The app the backup came from is not touched at all — it keeps running, so the copy can be tested before anything is switched off.

Two rules the destination has to satisfy, and both answer with the reason rather than a bare refusal: it must be running, and it must be the same app. "Same app" means the catalog name for a catalog app, and the same SOURCE — the same image or the same repository — for a custom deployment, whose name cannot be compared because one customer cannot have two custom deployments sharing a name.

The domain does not travel. The copy keeps its own hostname, and repointing DNS is the customer's move when they are ready. Neither does the .onion: the archive carries the hidden-service key, but it is only put back over the app it came from — two Tor instances publishing one key is the service flapping, not a spare.

Credentials do travel. A copy takes the source's variables, minus the ones that are the destination's own address, and the destination's containers are recreated rather than restarted — otherwise the copied database would refuse the destination's own generated password.