我想改变网站托pipe供应商，从“供应商O”到“供应商N”为我pipe理的特定网站。 我与供应商O有问题。我pipe理目前与供应商N托pipe的几个网站，一切都令人满意。
顺便说一下：我pipe理的所有网站都是非商业的。 所以保持最低成本至关重要，而且使用低成本的共享主机是别无select的。
供应商O和供应商N都宣称“无限存储”，对于典型的现场操作，带宽容量已经足够了。
我受到大量数据迁移到新的托pipe：55GB和不断增长。 （这些数据大多是历史数据的JPG格式 – 不是色情内容。）看起来像是大量的数据移动。 （注意：所有这些数据已经在服务器上累积了好几年了，没有什么东西可以接近整个数据集的非现场拷贝了）。显然，从旧服务器上下载所有的数据并上传它是不切实际的到使用我的办公室DSL的新的。
shell访问可用于两端。 我一直在研究使用rsyn，scp和tar + wget等进行服务器到服务器的直接传输（我在serverfault上发现了大量有关这些信息的文章）。使用现有的Vender N帐户，运行一些服务器到服务器的testing，从供应商O传输数据。如果我得到的数字是有代表性的，55GB将需要花费很多星期来传输，运行开放式节stream。 这个结果看起来是否合理？
我还没有find关于服务器到服务器传输的实际方面的很多build议。 例如，是否build议节stream回转，以避免pipe道堵塞 – 并引起注意？ 初步数字表明试图变得更好可以将转移时间延长到几个月。 或者托pipe服务已经限制了带宽，特别是对于低端账户？
另外我也关注供应商function列表中“无限存储”的定义。 卖方O没有抱怨55GB的数据加载。 供应商N可以保证那么多的保证？ 阅读和重新阅读供应商N的服务协议并没有帮助。 这似乎是他们的判断电话是否允许客户使用存储空间。 如果网站数据只称1GB，我怀疑他们甚至会看，但我猜50GB +可能会受到一些审查。 或者，服务条款通常在存储使用方面没有被强制执行，除非是非常令人失望的错误使用？
我想象的噩梦是花了数周或者数月的时间，将95％的数据转移给卖主N，然后从卖主N那里得到一个通知，说“你的存储器的使用是不允许的”。
我是否正确构思问题？ 我错过了一些非常明显的东西吗？ 请提出build议。
TIA，
hen3ry
感谢您的所有build议。 首先，我将总结回复：
许多人build议打电话给新的供应商，并询问他们大部分的问题。 过去，我对技术支持的经验总体上令人失望，但是当我详细研究这个问题的时候，我学到了最好的结果。 所以…是的，现在我明白要问什么了，我会打电话。
– 有人build议运动鞋网的一种或另一种forms。 伟大的想法，从来没有想到这一点。 发送一个磁盘驱动器。 新的供应商是否愿意为新的共享主机帐户提供这样的服务水平？ 如果最好的电子传输方法是无望的缓慢，这是值得一问。
– 许多人强烈build议完整的站点备份是必要的。 你正在向合唱团传道。 我全心全意同意！ 部分情况超出了我的控制范围
– 人们提出了基于nc（netcat，synch，sshfs + sync等）的各种方法，其中大部分是不可能的，因为旧的供应商不支持它们（离开供应商的另一个原因）是通过SSH运行的scp，旧供应商似乎阻止了任何尝试通过SSH连接到新供应商的行为，但是我能够从新供应商的另一个站点使用scp。
初步testing结果：
使用来自新供应商的SCP，我能够达到3.7MB / s左右的峰值传输速率 – 但是由于频繁的传输速率，整体速率要低得多。 总共需要大约一个小时的重量约为1.4GB的280个文件组。 粗略地说，这表明整个文件集将需要不到40小时的传输 – 这看起来非常好。
避免转移摊位将有助于减less转移时间。 我没有看到任何模式。 通常，在传输给定文件的第一个块之前，传输将会停止（0％），但是在传输中途随机发生的时间长达30秒或更长时间。 有任何想法吗？ 旧供应商可以做一些节stream？ 我可以和其他客户竞争带宽吗？
你可以打电话给他们解释一下情况。 他们很可能会让你把所有你需要的东西全速转移到自己开始。 您在这里支付资金来托pipe您的数据，他们应该灵活地实际获取您的数据。
要确定他们的政策的唯一方法就是问问他们。
你也可以考虑sneakernet 。 根据他们所在的位置，他们是否能够执行部分服务，如果他们不会被授予物理访问权限等因素，您可以使用外部USB驱动器来执行转让。 当然可以比几个星期或几个月快得多。 他们也可能会喜欢它，因为它会阻止交通。 如果需要，Fedex将乐意参与。
同意这些build议来打电话给他们。
如果您最终通过networking进行传输，请考虑虚拟的确定性，即需要几天或几周的过程将被中断并重新启动。 出于这个原因，我倾向于像rsync这样的方法，而不是像tar这样的方法进入netcat。 如果您打算制作一个大的tar文件进行复制，不要忘记，在传输过程中，这会大大加倍您当前的存储使用量，并且在传输过程中数据集很可能会发生变化。您将需要一些机制来更新远程复制与更改。
另外，这听起来像你没有备份，这是一个等待发生的灾难。 如果您的传输过程会为您的数据创build额外的物理副本（如外部硬盘），请考虑在数据更改时更新该副本。 如果您的传输过程将通过networking进行，请考虑将Amazon S3（或Rackspace或Azure或其他）作为中间目标和正在进行的备份。 低成本的托pipe服务提供商可能不提供备份数据的保证 – 假设他们甚至试图这样做，这可能过于乐观 – 即使他们确实做了偶尔的备份，让您再次启动和运行可能不是一个大的如果遇到某种悲剧，那么优先。
如果shell的访问在两端都可用，并且您有权访问netcat（nc），那么传输55G数据的最快方法是通过netcat和tar。 就是这样：
在新服务器上：
# nc -l -p 40022 | tar xf -
而在目前的一个：
# tar cf - /path/to/data | nc newserver 40022
这当然是在公共互联网上不encryption的，所以如果你担心你正在传输的数据，请不要这样做。
而且，使用rsync over ssh的55G（如果可用的话）速度不会太慢，而且您将获得中断传输恢复的好处。
如果没有，你应该能够scp它。 这应该是与rsync相同的速度，因为它使用相同的传输，但是如果连接丢失，您将不得不重新启动。
我不会担心55G – 按今天的标准，这实际上只是非常less量的数据 – 它不会给您的新供应商带来任何问题。
如果我的服务器上有55 GB的数据对我来说非常重要，那么我将使用我的DSL线路在一夜之间下载所有的夜晚，以确保我有一个可以控制的备份。 特别是如果服务器是一个低成本的提供者。 尽pipe提供商可能进行备份，但是如果提供商停业，那么这些备份会发生什么？
至于提供商到供应商的转移，我希望速度至less每秒1兆字节。 转换55 GB将需要一天的时间。 但是，你还没有告诉我们你的提供者是多么的便宜。 如果您的新提供商提供shell访问，则可以使用wget或ftp从旧服务器下载文件。