Last updated: 2026-07-09
Back ups you have to remember to run don't happen. Cron does remember, and the Relayium CLI is built for that: a single non-interactive command that copies (or mirrors) a directory to another machine, verifies every file, and picks up where it left off if the network drops.
This guide covers scheduling relayium push and the incremental relayium sync from cron, the two transports you can point either one at, and the crontab lines to copy.
Both push and sync move a directory to another machine and both are safe to run repeatedly, but they solve slightly different backup problems.
push sends an SSH or daemon-direct copy each time you run it — simple, and it even works against a bare server with no relayium installed via a tar fallback. sync instead keeps the destination as an incremental one-way mirror of the source: only changed files are re-sent, so a nightly sync of a large directory after the first run is fast. sync always needs relayium's native protocol on both ends — it has no tar fallback.
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:9031Both 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:
# full copy every night at 2am — add to your crontab (crontab -e)
0 2 * * * relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/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>&1By 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 — the receiving side must be explicitly listening with serve --allow-delete, or the deletions are silently skipped and reported back as denied. sync also refuses --delete outright if the source directory resolves to no files, so a typo in the source path can't wipe 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.
It depends on the command. push works either way: with relayium installed it uses the native protocol (resume + SHA-256 per file); without it, push falls back to a plain tar stream over SSH, so a bare server still works. sync always needs relayium's native protocol on the remote — there's no tar fallback for sync, so install it there first.
Yes. Every file is checked with a SHA-256 hash end to end, and pushing over SSH or daemon-direct means the bytes are already protected by that connection's encryption — nothing extra to configure.
With relayium on both ends, the next scheduled run resumes partial files instead of resending everything. Pass --no-resume if you ever want a clean full re-send instead.
sync refuses to run with --delete if the source directory contains no files, and the receiver has to be started with serve --allow-delete for deletions to take effect at all — otherwise they're skipped and reported back to you.
No. The CLI is free and needs no account for push, pull, or sync — the transfer runs over your own SSH connection or a direct daemon connection, not through Relayium's servers.
Put your backups on a schedule you don't have to remember — encrypted, resumable, and free.
Get the CLI