几十上百T数据如何在服务器之间迁移，又什么解决方案？（可以停机）

要看什么数据，比如文件存储服务器，可以买2块万兆光纤网卡，直接复制，或者用软件复制，速度很快就搞定
如果带数据库，不建议直接复制，容易出问题，
数据库通过使用数据库的软件备份，比如用友，金蝶的数据库，然后复制备份数据到新服务器，原则上，以数据，从小到大开始
如果数据库实在太大，可以给使用该数据库软件的公司联系，看能不能做数据库和软件分离，单独的一台服务器只做数据库，只存放数据库数据，不负载其他软件，或者做类似分布式存储，多台服务器存储数据库数据，不集中在某一台服务器

服务器迁移的整体思路大概是：
新旧系统的迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求，在迁移过程中，我们需要重点考虑几个问题：
1、数据迁移如何保障“业务中断停机时间”。业务中断对用用户无论是生产环境还是测试环境均存在较大的恢复风险，这样的风险特别是对于时间敏感型数据还是对于数据完整性业务都是不可以接受的。我们基于这样的要求，考虑到如何将停机时间最小，能否实现0停机的建设目标？
i 对
于服务器 *** 作系统而言，我们可以采用P2V的方式，利用 *** 作系统的Volume Shadow Copy卷影副本复制服务作为基础，来实现在旧系统环境下
的系统无修改，无停机的情况下，将数据和应用软件、 *** 作系统环境、系统环境变量等全部以“快照”形式迁移到新服务器中。由此实现服务器环境的整体迁移。
ii 对
于应用IIS和其他应用服务器来说，我们可以基于应用服务器的动态业务扩展集群方式，来实现服务器不停机环境下的增加业务节点 *** 作，这样可以实现应用服务
器“热添加”到新环境中的故障转移/负载均衡集群系统中，在部分应用服务中我们可以使用session会话复制来实现旧系统的全局环境变量和会话请求状态
也迁移到新环境中来。考虑到会话复制和状态的快速实时，我们可以采用会话内存复制，考虑到会话复制和状态的安全性，我们可以采用会话数据库复制管理。
iii 对
于数据库而言，我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建，数据库镜像技术可以让我们不但保证数据
库迁移的不停机，而且还可以保证万一迁移中出现停机故障也不影响源数据库，而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行，这样可以让我
们的系统环境在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。
2、迁移涉及到的除了应用、实例、数据库的 *** 作以外，还涉及到迁移前规划、迁移后测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会话状态完整性测试、连接中断测试、数据恢复测试。只有这样才能保证迁移的安全性和有效性。

按照楼主的说法来判断，你们的Exchange2010服务器是把所有服务器角色都集中在一台服务器上，现在准备迁移到另外一台高配的服务器，是这样理解吗？

建议使用此 *** 作方式进行迁移；

在使用Windows Server Backup备份及恢复整个邮箱数据库。可参考如下博文：

>

2 备份完整个邮箱数据库，同样使用windows server Backp对整个Exchange2010服务器进行备份。

3 邮箱数据库，服务器配置备份完毕后。在域控制器里将Exchange计算机帐号重设。

4将新的服务器更改计算机名为同名服务器，并且加入域。

5安装必须的补丁、IIS、控件等。

6重启Exchange服务器，然后插入Exchange光盘，运行命令：setup /m:recoverserver

7恢复完Exchange2010服务器配置后，就将邮箱数据库备份恢复回去即可。

 大概 *** 作就是如此了。详细可在网上搜索相应资料，或留个邮箱我发个文档给你也行。

---