Back up files to your own server over SSH with the Relayium CLI

Last updated: 2026-08-05

If you already have SSH access to a box — a VPS, a home server, a NAS, a workstation — you can back files up to it with the Relayium CLI without setting up a sync service or an account. The transfer runs over your existing SSH connection, so the bytes go straight to your server and never pass through Relayium.

This guide covers pushing and pulling directories, what resume and integrity checking give you, and how to run it on a schedule with cron.

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 -o relayium ./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

What you need

SSH access you already use. ssh user@your-server true must return silently — push reuses that exact connection and configures nothing of its own.
A writable destination on the server. The parent of the destination path has to exist and be writable by that SSH user.
Optionally relayium on the server, which is what buys resume and per-file SHA-256. Without it push still works, over a plain tar stream.
No Relayium account and no daemon on either end. Nothing here talks to Relayium's servers.

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:

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
```
Find out which protocol you will get. A path means the native protocol — resume and per-file SHA-256; no output means the tar-stream fallback.
```
ssh user@your-server command -v relayium
```
Push the directory. The destination is scp-style, and the trailing slash means "into this directory".
```
relayium push ./photos user@your-server:backups/
```
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/
```
Confirm what landed. push ./photos reproduces photos/ under the destination, so the folder name travels with it.
```
ssh user@your-server ls backups/photos
```

What a successful run looks like

On the native protocol, push prints one line per completed file and exits 0. Against a bare server it prints a single summary line instead — that is the tar fallback, and it is also success.

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: per-file resume and a SHA-256 check on every file.
If not, it falls back to piping a tar stream into the remote, so a bare server with no relayium still works.

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.

Resume and integrity come built in

Backups tend to be large and networks tend to drop. When relayium is on both ends, an interrupted transfer resumes from where it stopped on the next run instead of re-sending everything, and each file is verified end to end with a SHA-256 hash — what lands on the server is byte-for-byte what you sent.

If you ever want a clean, full re-send instead of resuming a partial file, pass --no-resume.

Resume needs relayium on the remote (the native protocol); the tar fallback always sends in full.
The SHA-256 check runs automatically; a mismatch is reported and that file is flagged as failed.

Run it on a schedule with cron

Because push is a single non-interactive command that uses your SSH keys, it drops straight into cron for a recurring backup. 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 push -i ~/.ssh/backup_key ~/documents user@your-server:backups/ >> ~/relayium-backup.log 2>&1

Combined with resume, a nightly job that gets interrupted simply continues the next night.
The command exits non-zero if any file fails its integrity check, so cron's mail-on-failure catches problems.

When a backup doesn't land

A scheduled backup fails quietly by nature — nobody is watching the terminal. These four cover almost all of it, and each is decided by a command you can run right now.

Symptom, check, fix

The cron job hangs, or the log ends at a password prompt.

ssh -i ~/.ssh/backup_key -o BatchMode=yes user@your-server true
# Permission denied (publickey).

BatchMode=yes refuses to prompt, which turns a silent hang into this line. Add that key's public half to the server's ~/.ssh/authorized_keys, or point the job at a key an agent already holds.

The crontab line runs but the log stays empty.

command -v relayium
# /usr/local/bin/relayium

cron runs with a minimal PATH that usually has no /usr/local/bin, so the line fails before relayium starts. Write the absolute path the check just printed into the crontab entry, and keep the >> ~/relayium-backup.log 2>&1 redirect so the next failure is visible.

An interrupted transfer starts over from zero on the next run.

ssh user@your-server command -v relayium
# (prints nothing)

Resume is a native-protocol feature, and no relayium on the remote means the tar-stream fallback, which always sends each file in full. Install it on the server to get per-file resume — and check you are not passing --no-resume, which disables it on purpose.

"N file(s) failed integrity check" and a non-zero exit.

relayium push ./photos user@your-server:backups/
# 1 file(s) failed integrity check: [photos/IMG_0413.jpg]
echo $?
# 1

The SHA-256 computed on arrival did not match the one sent, so that file is not trustworthy on the server. Re-run the push and check the exit code again; if the same file keeps failing, push that one file on its own to separate a bad source from a bad link.

Frequently asked questions

Do the files go through Relayium's servers?

No. push and pull run entirely over your own SSH connection. Relayium's servers are never involved and you need no account.

Does the server need relayium installed?

It depends on the direction. For push, it's optional: with relayium on the remote you get the native protocol — resumable transfers and per-file SHA-256 checks — and without it, push falls back to a plain tar stream over SSH, which still works but always sends each file in full. For pull, it's required: pull always needs relayium on the remote (it has no tar fallback), so install it there first.

How does it choose which SSH key and port to use?

It reads your ~/.ssh/config like ssh does, so host aliases, keys and ports are picked up automatically. You can also override them per command with -i for the identity file and -p for the port.

Is this faster than rsync?

For pushing to your own server it's in the same ballpark as rsync over SSH; the point isn't to beat rsync but to give you one tool that also does cross-network and server-to-server transfers with the same resume and integrity guarantees.

Back up your next directory the direct way — over your own SSH, resumable, integrity-checked, and free.

Get the CLI