用 cron 任务定时做异地服务器副本

push 与 sync：按日期的完整副本，还是一份持续更新的镜像

push 和 sync 都能把一个目录送到另一台机器，但只有其中一个是为往同一个位置反复运行而设计的。

push 每次都通过 SSH 或 daemon 直连发送一份完整拷贝；在远端装有 relayium 时，它会拒绝已存在的目标，而不是覆盖或续传。这让它完全不适合每晚指向同一个固定目录——第一晚成功，之后每晚都被拒——却恰好适合每次写进一个全新的、按日期命名的目录，而那也是这里唯一能给你留下旧副本的做法。push 还是唯一能对付没装 relayium 的裸服务器的命令，靠的是一条逐文件什么都不校验的 tar 兜底路径。

sync 则把一个目标目录维护成源目录的增量单向镜像：大小与修改时间都没变的文件会被跳过，只发送变化的部分，上一次中断留下的半截文件会在下次运行时接着传。sync 始终需要两端都用 relayium 的原生协议——它没有 tar 兜底方案。既然是镜像，它反映的就是当下而不是历史：源端删掉或损坏一个文件，下一次运行就会把这件事同步过去。

• 希望每次运行各自独立、旧副本还能留着，就让 push 写进按日期命名的目标。
• 目录很大或者经常变动，只想保留一份持续更新的副本、每晚重发全部内容太浪费，就用 sync。
• 走原生协议时，两者都会对自己传输的文件做逐文件 SHA-256 校验。push 和 pull 都不续传；三者之中只有 sync 会接着传半截文件，而 tar 兜底路径既不校验也不续传。

开始之前

下面用到的都是 relayium CLI，所以没装的话先装上。在 macOS 或 Linux 上，一条命令就能把预编译二进制放进你的 PATH：

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

• 想自己挑文件，或在 Windows 上？从发布页下载二进制——relayium.com/cli 列出了所有安装方式（装了 Go 也可 go build ./cmd/relayium）。
• relayium --version 可确认是否装好。不装这一步，下面的命令只会报 “command not found”。

两种传输方式：SSH 或daemon 直连

两个命令都可以指向一个 SSH 目标（scp 风格，走你的 ~/.ssh/config）；如果对方机器正跑着 relayium serve，也可以用daemon 直连（daemon-direct）协议直接连过去——不需要 SSH。

# SSH 目标——使用你现有的 SSH 密钥和配置
relayium push ./data user@backup-server:/srv/backups/

# daemon 直连——目标机器运行着 "relayium serve"，无需 SSH
relayium push ./data relayium://backup-server:9031

• daemon 直连走的是带证书证书固定的 TLS 1.3：首次连接时信任（trust-on-first-use），之后每次运行都校验同一个指纹。
• sync 接受和 push 完全相同的两种目标写法。

用 cron 定时运行

push 和 sync 都是单条非交互式命令，可以直接放进 crontab。给它指定一个没有口令的密钥（或者用 agent），并把输出记下来，好让失败能被看见。注意 push 那一行的目标里带了日期：因为 push 会拒绝已存在的目标。在 crontab 里 % 必须写成 \%，裸的 % 表示命令到此为止：

# 每晚 2 点做一次按日期归档的完整复制——每次都是全新的目标，
# 所以冲突检查永远不会拒绝它——添加到你的 crontab（crontab -e）
0 2 * * * relayium push -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/$(date +\%F)/ >> ~/relayium-backup.log 2>&1

# 改为每 15 分钟做一次增量镜像
*/15 * * * * relayium sync -i ~/.ssh/backup_key ~/documents user@backup-server:/srv/backups/ >> ~/relayium-sync.log 2>&1

1. 先查清 relayium 到底在哪。cron 不用你 shell 的 PATH，而 install.sh 在 /usr/local/bin 不可写时会退到 ~/.local/bin——那正好是 cron 看不见的地方。

   command -v relayium

2. 确认这把密钥在没人守着键盘时也能用。BatchMode=yes 会直接失败而不是弹提示，这正是 cron 的处境。

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

3. 先手动完整跑一次，写法要和 cron 将要执行的一模一样，包括绝对路径。

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

4. 确认之后再加计划任务。绝对路径和重定向都要保留。

   crontab -e

5. 第一次定时执行之后，去读日志，不要想当然。这一步是最容易被跳过的，也正是本可以提前告诉你问题的那一步。

   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

• 只要有文件没通过完整性校验，命令就会以非零状态退出，cron 的失败邮件通知就能发现问题。
• 被中断的 sync 会在下一次计划运行时补上：已匹配的跳过，半截的接着传。被中断的 push 不续传——但因为每晚都写进各自按日期命名的目录，第二晚是一次干净的完整复制，而不是一次拒绝。
• 按日期命名的目录会越堆越多。请在目标端按你负担得起的节奏清理，否则磁盘会替你回答这个问题。

镜像删除与实时同步

默认情况下，sync 只会在目标端新增或更新文件。加上 --delete 才会变成真正的镜像，把源目录里已经不存在的文件也从目标端删掉——而谁需要同意这件事，取决于你用的是哪种目标。走 relayium:// 时，接收端是别人启动的独立进程，所以它必须以 serve --allow-delete 启动；否则这些删除会被跳过，并回报给你为 denied。走 SSH 时根本没有独立的监听端可以同意：sync 是通过你自己的 SSH 会话、以你的身份把接收端拉起来的——没有 --allow-delete 可设，传了 --delete 就是真删。本文里的 SSH 目标属于后一种情况。

两件事限定了破坏范围：删除只会发生在这一次运行真正发送的顶层目录内，目标端的兄弟目录永远不会被碰；而且如果源端解析不出任何文件，sync 会直接拒绝 --delete，所以源路径写错、或者该挂的没挂上，都清空不了目标目录。

不想等 cron 的下一个执行点，就用 --watch：它会让 relayium sync 常驻运行，源目录下一有文件变动，片刻之后就自动重新同步——比按计划轮询更轻量。

• relayium sync ./data user@backup-server:/srv/backups/ --delete 会把删除也镜像过去，而走 SSH 时除了你自己没人需要同意。如果源端误删比目标端留个旧文件更糟，就别加 --delete。
• relayium sync ./data relayium://backup-server:9031 --delete 只有在那个监听端以 serve --allow-delete 启动时才会真删；否则会回报为 denied。
• relayium sync ./data user@backup-server:/srv/backups/ --watch 会常驻运行，一有变化就同步，而不是靠 cron 单次触发。

出问题时怎么办

这里每一种在你去看日志之前都是不可见的，所以那条日志重定向写在 crontab 行里，而不是可选项。第五种比不可见更糟：它看起来像成功。