通过Windows网络传输大文件的最简单，最快的方法是什么？

我有一台运行MS SQL Server的Window Server 2000计算机，该计算机存储了20GB以上的数据。每天将数据库备份到第二个硬盘驱动器。我想将这些备份文件转移到另一台计算机上，以构建另一台测试服务器并进行恢复练习。（备份实际上从未恢复过将近5年。请不要告诉我的老板！）

我无法通过网络传输大文件。我已经尝试过简单的网络复制，apache下载和ftp。当传输的数据量达到2GB时，我尝试的任何方法最终都会失败。我上一次成功传输文件是通过USB连接的外部硬盘驱动器。但是我想定期执行此任务，最好自动执行。

想知道这种情况下最实用的方法是什么？

可预测的2Gb失败听起来像是目标文件系统...都是在NTFS上吗？您是否正在进行任何压缩（过去在2gb边界失败的zip压缩）（（Apache正在压缩））

我已经使用robocopy复制了超过20Gb的许多文件（就像其他人所提到的一样），但是我避免使用/ MIR开关，直到您确定可以执行所需的复制为止-因为它将删除文件并进行复制。

SMB一次只能承受一个数据包，因此通常是复制文件的较慢方法-您可以选择使用推入或拉入进行复制。就个人而言，我更喜欢push方法（复制由源启动）。

MS Exchange工具eseutil是一个出色的实用程序，可通过网络快速复制大型文件：

eseutil / y source_file / d dest_file。

我强烈建议使用免费实用程序RichCopy。它是多线程的，可以暂停和继续文件复制操作。我很幸运使用它在服务器之间传输文件。

我使用RichCopy的三个主要技巧

1. 如果要复制一个或几个大文件，请将“文件复制”属性设置为大于“ 1”。它消耗了资源，但更快地复制了大文件

2. 如果要复制大量文件，则将“线程号”属性设置为10-10-1。这样可以更快地复制多个文件

3. 如果通过狡猾的连接进行复制。您可以重新运行下载程序，它将开始查找第一次无法获取的文件。

http://blogs.technet.com/markdea/archive/2009/03/24/richcopy-is-it-the-new-sliced-bread.aspx

就文件复制实用程序而言，TeraCopy是一种基于GUI的不错的工具（不是命令行），可以将大量文件排入队列，支持暂停和恢复，可以动态更改其缓冲区大小以优化速度，并可以选择替换Windows资源管理器的默认设置。自己复制/移动。

具有/ MIR选项的Robocopy对于在机器之间进行快速而肮脏的备份非常有用。您可以在Windows Server 200X资源工具包中找到robocopy

MIR会将一个目录的内容MIRror传递给另一台服务器。它将仅复制已更改的文件。

对于大型SQL Server备份文件的重复打乱，最实用的解决方案是使用第三方备份压缩产品或SQL Server 2008 Enterprise Edition的内置备份压缩。

有不同供应商的产品。我为LiteSpeed的制造商Quest Software工作，但是我什么都不卖。您想检查所有产品，然后确定最适合您的需求。这是最近的博客文章，专门讨论LiteSpeed，但是相同的概念也适用于其他产品：

http://blogs.lessthandot.com/index.php/DataMgmt/DBAdmin/title-8

您是通过LAN还是通过诸如ADSL之类的WAN连接复制文件？我认为这是WAN，因为20GB不是要通过LAN复制的大文件。我每天都会复制许多此类文件。

如果是WAN连接，那么我的方法是使用Cygwin版本的rsync。

JR

我的网络传输失败在2GB左右-事实证明这是一个有故障的NIC。

我每天都使用syncback（http://www.2brightsparks.com/syncback/sbse.html）来传输比您大几倍的文件。从来没有问题。

有点晚了，但我建议使用第三方备份和还原应用程序选项。我们使用Red Gate SQL备份（www.red-gate.com），它在GUI中具有压缩和备用位置选项。我平均节省了80％的压缩-因此您只能传输实际数据库大小的20％。它还支持加密，因此可以在WAN上使用，而不必担心拦截。

它完全可调度，因此可以按您选择的周期自动运行。

GUI还允许您配置和管理日志传送。

以上提供免费试用版。

我没有使用如此大文件的经验，但是您能否将robocopy甚至xcopy与/ Z选项一起使用，声称具有可重启功能。似乎这是用于网络不可靠的大文件副本的。

我已经使用了robocopy超过1GB，并且没有问题。ss64.com很好地说明了这些开关。我虽然不能发布链接:-(

邪恶的答案..

使用Netcat。可以在此处找到面向Unix的文件传输教程。您可以通过以下方法进一步加快处理速度：

1. 在发送方进行压缩，然后在目标方进行解压缩。（在命令行中间将相当于gzip的窗口删除。）
2. 选择通过udp而不是通过tcp发送数据（嘿，谁在乎数据完整性？！！）

除了开玩笑，netcat可能是在LAN上传输大文件的最快方法。由于未完成校验和，因此您可能希望在发送文件之前对文件进行MD5和，然后将其与接收文件的MD5和进行比较。

我以这种方式大量使用了netcat，从未见过它失败，也从未见过它无法使网络最大化。

可能值得将文件分成较小的块作为短期解决方案，直到您可以查明问题为止。过去，我们遇到过类似的问题，而ftp一直对我们有用

如果这些是您要复制的SQL .bak文件，我强烈建议您执行以下操作之一以在复制之前缩小文件：

• 在运行备份之前，请收缩数据库并截断日志。要么
• 复制之前先压缩.bak文件。如果您不使用数据和日志文件中已分配的全部空间，则SQL .bak文件将向下压缩。

可能不需要复制大文件的替代方法。

我认为没有问题可以更快地传输是您的问题，请仔细检查以确保您的目标文件系统不是FAT，就像其他人所说的那样。另外，请确保两侧的NIC都有更新的驱动程序，并且其他情况下不会出现不稳定的情况。

话虽这么说，您是要移动许多小文件还是仅移动一些大文件？尝试移动数百万个小文件时，我已经看到RAID控制器问题。

我认为一旦找出导致故障的原因，自动化此操作就不会出现问题。它可能有助于列出有关硬件以及事件查看器中可能看到的任何相关错误的更多详细信息。

您是否尝试过使用eSATA连接到外部硬盘驱动器？连接速度很快（3 GB！），应该能够立即传输该文件！

服务器上的网卡以10/100或10/100/1000的速度是多少？处理文件时，服务器网络带宽和交换机的外观如何？复制时，目标位置（服务器的网络带宽）是什么样的？您是否尝试将2个NIC组合在一起？网卡驱动程序是否最新？BIOS是否已更新？

文件传输可能有很多问题。确保硬件驱动程序和BIOS是最新的，确实可以有所作为。

-JFV

最简单，最快的方法：外部USB磁盘和移动设备。

我的方式：使用rsync。如果复制失败，请重新启动它，然后它将在它离开的地方取走。

要检查的另一件事是查看是否在目标服务器上设置了配额服务。我认为它使用2 GB作为每个用户的默认配额。