80T 的服务器文件该如何转移？

好的，咱们就来聊聊怎么把一台 80T 容量的服务器上的文件安全、高效地转移出去。这么大的数据量，可不是件小事，需要仔细规划和操作。

首先，我们要明确几个关键点：

数据是什么？ 是数据库文件？大量的媒体文件？代码库？不同的文件类型在转移时可能需要不同的策略。
转移的目的地是哪里？ 是另一台服务器？云存储？还是本地硬盘？目的地不同，接口和工具也会不一样。
对转移时间和中断时间的要求是什么？ 是要尽量缩短服务中断时间吗？还是可以接受较长的离线迁移时间？
网络环境怎么样？ 服务器之间的带宽是关键，内网还是外网？速度有多快？

有了这些基础信息，我们就可以开始制定详细的迁移方案了。下面我将从几个方面来展开：

第一步：前期准备与规划

这是最重要的一步，直接关系到迁移的成败。

1. 数据盘点与清理：
确认数据量： 再次核实 80T 的确切数据量，了解哪些是核心数据，哪些是可以归档或删除的“垃圾”数据。
数据分类： 将数据按照重要性、访问频率、文件类型等进行分类。例如，核心数据库文件可能需要更严谨的备份和恢复流程，而日志文件可能可以批量压缩转移。
文件压缩与去重（如果适用）： 如果数据中存在大量重复文件或可以有效压缩的文件类型（如文本、日志），可以考虑在源端进行预压缩，减小传输量。当然，这会增加源端的 CPU 负担，需要权衡。
权限检查： 确保您有足够的权限读取所有需要迁移的文件。如果涉及用户目录，要了解清楚文件的所有者和权限设置，以便在目标端恢复。

2. 目标环境准备：
存储空间： 确保目标存储（另一台服务器、云存储等）有足够的空间来容纳 80T 的数据，并且留有适当的余量以应对未来增长。
网络带宽： 这是影响迁移速度的关键。
内网迁移： 如果是两台服务器之间迁移，尽量确保它们连接到同一个高速内网，例如万兆（10Gbps）甚至更高带宽的交换机。确认内网链路是稳定且畅通的。
外网迁移： 如果需要通过互联网传输，那带宽将是瓶颈。评估当前公网出口带宽，并考虑是否需要升级带宽或选择特殊的服务。
目标系统： 确保目标系统已经安装好必要的文件系统、软件包和工具。

3. 工具选择：
高可用性与效率： 对于如此大的数据量，我们需要选择能够支持断点续传、多线程并发传输、校验文件完整性的工具。
常用工具推荐：
rsync： 这是 Linux 系统下非常强大且常用的工具，支持增量备份、文件校验、权限保留等。可以通过参数 `avzP` (archive, verbose, compress, progress) 来进行高效传输。
scp/sftp： 简单直接的文件传输协议，适合少量文件或简单场景。但对于大批量文件，效率不如 rsync。
wget/curl： 主要用于下载 HTTP/FTP 资源，不太适合服务器间文件批量迁移。
专业数据迁移工具： 比如一些云厂商提供的专有迁移服务（如 AWS DataSync, Azure Data Box, GCP Transfer Appliance），或者一些第三方数据同步工具，它们通常对大容量、长距离传输做了优化。
数据库迁移： 如果是数据库文件，则需要使用数据库自带的备份和恢复工具（如 mysqldump, pg_dump, Oracle RMAN）或者专门的数据库迁移服务。

4. 迁移策略制定：
全量迁移 vs. 增量迁移：
全量迁移： 一次性将所有数据复制过去。简单直接，但耗时最长。
增量迁移： 先进行一次全量复制，然后在迁移过程中只复制自上次同步以来发生变化的文件。这可以大大缩短最终切换的时间。
分批迁移： 将 80T 数据分割成若干个较小的批次进行传输，可以降低单次传输的风险，方便管理和监控。
时间窗口： 确定一个数据量影响最小的时间段进行迁移操作，特别是涉及服务中断的情况下。

第二步：实施迁移过程

准备工作就绪后，就可以开始实际操作了。

