What survives a failure

Running memory is not durable

A Host failure stops the Machines on it and loses their running memory. Runin does not provide live migration. Save work to disk and push source code to your repository regularly.

Mirrored local drives protect against a drive failure. They do not replace an off-Host backup and do not protect against loss of the whole Host.

Use the last successful capture

A running Machine's backup is a crash-consistent disk checkpoint. Applications may need their normal crash recovery after restoration. A complete paused backup also contains captured memory and Machine metadata.

The effective Pool recovery interval is normally one hour. An interval is a scheduling target, not proof that an upload succeeded. Inspect the Machine's last successful capture time, replication time and overdue status. A missing observation means backup status is unavailable.

A backup protects data as it existed at its capture time, even if the upload completed later. An unchanged paused Snapshot does not need a fresh upload every hour.

Encryption and storage location

Machine disks and captured memory use ZFS encryption on the Host. Configured backups send raw encrypted payloads over HTTPS to Hetzner Object Storage in Nuremberg, Germany. Decryption requires Runin's separately held encryption key.

The small backup catalog contains identifiers, timestamps and integrity checksums in plaintext. Encryption protects payload confidentiality; checksums and versioned object references verify the chosen restore chain.

Backup retention

Scheduled backups use a 30-day retention window. Runin also keeps the newest recovery point and any older checkpoints required to restore a retained backup. A current paused Snapshot remains protected. Provider locks or a failed deletion can extend physical retention.

Backup cleanup removes recorded object versions. It does not delete your Machine disk or local Snapshots. Retention does not provide a self-service restore command or automatic recovery onto another Host.

Current recovery limits

Automatic recovery onto another physical Host is not yet available. Off-Host backup coverage must be confirmed from a successful Machine observation; an unconfigured or failed backup is not protected by a promised interval.

Recovery starts in an isolated destination. Reusing a Machine identity on another Host requires fencing the old instance and restoring access to the correct encryption key before it can serve traffic. Contact support for recovery rather than starting a second copy with the same identity.

Keep an independent copy of irreplaceable data. Deleting a Machine is not a request to restore it later. Backup retention and restore availability are separate from keeping a local paused Machine.