☰

使用 cURL/rsync 进行 FreeBSD 转储

tag-icon • tag-icon freebsd rsync curl dump
使用 cURL/rsync 进行 FreeBSD 转储

我正在尝试使用 FreeBSD 的 dump 创建一个备份脚本来获取文件系统的快照，但我并不希望将快照存储在磁盘上，而是希望将 dump 的输出通过管道传输到 cURL 或 rsync 中，以便远程存储。我已通过 SSH 通过管道传输该脚本，以将输出传输到远程端，但出于安全原因，我需要使用 cURL 或 rsync 来执行此操作。

我尝试了许多不同的命令行参数：

dump -0u -a -L -f - /dev/ad0b | curl -v --data @- http://1.2.3.4/
dump -0u -a -L -P "curl -v --data - http://1.2.3.4/" /dev/ad0b
dump -0u -a -L -P "rsync --progress --stats rsync://1.2.3.4/backup" /dev/ad0b

无论我做什么，要么管道破裂，要么就是没有数据传输。

我可以手动将其转储到文件中，然后通过 cURL 或 rsync 上传，但这违背了我想要的目的。

任何帮助或指点都将非常有用。

答案1

这两种尝试中的任何一种的基本方法curl看起来都不错。但是您的转储是二进制数据，因此--data是错误的（数据将被破坏）。根据您的网络服务器的期望，您可能更幸运地使用其中一种

  • curl -v --data-urlencode @- http://1.2.3.4/，如果预期格式是 URL 编码数据。
  • curl -v --data-binary -H 'Content-Type: octet/stream' @- http://1.2.3.4/，如果预期格式是原始二进制数据。
  • curl -v -F "mydump=@-" http://1.2.3.4/，如果预期格式是表格。

这一切都取决于 HTTP 服务器的期望。检查您正在使用的任何 CGI 的文档（或者如果您需要帮助，请在此处发布）。

如果监听 1.2.3.4 的服务器期望原始数据而不是 HTTP POST 请求，那么curl就是错误的工具（http当然也是错误的）。网猫是将数据传输到 TCP 套接字的最流行工具：nc 1.2.3.4 5678。

Rsync 不太可能起作用。rsync 的主要目的是仅复制文件中两侧不同的部分，这需要在源文件和目标文件内部进行大量搜索。此外，rsync 旨在处理文件层次结构，而不是单个文件。从技术上讲，可以编写一个始终复制整个文件的 rsync 客户端，因此不需要搜索源数据，但这种需求非常不寻常，我怀疑是否存在这种需求。

相关内容