1. 测试迁移（小范围）：
在正式迁移 80T 数据之前，强烈建议先选取一小部分具有代表性的数据（比如几个 GB 到几十个 GB）进行测试迁移。
测试使用的工具、命令参数、网络速度、目标端写入速度以及文件完整性。通过测试，可以及时发现问题并调整方案。

2. 执行全量迁移：
使用 rsync 的示例：
假设源服务器 IP 是 `source_ip`，数据目录是 `/data/big_data`；目标服务器 IP 是 `target_ip`，目标目录是 `/mnt/new_storage/big_data`。
在源服务器上执行（或者在另一台有权限访问两边服务器的机器上执行）：

```bash
在源服务器上执行
rsync avz progress /data/big_data/ user@target_ip:/mnt/new_storage/big_data/

或者在目标服务器上执行（如果已有SSH访问权）
rsync avz progress /data/big_data/ user@source_ip:/mnt/new_storage/big_data/

解释参数：
a: 归档模式，等同于 rlptgoD，保留文件权限、所有者、时间戳、设备文件、符号链接等。
v: 显示详细输出信息。
z: 传输时压缩数据，可以节省带宽，但会增加 CPU 负担。如果网络带宽远大于磁盘 IO，可以考虑不加或只对特定类型文件压缩。
progress: 显示传输进度。
/data/big_data/: 源目录，注意末尾的斜杠表示复制目录里的内容，而不是目录本身。
```
处理断点续传： rsync 本身支持断点续传。如果传输过程中网络中断或进程被意外终止，再次执行相同的 rsync 命令，它会自动从上次停止的地方继续。

3. 数据校验：
文件数量和大小对比： 在迁移完成后，对源端和目标端的文件数量和总大小进行核对。可以使用 `find /data/big_data/ type f | wc l` 和 `du sh /data/big_data/` 等命令。
校验和/MD5/SHA1： 对于关键数据，可以考虑生成源端和目标端的文件的校验和（如 MD5 或 SHA1），然后逐一比对。这会比较耗时，但能确保数据完整性。例如：
```bash
在源端生成文件列表和MD5
find /data/big_data/ type f print0 | xargs 0 md5sum > source_md5.txt

在目标端生成文件列表和MD5
find /mnt/new_storage/big_data/ type f print0 | xargs 0 md5sum > target_md5.txt

比较两个MD5文件
diff source_md5.txt target_md5.txt
```
注意：直接对 80T 文件生成 MD5 会非常耗时，可能需要单独的进程或服务器来完成，并考虑存储这些校验和文件。

第三步：增量同步与最终切换

如果迁移过程中源端数据还在变化，或者为了最小化服务中断时间，需要进行增量同步。

1. 执行增量同步：
在完成全量迁移后，如果源端有新的数据产生或已有数据发生修改，再次执行相同的 rsync 命令。这次，rsync 会检测并只传输变化的部分。
可以设置一个固定的时间间隔（例如每小时、每天）来运行增量同步，以保证目标端的数据与源端尽可能同步。

2. 业务暂停与最终同步：
在预定的切换时间点，暂停源服务器上的业务访问。这是为了确保在最后的同步过程中，源数据不再发生变化，避免数据不一致。
执行最后一次增量同步。
再次进行快速的数据校验（例如文件数量、关键文件的大小对比）。

3. 切换服务：
将应用程序或用户的访问指向新的目标服务器。
在新服务器上启动服务，并进行充分的测试，确保一切正常工作。

第四步：善后工作

1. 数据验证与回滚计划：
在确认新服务器稳定运行一段时间后，可以考虑对数据进行更详细的验证。
保留源数据一段时间，以防万一需要回滚。

2. 清理旧数据：
当确认所有数据迁移和业务都运行良好后，可以根据策略安全地删除源服务器上的旧数据。

一些补充建议和注意事项：

