Schedule an off-host server copy with a cron job

push vs sync: a dated copy or one mirror kept current

Both push and sync move a directory to another machine, but only one of them is built to run twice into the same place.

push sends a full SSH or daemon-direct copy, and with relayium on the remote it refuses a destination that already exists rather than overwriting or resuming. That makes it the wrong shape for a nightly job pointed at one fixed directory — the first run succeeds and every run after it is refused — and exactly the right shape for a job that writes into a fresh, dated directory each time, which is also the only arrangement here that leaves you an earlier copy to go back to. push is also the one that works against a bare server with no relayium, via a tar fallback that verifies nothing per file.

sync instead keeps one destination directory as an incremental one-way mirror of the source: files whose size and modification time are unchanged are skipped, only what changed is sent, and a partial file left by an interrupted run is continued on the next run. sync always needs relayium's native protocol on both ends — it has no tar fallback. Being a mirror, it is current rather than historical: delete or corrupt a file at the source and the next run propagates that.

• Use push into a dated destination when you want each run to stand on its own and older copies to survive.
• Use sync for a large or frequently-changing directory kept as one current copy, where re-sending everything every night would be wasteful.
• Both verify what they transfer with a per-file SHA-256 on the native protocol. Neither push nor pull resumes; sync is the only one of the three that continues a partial file, and the tar fallback verifies and resumes nothing.

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'.

Two transports: SSH or daemon-direct

Point either command at an SSH destination (scp-style, using your ~/.ssh/config) or, if the other machine is running relayium serve, straight at it over the daemon-direct protocol — no SSH needed.

# SSH destination — uses your existing SSH keys and config
relayium push ./data user@backup-server:/srv/backups/

# daemon-direct — the destination runs "relayium serve", no SSH required
relayium push ./data relayium://backup-server:9031

• Daemon-direct connections are pinned TLS 1.3 with trust-on-first-use, then pinned to that fingerprint on every run after.
• sync accepts the same two destination forms as push.

Schedule it with cron

Both push and sync are single, non-interactive commands, so they drop straight into a crontab. Point them at an SSH key with no passphrase (or an agent), and log the output so failures are visible. Note the destination in the push line: it carries the date, because push refuses a destination that already exists. The % has to be escaped as \% in a crontab, where a bare % means end-of-command:

# a dated full copy every night at 2am — a fresh destination each run, so the
# collision check never refuses it — add to your crontab (crontab -e)
0 2 * * * relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/$(date +\%F)/ >> ~/relayium-backup.log 2>&1

# incremental mirror every 15 minutes instead
*/15 * * * * relayium sync -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-sync.log 2>&1

1. Find out where relayium actually is. cron does not use your shell's PATH, and install.sh falls back to ~/.local/bin when /usr/local/bin is not writable — which is exactly the case cron cannot see.

   command -v relayium

2. Confirm the key works with nobody at the keyboard. BatchMode=yes fails instead of prompting, which is what cron would do.

   ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true

3. Run the whole command by hand once, written exactly as cron will run it, absolute path included.

   /usr/local/bin/relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/

4. Only then add the schedule. Keep the absolute path and the redirect.

   crontab -e

5. After the first scheduled tick, read the log instead of assuming. This is the step people skip, and it is the one that would have told them.

   tail -n 20 ~/relayium-backup.log

$ command -v relayium
/usr/local/bin/relayium
$ ssh -i ~/.ssh/backup_key -o BatchMode=yes user@backup-server true
$ echo $?
0

• The command exits non-zero if any file fails its integrity check, so cron's mail-on-failure catches problems.
• An interrupted sync catches up on the next scheduled run: what already matches is skipped and a partial file is continued. An interrupted push does not resume — but because each night writes into its own dated directory, the next night is a clean full copy rather than a refusal.
• Dated directories accumulate. Prune them on the destination on whatever schedule you can afford, or the disk answers the question for you.

Mirroring deletions and real-time sync

By default sync only ever adds or updates files at the destination. Add --delete to make it a true mirror that also removes files the source no longer has — and who has to agree to that depends on which destination you used. Over relayium:// the receiver is a separate process someone started, so it must have been started as serve --allow-delete; without that the deletions are skipped and reported back to you as denied. Over SSH there is no separate listener to consent: sync starts the receiver itself, through your own SSH session, as you — there is no --allow-delete to set, and passing --delete does delete. The SSH destinations in this guide are that second case.

Two things bound the damage either way. Deletion is confined to the top-level directories the run actually sends, so a sibling directory on the destination is never touched; and sync refuses --delete outright if the source resolves to no files, so a typo in the source path or an unmounted source cannot empty the destination.

If you'd rather not wait for cron's next tick, --watch keeps relayium sync running and re-syncs automatically a moment after any file under the source changes — a lightweight alternative to polling on a schedule.

• relayium sync ./data user@backup-server:/srv/backups/ --delete mirrors deletions, and over SSH it needs nobody's permission but yours. Leave --delete off if a mistaken deletion at the source is a worse outcome than a stale file on the destination.
• relayium sync ./data relayium://backup-server:9031 --delete deletes only if that listener was started with serve --allow-delete; otherwise it is reported back as denied.
• relayium sync ./data user@backup-server:/srv/backups/ --watch stays running and re-syncs on change instead of running once from cron.

When it doesn't work

Every one of these is invisible until you look at the log, which is why the log redirect is in the crontab line rather than being optional. The fifth is worse than invisible: it looks like success.