Linux 上的 ZFS 在 ssh 连接不佳/坏的情况下发送/接收简历

Ura*_*ral 8 linux zfs snapshot replication

我在 Linux 上使用 ZFS,并尝试设置远程复制。但是我的 ssh 连接不好,并且 zfs 通过 ssh 发送/接收再次重新启动。我知道 ZoL 上存在问题,但我不知道它何时会实施,或者新的稳定版本即将发布。我听说过 mbuffer,但似乎无法重新启动。也许可以像 zfs send 一样使用它 | 缓冲区 | 虽然是真的;做 ssh ...; 完成,但不确定。

现在我正在将 zfs 发送到一个文件,将它与 --append --partial 同步到远程和恢复。但它占用空间,需要人工帮助,并且是一个肮脏的解决方案。我想要一些自动化的解决方案,比如 sanoid/syncoid,来保存我的池的镜像和所有快照。也许一些 bash 脚本做同样的事情,但将所有快照保存在远程,在成功同步后删除主机上的文件等。请帮忙

PS我知道有一个重复的问题,但没有任何解决方案。在我的问题中,我使用了一些肮脏的解决方案,并想更换或改进它

小智 8

您可以使用-szfs receive 选项,如果传输失败,它将在接收端保存一个可恢复的令牌。这取决于您使用的是 netcat (nc) 还是 SSH。

在recv机器上 (仅限 netcat):

nc -l <port> | zfs receive -s -v tank/dataset

在send机器上:

从通常开始send:

zfs send -v snapshot | nc <host> <port>

zfs send -v snapshot | ssh ... zfs receive -s -v tank/dataset

如果传输失败,请在recv机器上输入:

zfs get all tank/dataset

获取receive_resume_token并继续上send机:

zfs send -v -t <token> | nc <host> <port>

zfs send -v -t <token> | ssh ... zfs receive -s -v tank/dataset

干得好 :)

  • 一些附加说明:令牌在每个对象(大多数情况下是快照)传输后更改,并在整个文件系统完全传输后销毁。由于它是为每个文件系统保存的,因此递归发送/接收并不能很好地发挥作用 - 手动迭代所有文件系统并单独传输/恢复它们可能比使用内置递归选项更容易。 (3认同)