网络稳定性： 80T 的数据量意味着长时间的传输，网络必须足够稳定。任何中断都可能需要重新开始或处理断点。考虑使用具有流量控制和自动重连机制的工具。
磁盘 I/O 瓶颈： 除了网络，源端和目标端的磁盘 I/O 速度也可能成为瓶颈。如果使用的是机械硬盘，传输速度可能会受到限制。SSD 或 NVMe 硬盘会有更好的表现。
CPU 占用： rsync 的 `z` (compress) 参数会消耗较多 CPU 资源。如果服务器 CPU 本来就很高，需要权衡是否启用压缩。
SSH 密钥认证： 建议在源端和目标端配置 SSH 密钥认证，这样在执行 rsync 时就无需每次输入密码，方便自动化。
监控： 在整个迁移过程中，要密切监控网络流量、磁盘 I/O、CPU 使用率以及工具的运行状态。设置告警机制。
日志记录： 确保所有迁移操作都有详细的日志记录，方便追溯和排查问题。
自动化脚本： 对于如此大的数据量，强烈建议将迁移过程脚本化。这样可以减少人为错误，并方便重复执行。例如，写一个 shell 脚本来执行 rsync，并包含日志记录和简单的状态检查。
专业迁移方案： 如果数据是高度敏感、关键业务不允许有任何中断，或者你没有充足的技术和时间进行自助迁移，那么强烈建议考虑使用专业的数据迁移服务或咨询有经验的 IT 团队。例如，一些云服务商提供专门的大规模数据导入服务，他们会提供物理设备给你，你把数据拷贝到设备上，然后寄回给他们，他们再导入到云端。这种方式通常更安全、更快捷，但成本也更高。

总的来说，80T 的服务器文件转移是一项系统工程，需要周密的计划、合适的工具和耐心的执行。细致的准备和测试是成功的关键。希望这些详细的步骤和建议能帮助你顺利完成这次数据迁移！

这个可以很简单。

插上硬盘（不管是存储服务器、阵列还是 USB ）拷走。

ISP 如果在北京有机房， 可以问 ISP 要流量减免， 镜像。

80T 是很小的数据量， 如果新服务器打算上 SSD， 现在就可以去批发。

方法很多，有便宜有贵，甚至还有一个坏主意。

方案一：

硬盘每T价格在单盘3-4T最低，之前之后都不够经济。

你说5块16T，成本在4500*5=22500，觉得贵了，那么我推荐你考虑4T*20，估计也就12000就搞定了，再给你加个冗余，避免硬盘坏了白跑一趟，25块硬盘，也就15000搞定。

冗余可以用snapRAID这种方案，5块冗余盘，只要路上不阵亡超过五块硬盘，数据就没事儿。

这么多硬盘的好处在于，并发读写，理论上能达到上GB/s，大大加速你拷贝数据的速度。

方案二：

只要你冗余够多，硬盘都不用新的，二手的也足够，目前3T的二手硬盘也就200，算上冗余，50块够了吧，也就10000块钱搞定。

方案三：

磁带，数据磁带比硬盘便宜不少，就算是用新磁带，成本也很经济了。

如果你能接受磁带库淘汰的货，价格会更低，磁带还支持压缩。

只是磁带机贵些，好在磁带机基本都能向前兼容两代磁带，算是一次性投资。

如果你需要经常运输数据这个选项也不错。

方案四：

互联网是建立在分组转发的基础上的，只是为了延迟考虑，这个分组都挺小的。

我们可以借鉴这个思路，来个超大分组，超大延迟，超大带宽的数据传输。

北京深圳往返的快递时间，顺丰航空件也就一天时间，你可以理解为每两天时间一次往返，可以完成一块硬盘数据量的传输，带宽还是很可观的。

如果你买的是16T的硬盘，只要买一块，或者买两块做raid1，避免硬盘损坏造成损失。

16T/2天/24小时/3600秒=741Mbps，基本上已经接近千兆网络的带宽了。

只要9天左右（不算最后一次硬盘寄回去的时间，因为数据已经完成传输了），就可以完成数据传输了。

而且只需要一块或者两块16T硬盘，算上快递费和raid1冗余，10000块足够。

如果能用3-4T的硬盘，还会更便宜，合理平衡买的硬盘数量和快递费以及时间，还可以有更优的解。

比如5块4T硬盘组raid5，依然可以实现9天传完，但是只需要3000硬盘钱+1000左右的快递费。

方案五：

