一、使用Snowball迁移后的文件增量需求
一个典型的NAS迁移场景是使用Snowball将原IDC的大量数据复制到Snowball上，然后通过Snowball交运到AWS云。数据在AWS区域内，会从Snowball中提取出来，保存到S3目标存储桶内。也就是说，Snowball的交付成果是一个S3存储桶。至此Snowball迁移的流程结束。
如果原IDC内的使用场景是NAS，传统应用程序是无法直接访问S3的，因此有两种可能：
- 方案一，对应用程序做改造，应用程序通过调用SDK，直接读写AWS S3，数据不需要在本地EC2上被挂载；此方案主要难度在改造传统应用；
- 方案二，继续使用NAS方式，使用AWS EFS文件系统，可以通过NFS协议挂载到所有EC2，对原有应用程序无感知。
本文的场景是方案2，因此需要从Snowball完成迁移的S3存储桶上将所有文件下载EFS文件服务上。这个时候可以创建一个EC2云服务器，使用NFS协议挂载EFS服务器到 /data 目录，然后通过AWS CLI，执行如下命令：
aws s3 cp --recursive s3://桶名/目录名 /data/dir1 由此完成了Snowball的数据到EFS的过程。注意这个过程非常耗时间，需要提前启动screen虚拟终端，这样SSH断线后可以重新连回来。
此时下一个挑战到来。当使用Snowball迁移大量数据的时候来回邮寄和拷贝需要2周左右，因此这个迁移是个静态迁移。在这两周期间，IDC内的原NAS上数据已经发生了变化，应用系统产生了增量数据，导致Snowball上云后的数据只是基础数据，还需要追加增量。
二、环境和关键假设
本文即按照上述背景和假设，使用Rsync工具，将IDC内的NAS上的增量，通过Rsync工具和网络复制到AWS云上的EC2上，并写入EFS存储，完成增量数据的同步复制。
注意：
- 复制建议通过内部网络，即事先通过专线、SDWAN、Site-to-Site VPN等方式，让原有IDC内的NAS和AWS云上VPC内的EC2可以用内网IP互通，全程流量不暴露在互联网；
- 此同步是单向同步，方向只能从IDC到AWS云上，不能双向同步，不能同时起两个任务来回同步；
- 同步属于周期性操作，需要按一定频率执行，例如每天执行一次；
- 同步时候扫描文件较多，必须使用screen虚拟终端，否则SSH断开后程序不再执行；
- 本方案为了加速在千万文件量级的检查速度，对增量检查定义是只对比文件名和大小，不对比文件内容，不对比属性和时间。由此场景，适合存放上传图片这种一旦写入数据就不会再修改的场景。如果是某些特殊应用，会对一个已经存在的文件反复改写，且改写后恰好文件字节大小1点不差，这种情况就不会被Rsync视为增量了。因此本次迁移脚本增量复制图片类数据是符合的，其他场景请酌情调整参数，增加对比判断增量文件的依据，当然也会大大拉长扫描增量时间；
- 注意对源NAS实施完成备份，对数据保护后再进行同步操作；
- 迁移后不可将源站直接删除，而是应该先离线应用，然后进行完整备份，然后在云上用S3长期保存备份以应对后续合规检查。
本例中，我们使用AWS EC2挂载EFS后作为Server端，将IDC内的虚拟机作为客户端。于是将要在EC2上配置Rsync Server后台进程，在IDC内运行rsync客户端发起同步。同步方向是从IDC到云，发起者的命令是在IDC，AWS云上是服务监听和被动接收者。
三、配置云上EC2作为Rsync服务器
1、安装Rsync
Rsync在几乎所有的Linux系统中是标准包，直接在线安装即可。
Amazon Linux 、CentOS Linux 、Redhat Enterprise Linux （RHEL）方法如下：
yum install rsync -yUbuntu 和其他 Debian Linux 方法如下：
apt-get install rsync -ySuSE Enterprise Linux （SLES）和 OpenSuSE等方法如下：
zypper install rsync至此就装好了Rsync。
2、配置服务器端文件
编辑配置文件 vim /etc/rsyncd.conf ，这个文件在安装好后有默认内容，此时可以完全删除默认内容，替换为以下配置。
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsyncd.lock
log file = /var/log/rsyncd.log
motd file = /etc/rsyncd.Motd
transfer logging = yes
log format = %t %a %m %f %b
syslog facility = local3
[backup]
uid = root
gid = root
port = 873
comment = rsync
use chroot = yes
read only = no
path = /data/
hosts allow = 172.31.31.146/32由于本文是一次性任务方式，就是两个系统点对点的复制和拷贝，因此本文不使用Rsync的密码身份验证机制，而是改为用IP地址白名单，点对点的授权单个IP有权进行同步操作。请务必确认IP地址的精确性。
此外，还需要对本EC2云服务器修改安全规则组，增加TCP协议873端口的放行，同样，在安全规则组上，也只放行单一IP地址，例如在IDC内的NAS的IP地址是172.31.31.146/32，那么则在安全规则组上，只放行这一个IP。
编辑完毕，保存退出。
4、启动和停止进程
以root身份启动，执行如下命令。
rsync --daemon --config=/etc/rsyncd.conf当启动成功后，即便SSH中断，此进程也将继续跑在服务器上。因此，Rsync的服务器端，可以不使用screen。
查看运行中进程执行如下命令。
ps awuxf | grep rsync停止进程采用kill 进程ID的办法，如下命令。
kill 3645停止任务的执行效果如下图。
至此服务器端的配置完成。
三、准备客户端
1、安装和使用
安装方法同服务器端，不用写配置文件了，yum装好后即可运行。另外，建议安装screen虚拟终端，避免网络超时、断线造成任务失败。
yum install screen -y执行screen即可打开虚拟终端。每次网络断开，重新连接到服务器时候，执行screen -x即可attach回到之前的虚拟终端。
2、执行复制
这个增量复制任务将把源服务器上 /home/ec2-user/source/usr 中的新增文件复制到服务器端 /data/usr 目录下。
请务必确认增量要复制的目录已经在目标服务器上指定正确。如果目标服务器rsync的目录错误，目标目录是个空目录不包含以往全量数据，那么rsync会将源服务器上的所有文件100%的从头到尾传输一次。由此将是一个全量复制，而不是增量复制， 传输的数据量非常巨大，文件数量也在千万级，由此会占用大量的时间和带宽。因此启动任务前，请按照如下例子先做好源和目标的关系映射。
例如要做增量的同步的对应关系如下：
- 源服务器 /home/ec2-user/source/usr -> 目标服务器 /data/usr
- 源服务器 /home/ec2-user/source/var -> 目标服务器 /data/var
- 源服务器 /home/ec2-user/source/opt -> 目标服务器 /data/opt
在以上的目标目录中，都已经加载了从Snowball和S3迁移过来的全量数据。现在要开始同步增量文件了。执行如下命令。
rsync -vzrl --size-only /home/ec2-user/source/usr 172.31.31.146::backup以上命令中，前一个地址是源服务器上的数据目录usr，后边的IP是目标服务也就是配置Rsyncd.conf服务的Server IP地址，两个冒号后边的 backup 是目标服务器rsyncd.conf 配置中指定的配置段，其根目录在/data目录。因此backup后边不需要在额外补写目录名称即可。
同步效果如下图，可以看出只有几个增量文件被复制完成。全量数据不会再通过网络传输。
复制usr目录完成后，可以将命令中的源服务器上的usr改成var，即可复制var目录下的增量。同理对待其他目录。
3、验证增量同步效果
验证增量同步效果的办法是可以通过业务层查找最新写入的某个文件，然后分别在源服务器上和目标服务器上确认。之后执行增量同步。同步之后，再去目标服务器上确认增量文件是否存在。
此外还可以使用统计文件总数量的方法验证。此方法比较耗时间，而且只适合业务服务器处于只读状态的停机窗口，即不再写入新数据时候来执行验证。否则业务服务器随时在写入新的源文件，测算文件数量是不准确的。
执行如下命令，在统计当前目录内的文件总数。
ls -lR | grep "^-" | wc -l对源服务器执行结果：总计35382个文件。如下截图。
对目标服务器执行结果：总计35376个文件。如下截图。
以上结果35382大于35376，说明源服务器有一定增量文件写入。
现在按照如上办法执行rsync增量同步。执行后结果如下。
通过以上执行结果，可以看到只有几个增量文件被迅速传输。
随后在目标服务器上查询文件数量，可以看到目标服务器和源服务器文件数量一致，至此增量同步完成。
需要注意的是，当源服务器和目标服务器目录内包含百万到上千万文件时候，对比检查增量文件会比较耗时，出现检查增量时间远超过实际传输增量文件时间的现象。这是正常的。请在源服务器上打开screen虚拟终端后，再发起命令，确保不会断线。
全文完。