用 Relayium CLI 通过 SSH 在自己的服务器上留一份异地副本

开始之前

下面用到的都是 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”。

把一个目录 push 到你的服务器

push 接受一个或多个源，以及一个 scp 风格的目标地址。Relayium 会用你平常的密钥和配置通过 SSH 连过去，再把文件流式写入目标目录：

1. 确认 push 将要复用的那条 SSH 访问。静默返回就说明你的密钥、主机别名和端口都已正确。

   ssh user@your-server true

2. 查清你会走哪条协议。打印出路径就是原生协议——发送前的冲突预检加逐文件 SHA-256；什么都不打印就是走 tar 流兜底，那条路逐文件什么都不校验。

   ssh user@your-server command -v relayium

3. 把目录 push 上去。目标是 scp 风格的写法，末尾的斜杠表示“放进这个目录里”。

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

4. 如果你的 ssh 配置里还没有这台主机，就为这一条命令临时指定密钥或端口。

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

5. 确认落地结果。push ./photos 会在目标下重建 photos/，所以文件夹名会一起带过去。

   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)

• 它会复用你的 ~/.ssh/config，所以你早就配好的主机别名、密钥和端口都能直接生效。
• 如果服务器上装了 relayium，就走原生协议：发送任何字节之前先对整批做冲突预检，传输的每个文件都做 SHA-256 校验并先落到暂存区再安装。
• 如果没装，就退回到把 tar 流通过管道送给远端自己的 tar -x -k，所以一台没有 relayium 的裸服务器也能收——但那条路逐文件什么都不校验，而且可能让一批文件只装了一半。

把文件 pull 回来

恢复就是把同一条命令反过来写：给出一个远程源和一个本地目标目录。恢复备份，或者把服务器上的产物同步回笔记本，都用它：

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

• 和 push 不同，pull 始终需要远端已经装好 relayium——它没有 tar 兜底方案，远端要是没装，请先装好。

完整性校验是内置的，续传不是

两端都装了 relayium 时，push 传输的每个文件都会用 SHA-256 哈希做端到端校验，并先落到暂存区再安装——落到服务器上的内容，和你发出去的逐字节一致。这一半是真的，也正是值得在目标端装上 relayium 的理由。

push 不做的事情是续传。它也不是事务：文件是一个一个装上去的，所以中途断线会把已经落地的文件留在原地——而正因为这些文件现在存在了，重跑同一条 push 会被冲突检查拒绝，而不是接着传。请显式补传缺失的路径，或者改用 relayium sync：它才是会跳过已匹配文件、并在下次运行时接着传半截文件的那个模式。

--no-resume 在 push 和 pull 上能被接受，但什么也不做。它只在接收 sync 的 serve 监听端上才是真的有效——那里才可能出现半截文件。

• SHA-256 校验会自动进行；一旦对不上就会报出来，该文件被标记为失败。
• 它覆盖的是这一次真正传输的内容。tar 兜底路径不做任何哈希；而 sync 的 size+mtime 跳过意味着看起来没变的文件根本不会被读取，也就不会被哈希。
• push 和 pull 在两条协议下都不续传。预计会被中断的目录，请用 sync。

用 cron 让这份副本保持最新

要放进 cron 的是 sync，不是 push。push 会拒绝已存在的目标，所以每晚往同一个目录 push，只有第一晚会成功，之后每晚都被拒。sync 才是为反复运行设计的：它跳过大小与修改时间都没变的文件，只发变化的部分，并接着传上一次中断留下的半截文件。

它是一条用你自己 SSH 密钥的非交互式命令，所以可以原样放进 cron。给它指定一个没有口令的密钥（或者用 agent），并把输出记下来，好让失败能被看见：

# 每晚 2 点备份——加到你的 crontab 里（crontab -e）
0 2 * * * relayium sync -i ~/.ssh/backup_key ~/documents user@your-server:backups/ >> ~/relayium-backup.log 2>&1

• 一个被中断的夜间 sync，下一晚会接着来：已经匹配的会被跳过，半截的文件会接着传而不是重头来。
• sync 没有 tar 兜底，所以服务器上必须装有 relayium。那是一次响亮的失败，而不是悄悄降级。
• 只要有文件没通过完整性校验，命令就会以非零状态退出，cron 的失败邮件通知就能发现问题。
• 它保持的是副本的最新状态，不保存历史。只有当你确实希望源端的删除也在服务器上生效时才加 --delete——那就是镜像，而如果你可能误删东西，这恰恰是你不想要的。

定时副本没落地的时候

定时任务天生就是悄无声息地失败的——没人盯着终端。下面四种是真正会发生的，而且每一种都能用一条你现在就能跑的命令定性。它们并不是全部：目标端也可能磁盘满了，或者那个 SSH 用户没有写权限。