民用宽带现在上传都能有30Mbps左右，把数据拷贝到移动硬盘里，带回家，慢慢上传到北京的机器，这个方案基本不花额外的钱，但是时间超长，要一年多，只要数据够冷，其实也不是不可接受，我相信你们的服务器应该带宽高于30Mbps，至少100Mbps对称起步吧。

方案六：

京东买一堆硬盘，用完了做个数据安全销毁，全盘随机写入7次，然后退货。

嗯，这个方案成本是0，最多可能需要个京东plus会员。

根据京东的规则，第七天提交退货申请，取件时间最多可以约到提交日之后六天。

到了取货日前一天，可以提交一次日期改约，又可以延期到六天后，到了真正的取件日期，可以联系小哥，要求再缓一天，小哥点一个取件单再投，就可以了。

这样累计可以用18天。

是不是很鸡贼？

然后，你就不是东哥兄弟了。

其实就算你不退货，而是把硬盘二手卖掉，怎么也算是99新，回7成血还是没问题的。

以上所有的方案中，用的介质都是可以多次使用的，都有较高残值。

这也是为什么我没有考虑蓝光光盘等一次性介质，这可是实打实的一次性成本，不是土豪用不起。

---

我从一个咨询顾问的角度看，很多时候，客户的描述是存在问题的。

用户说我要一个钉子和一把锤子，但是当你仔细和客户沟通之后，发现客户的诉求其实是墙上有个洞，但是客户只知道锤子和钉子能打洞，于是表达成了要锤子和钉子。

差的顾问，只会真的给客户钉子和锤子，好的顾问，会在倾听客户需求之后，引导客户说出具体情况，并提出更优的方案，这才是真正能成就客户的做法，也更能让客户感受到你的专业和负责。有时客户听完最终方案，甚至高兴地说，这就是我想要的。

其实题主这个问题也是一样的，我有很多问题可以问，来提出更好的方案，比如：

80T的数据一定要转移吗？可不可以转移计算资源而不是数据。

一定要全部转移吗？一定要全部转移完了业务才能开始吗？

我相信80T数据一定可以分出冷数据、温数据、热数据，分级确定优先级传输，既兼顾了成本和时效，又不影响业务。

很多时候，数据可以进行清洗和汇总，有点儿边缘计算的思想，可能原始数据80T，对端真正需要的信息，经过汇总，可能只有几T，完全可以在本端预处理下，再传输。

如果这80T数据是稀疏的，压缩也会极大节省时间，还可以增加纠错码，减少传输错误造成的影响。

如果题主可以补充更多上下文，比如什么业务，什么类型的数据等等，也许会有更多好的方案。

假如北京的服务器没足量硬盘，还得买硬盘。怎么绕都绕不过去。

假如北京服务器有足量硬盘，网速快且时间足够，直接给百度云盘充个一两个月的超级会员当中转站就解决了。超级会员是5T。中转20次就够了。如果时间紧，磁带还是硬盘自个儿看着办。

楼主还是不要拷贝了。自认为很重要的80t数字资产，连4500都不愿意出，还谈什么重要。按照gcp的价格，每月光存储费用就超过1.5万，你还敢买绿盘，疯了，最可行是买群晖16盘以上的买12t以上的硬盘组raid 10，然后人肉快递群晖和硬盘。

大数据不是谁都能玩的起的，要有充足的预算，嫌贵就不要存这么多数据了。

80t数据

最快的方法是乘火车把服务器自己搬到北京

乘飞机服务器打包后不一定上的了飞机

20多小时

前提服务器和数据产权没争议

用硬盘拷贝 知道普通x86机器拷贝80t要多久吗

小文件多的话你会拷的吐血

高赞的dell卖家居然建议用md这种das柜子做raid0拷贝 无底线啊 md柜子+盘比服务器都贵了

md das柜子 raid依赖在服务器上 且数据高风险 机器成本很高 应该没人会借给你 das柜子的速度也并不快

推荐阿里云闪电云立方的更不谈了，有句话叫上云容易下云难

闪电云立方的存储是我们做的一个牌子oem的

闪电云立方仿造amazon pb卡车 不过只做线下机房数据迁移物理传送到阿里云机房

阿里对象存储每tb1800左右每年 流量费另算

闪电云立方租押金另算 比服务器都贵多了