如何创建远程目录的本地 tar 文件

如何创建远程目录的本地 tar 文件

关联描述了如何复制 tarred 文件以尽量减少通过网络发送的数据量。我正在尝试做一些略有不同的事情。

我在不同子目录级别上有许多远程文件:

remote:/directory/subdir1/file1.ext
remote:/directory/subdir1/subsubdir11/file11.ext
remote:/directory/subdir2/subsubdir21/file21.ext

我有一个列出所有这些的文件:

remote:/directory/allfiles.txt

为了最有效地复制它们,在远程站点上我只需执行

tar zcvf allfiles.tgz `cat /directory/allfiles.txt`

但没有足够的空间来做到这一点。

我的本地磁盘上有足够的存储空间。有没有办法tar从远程服务器传入流(使用scpssh用于传输)?

类似于/localdir$ tar zc - | ssh remote `cat /directory/allfiles.txt`我猜测的那样 - 但这只会列出本地主机上的远程文件。

答案1

您几乎做对了,只需在远程主机上运行 tar,而不是在本地运行。该命令应类似于以下内容:

ssh remote_host tar cvfz - -T /directory/allfiles.txt > remote_files.tar.gz

答案2

如果你的本地磁盘上有足够的空间,并且你的目标是尽量减少通过网络发送的数据量也许启用压缩就足够了 SCP或者同步

scp -avrC remotehost:/path/to/files/file1 /files/file2 ...  local/destination/path

当然,你可以编写一个小脚本来循环遍历每个文件并进行 scp 压缩传输,甚至无需使用 tar。使用同步

rsync -avz --files-from=FILE remotehost:/path/to/files  local/destination/path

您可以通过以下方式连接远程控制到远程主机并写入

tar cvzf - -T list_of_filenames | ssh Local_Hostname tar xzf -

参考:

  • man scp

    -C      Compression enable.  Passes the -C flag to ssh(1) to enable compression.
    
  • man rsync

    --files-from=FILE       read list of source-file names from FILE
    -z, --compress          compress file data during the transfer
    --compress-level=NUM    explicitly set compression level
    

答案3

如果我们接受您的启动命令:

tar zcvf allfiles.tgz `cat /directory/allfiles.txt`

然后我们需要做的就是确保文件最终到达远程。因此,让我们将 tar 传输到标准输出,通过 netcat 进行管道传输,并将其保存为本地文件。

或者,像这样:

本地:nc -l 1234 | gunzip | tar zcvf allfiles.tgz
远程: cat /directory/allfiles.txt | gzip | nc localIP 1234

解释:

本地,步骤 1:从 netcat 输入。-l 监听某个端口。将输出发送到您想要的任何位置。
远程:步骤 1:您已经退出文件列表。gzip 压缩以获得最少的网络数据。将结果发送到本地。
本地:步骤 2:嗯,我们已经获得了 gzip 压缩文件。让我们在将它们提供给 tar 之前对其进行解压缩。

答案4

如果你想尽可能地压缩数据以减少所用的带宽,你可以使用 xz 工具运行 tar 命令,如下所示:

ssh host 'tar cvf - -T /directory/allfiles.txt | xz -9' > files.tar.xz

注意额外的单引号 ( ')。这是必需的,因为管道需要由远程 shell 而不是本地 shell 运行。

不过,这里有一些需要注意的缺点:

  1. 该过程使用了大量内存(大约 700Mb),因此你需要确保你的服务器有足够的可用内存(最好是 1Gb 或更多),以免开始交换
  2. 使用时命令xz非常慢-9。如果您不为使用 CPU 数小时而支付额外费用(如果您正在传输 Gb 的数据...),那么您应该没问题。
  3. 它还只使用一个 CPU,这可能是一件好事。无论如何,您将在整个过程中拥有一个使用率为 100% 的 CPU。

不过,如果您的带宽是您服务中最昂贵的部分,那么使用最佳压缩是个好主意。

请注意,压缩会降低下载速度。如果您的服务器磁盘驱动器上有足够的空间,那么您可以尝试在服务器上创建 tarball,完成该过程后,进行一次快速传输。我提到这一点是因为如果您的连接有点不稳定,上面的 ssh 命令可能会中途中断,然后您必须重新启动整个过程...如果这是一个真正的问题,使用rsync肯定是您最好的选择。使用的优点rsync是它一次发送一个文件,并且能够从中断的地方重新启动。它也会压缩数据,但据我所知,它只知道 gzip(但我已经有一段时间没有检查过了,它们现在可能支持更好的压缩器)。

相关内容