5同行回答
几个TB的备份数据量不算特别的大，迁移其实和这个备份没有多大的关系，说白了，迁移完了，配上备份继续呗就可以了。
当然也可以使用备份完成所谓的迁移工作。比如以前搞过一个场景：
oracle的数据库6T，数据量也算少了，如果使用停机ftp或者scp等方式肯定很耗时啊，所以当时就是使用备份恢复的方式进行，然后持续的应用归档，当生产机停了，迁移机器应用一下最后的几个归档打开即可，窗口也很短。
至于说备份方面的事，如果对生产库影响较大的话可以考虑搭建一个只读库备份只读也是可以的。
收起曾经做过几个数据库系统的迁移，系统迁移用两种方案做过，一个是DSG，一个就是我们EMC Networker。
对于IDC来说，几TB不算大数据库，迁移本身也简单。DSG的方式是持续抽数复制，优点是不用停机，但缺点也很明显，抽数过程不能中断，一旦中断从头开始。备份软件Networker的方式就是备份恢复，在前天晚上做FULL备份，然后迁移当天在迁移主机上恢复FULL备份（也可以提前做），同时备份生产库的归档到迁移主机上，然后在迁移主机上追归档。迁移当晚，迁移主机上的数据库和生产库数据基本一致了，可能就是几十个归档的差值。迁移时，断开生产库的所有数据库应用链接，把数据库归档全部切出来，备份恢复到迁移主机上追加。剩下的就是DB去检验数据了，部署应用。
除去上面两种，还有存储复制这种方案，也是相对安全的一种迁移，优点是停机时间短，大部分操作可以不中断业务的时候操作，但IO可能会高；缺点也十分明显，要两套存储之间能完美复制（成本）。
这几种方案里，推荐备份软件来做。DSG的这种方式不确定因素太多，要是网络闪断或者延时突变，抽数中断的可能性很大。存储复制的成本相对较高，不过效率也是比较高的一种。备份软件来说，风险最小，成本也低，最重要的一点，容错高。
如果迁移时对数据做保全的话，建议前一天做FULL，后面备份归档即可。FULL备份是在夜间进行，不会耽误生产。归档备份IO小，对数据库也没什么影响。
收起第一次全量，分次增量表，时间增加，量减少。最后一次增量就很轻松了，比如1天的数据，然后切割。当然，需要增量的表，你应该很清楚吧。
收起数据量上TB级别，做迁移时，数据库backup会非常耗时，但是又必不可少，可以采用vgcopy，或者存储级别的复制技术相结合。DB2的话，还有IBM db2hpu做数据迁移的工具，效率是load的好几倍。
收起