Keep an off-host copy on your own server over SSH with the Relayium CLI

Before you start

Everything below is the relayium CLI, so install it first if you haven't. On macOS or Linux, one command drops a prebuilt binary on your PATH:

curl -fsSL https://relayium.com/install.sh | sh

• Prefer to pick the file yourself, or on Windows? Grab a binary from the releases page — relayium.com/cli lists every install option (or go build ./cmd/relayium if you have Go).
• relayium --version confirms it's installed. Skip this and the commands below just print 'command not found'.

Push a directory to your server

push takes one or more sources and an scp-style destination. Relayium connects over SSH using your usual keys and config, then streams the files to the destination directory:

1. Confirm the SSH access push will reuse. A silent return means your keys, host alias and port are already right.

   ssh user@your-server true

2. Find out which protocol you will get. A path means the native protocol — an up-front collision check and per-file SHA-256; no output means the tar-stream fallback, which checks nothing per file.

   ssh user@your-server command -v relayium

3. Push the directory. The destination is scp-style, and the trailing slash means "into this directory".

   relayium push ./photos user@your-server:backups/

4. Override the key or the port for this one command if your ssh config doesn't already cover the host.

   relayium push -i ~/.ssh/id_ed25519 -p 2222 ./photos user@your-server:backups/

5. Confirm what landed. push ./photos reproduces photos/ under the destination, so the folder name travels with it.

   ssh user@your-server ls backups/photos

relayium push ./photos user@your-server:backups/
  photos/IMG_0413.jpg (2314518 bytes)
  photos/IMG_0414.jpg (1998233 bytes)

# against a server with no relayium installed, one summary line instead:
sent 2 file(s) (zero-dependency mode)

• It reuses your ~/.ssh/config, so host aliases, keys and ports you already set up just work.
• If relayium is installed on the server, it uses the native protocol: the whole batch is checked for collisions before any bytes are sent, and each file it transfers is verified by SHA-256 and staged before it is installed.
• If not, it falls back to piping a tar stream into the remote's own tar -x -k, so a bare server with no relayium still works — but that path verifies nothing per file and can leave a batch partly applied.

Pull files back

Restoring is the same command in reverse: give a remote source and a local destination directory. This is how you recover a backup, or sync a server's output down to your laptop:

relayium pull user@your-server:backups/ ./restore

• Unlike push, pull always needs relayium already installed on the remote — it has no tar fallback, so install it there first if it's missing.

Integrity is built in — resume is not

With relayium on both ends, each file push transfers is verified end to end with a SHA-256 hash and staged before it is installed, so what lands on the server is byte-for-byte what you sent. That much is real, and it is the reason to install relayium on the destination.

What push does not do is resume. It is not a transaction either: files are installed one at a time as they pass, so a connection lost partway through leaves the files that already landed in place — and because those files now exist, re-running the same push is refused by the collision check rather than continuing. Push the missing paths explicitly, or use relayium sync, which is the mode that skips what already matches and does continue a partial file on a later run.

--no-resume is accepted by push and pull and does nothing there. It is real on a serve listener receiving a sync, which is where a partial file can exist in the first place.

• The SHA-256 check runs automatically; a mismatch is reported and that file is flagged as failed.
• It covers what the run transfers. The tar fallback hashes nothing, and sync's size+mtime skip means an unchanged-looking file is never read and so never hashed.
• Neither push nor pull resumes, in either protocol. Use sync for a directory you expect to be interrupted.

Keep the copy current on a schedule with cron

Schedule sync, not push. push refuses a destination that already exists, so a nightly push into the same directory succeeds once and is refused every night after that. sync is the mode built for a repeated run: it skips files whose size and modification time are unchanged, sends only what changed, and continues a partial file left by an interrupted run.

It is a single non-interactive command that uses your SSH keys, so it drops straight into cron. Point it at a key with no passphrase (or an agent), and log the output so you can see failures:

# back up every night at 2am — add to your crontab (crontab -e)
0 2 * * * relayium sync -i ~/.ssh/backup_key ~/documents user@your-server:backups/ >> ~/relayium-backup.log 2>&1

• A nightly sync that gets interrupted continues the next night: what already matches is skipped, and a partial file is carried on rather than restarted.
• sync has no tar fallback, so relayium must be installed on the server. That is a loud failure rather than a silent downgrade.
• The command exits non-zero if any file fails its integrity check, so cron's mail-on-failure catches problems.
• This keeps the copy current; it keeps no history. Add --delete only if you want a deletion at the source to remove the file on the server too — which is a mirror, and the opposite of what you want if you might delete something by mistake.

When a scheduled copy doesn't land

A scheduled job fails quietly by nature — nobody is watching the terminal. These four are the ones that actually happen, and each is decided by a command you can run right now. They are not the only ways a run can fail: the destination can be out of space, or unwritable by that SSH user.