介绍
在许多情况下，您可能必须将数据和操作需求从一个服务器移动到另一个服务器。 您可能需要在新的数据中心中实施解决方案，升级到更大的计算机，或转换到新的硬件或新的VPS提供程序。
无论你的原因，当从一个系统迁移到另一个系统时，你应该做许多不同的考虑。 如果您不使用配置管理解决方案（如Chef，Puppet或Ansible）运行，获取功能等效的配置可能会很困难。 您不仅需要传输数据，还需要配置服务以在新计算机上以相同的方式运行。
在我们的上一篇文章中，我们介绍了如何使用rsync传输数据和迁移数据库 。 我们将通过迁移用户，组，邮件，crontabs和其他设置在本文中继续迁移。
迁移用户和组
虽然您的主要关注可能是您的服务和计划，我们还需要注意用户和组。
大多数需要特定用户操作的服务将在安装时创建这些用户和组。 但是，这仍然会留下手动或通过其他方法创建的用户和组。
幸运的是，用户和组的所有信息都包含在几个文件中。 我们需要看的主要文件是：
/ etc / passwd文件 ：这个文件定义了我们的用户和基本属性。 尽管其名称，此文件不再包含任何密码信息。 相反，它关注用户名，用户和主组号，主目录和默认shell。
/ etc / shadow文件 ：此文件包含有关每个用户密码的实际信息。 它应包含每个中定义的用户线
passwd文件中，用自己的密码的哈希和有关密码策略的一些信息。/ etc / group文件 ：这个文件定义您系统上的每个组可用。 基本上，这只包含组名称和关联的组号，以及使用它作为补充组的任何用户名。
在/ etc / gshadow中 ：此文件包含每个组的系统上线。 它基本上列出了组，非组成员可以使用的密码，以访问组，管理员和非管理员的列表。
虽然将这些文件直接从源系统复制到新系统上似乎是一个好主意，但这可能会导致复杂性，因此不推荐。
可能出现的主要问题之一是冲突的组和用户ID号码。 如果创建自己的用户和组的软件以不同的顺序安装在系统之间，则用户和组号可能不同，从而导致冲突。
而是更好地保留这些文件的大多数，只调整我们需要的值。 我们可以通过多种方式做到这一点。
创建迁移文件
无论我们想要使用哪种方法将用户添加到我们的新系统，我们都应该生成应该传输和添加的用户，组等的列表。
已方法流传在Internet上一段时间被提及如下：
我们将创建一个与上述每个文件相关联的文件，我们需要修改。 它们将包含所有适当的传输信息。
首先，弄清楚普通用户和系统用户在您的计算机上的ID限制。 这通常是500或1000，具体取决于您的系统。 如果你有一个普通用户，一个简单的方法，找出是检查/etc/passwd文件，看看那里的普通用户帐户启动：
less /etc/passwd
之后，我们可以使用此号码（第一个常规用户ID号，在第三列中）设置我们的命令的限制。 我们不会将低于此限制的用户或群组导出。 我们还将排除给予用户ID“65534”的“nobody”帐户。
我们可以为我们创建一个同步文件/etc/passwd键入此文件。 替代限＃与您在发现最低的普通用户号码/etc/passwd文件：
awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /root/passwd.sync
之后，我们可以做一个类似的事情来创建一个组同步文件：
awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /root/group.sync
我们可以我们感兴趣的是从我们的范围内使用用户名/etc/passwd文件，以获得我们从影子文件所需的值：
awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > /root/shadow.sync
对于/etc/gshadow的文件，我们会做一个类似的操作：
awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > /root/gshadow.sync
一旦我们知道我们想要运行的命令，我们可以在常规SSH命令之后将它们添加到脚本中，然后将它们关闭，如下所示：
ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /root/passwd.sync"
ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /root/group.sync"
ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > /root/shadow.sync"
ssh 111.222.333.444 "awk -v LIMIT=limit# -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > /root/gshadow.sync"
rsync 111.222.333.444:/root/passwd.sync /root/
rsync 111.222.333.444:/root/group.sync /root/
rsync 111.222.333.444:/root/shadow.sync /root/
rsync 111.222.333.444:/root/gshadow.sync /root/
手动添加用户
如果我们只想注释添加到我们的脚本文件，手动做到这一点， vipw和vigr推荐的命令，因为他们锁定的文件，同时编辑和防范腐败。 您可以通过键入以下内容手动编辑文件：
vipw
传递-s标志编辑相关的影子文件，并通过-g标志编辑组文件。
您可能会试图将文件中的行直接添加到新系统上关联文件的末尾，如下所示：
cat /root/passwd.sync >> /etc/passwd
如果您选择使用此路由，则必须注意，如果新系统上的其他用户已经使用ID，则可能存在ID冲突。
您还可以在从源计算机获取列表后，使用系统上的可用工具添加每个用户名。 该useradd命令可以让你快速创建以匹配源计算机用户帐户：
useradd -s /path/to/shell -m -d /home/username -p password -G supplementary_groups
您可以使用*.sync文件，以供参考，以这种方式添加。
自动添加用户
如果我们想要在我们的文件中脚本化用户和组添加，我们也可以很容易地做到这一点。 我们将在第一次成功运行后评论这些，因为脚本将尝试多次创建用户/组否则。
有一个名为命令newusers ，可以批量从文件添加用户。 这对我们是完美的，但我们要先修改我们的文件，以删除用户和组ID。 该命令将为新系统生成下一个可用的用户和组。
我们可以从passwd文件中剥离组和用户ID，如下所示：
awk 'BEGIN { OFS=FS=":"; } {$3=""; $4=""; } { print; }' /root/passwd.sync > /root/passwd.sync.mod
我们可以这样应用这个新的修改文件：
newusers /root/passwd.sync.mod
这将从文件中添加所有用户到本地/etc/passwd文件。 它还将自动创建关联的用户组。 你将不得不手动必须添加不与用户相关联的额外组/etc/group的文件。 使用迁移文件编辑相应的文件。
为/etc/shadow文件，可以在第二列从复制shadow.sync文件到相关账户的第二列在新的系统中。 这会将您帐户的密码转移到新系统。
您可以尝试脚本化这些更改，但这可能是一个更容易手动执行的情况。 记住在配置用户和组后注释掉任何用户或组线。
将邮件和作业传输到新系统
现在，您的用户从旧系统转移，并且您的用户的主目录由已运行的rsync命令填充，您也可以迁移每个用户的邮件。 我们也想复制cron作业。
我们可以从spool目录的另一个rsync命令开始。 在源系统上的假脱机目录中，我们通常可以看到一些重要的文件：
ls /var/spool
anacron cron mail plymouth rsyslog
我们要将邮件目录传输到目标服务器，因此我们可以向迁移脚本中添加一个类似于rsync的行：
rsync -avz --progress 111.222.333.444:/var/spool/mail/* /var/spool/mail/
在中的另一目录/var/spool ，我们要注意的目录是cron目录。 此目录保存cron和作业，用于调度。 该crontabs目录中包含了个人用户的crontab是用来调度作业。
我们希望保留用户已分配的自动化任务。 我们可以使用另一个rsync命令：
rsync -avz --progress 111.222.333.444:/var/spool/cron/crontabs/* /var/spool/cron/crontabs/*
这将获得单个用户的crontab到我们的新系统。 然而，还有其他crontab，我们需要移动。 内/etc目录下，有一个crontab和一些含有的cron信息等目录。
ls /etc | grep cron
anacrontab
cron.d
cron.daily
cron.hourly
cron.monthly
crontab
cron.weekly
该crontab文件包含系统范围的cron的细节。 其他项目是包含其他cron信息的目录。 查看他们并决定他们是否包含您需要的任何信息。
再次，使用rsync将相关的cron信息传输到新系统。
rsync -avz --progress 111.222.333.444:/etc/crontab /etc/crontab
一旦你有新的系统的cron信息，你应该验证它的工作。 这是一个手动的步骤，所以你必须这样做到底。
正确执行此操作的唯一方法是以每个用户身份登录，并手动运行每个用户的crontab中的命令。 这将确保没有权限问题或缺少文件路径，这将阻止这些命令自动运行时自动失败。
重新启动服务
在迁移脚本结束时，应确保重新启动，重新加载，刷新等所有相应的服务。您需要使用适用于您正在使用的操作系统的任何机制来执行此操作。
例如，如果我们在Ubuntu上迁移LAMP，我们可以通过键入以下命令重新启动重要的进程：
service mysql restart
service apache2 restart
service php5-fpm restart
您可以将这些内容添加到迁移脚本的末尾，它们应按预期运行。
测试站点和服务
在您完成迁移脚本并运行它与所有同步和修改，以及执行所有必要的手动步骤后，您应该测试出您的新系统。
有很多地方你想检查。 在测试时注意任何关联的日志文件，看看是否有任何问题出现。
首先，您需要在传输后测试目录大小。 举例来说，如果你有一个/data ，你已经rsynced分区，你会想要去到该目录对源和目标计算机并运行du命令：
cd /data
du -hs
471M .
验证大小是否接近相同。 原始系统和新系统之间可能存在细微的差异，但它们应该接近。 如果有很大的差异，你应该调查为什么。
接下来，您可以检查在每台计算机上运行的进程。 您可以通过寻找重要信息，这样做ps输出：
ps auxw
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 27024 2844 ? Ss Feb26 0:00 /sbin/init
root 2 0.0 0.0 0 0 ? S Feb26 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S Feb26 0:00 [ksoftirqd/0]
root 4 0.0 0.0 0 0 ? S Feb26 0:00 [kworker/0:0]
root 5 0.0 0.0 0 0 ? S< Feb26 0:00 [kworker/0:0H]
. . .
您还可以复制最初在源计算机上执行的某些检查，以查看是否已在新计算机上模拟环境：
netstat -nlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN 1564/dnsmasq
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 2886/cupsd
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 752/smbd
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 752/
. . .
再次，另一个选择是：
lsof -nPi
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
smbd 752 root 26u IPv6 9705 0t0 TCP *:445 (LISTEN)
smbd 752 root 27u IPv6 9706 0t0 TCP *:139 (LISTEN)
smbd 752 root 28u IPv4 9707 0t0 TCP *:445 (LISTEN)
smbd 752 root 29u IPv4 9708 0t0 TCP *:139 (LISTEN)
. . .
你应该通过你的重要服务的包版本，就像我们在第一篇文章中一样，以验证是否匹配重要包的版本。 这样做的方式将取决于系统。
如果您传输了一个Web服务器或LAMP，您应该在新服务器上测试您的网站。
您可以通过修改您的主机文件（在本地计算机上）轻松地指向您的新服务器，而不是旧的服务器。 然后，您可以测试以查看您的服务器是否正确接受请求，并且所有组件是否以正确的方式一起运行。
修改本地主机文件的方式因使用的操作系统而异。 如果您使用的操作系统具有基于* nix的设计，例如OS X或Linux，则可以修改本地系统上的hosts文件，如下所示：
sudo nano /etc/hosts
在内部，您需要添加一个条目，将您的域名指向新服务器的IP地址，以便您的计算机拦截该请求并将其路由到新位置进行测试。
您可以添加的行可能如下所示：
111.222.333.444 www.domain.com 111.222.333.444 domain.com
添加在您的网站配置过程中使用的所有子域（images.domain.com，files.domain.com等）。 添加主机行后，保存并关闭文件。
如果您使用的是OS X，则需要刷新计算机的主机文件以查看新内容：
sudo lookupd -flushcache
在Linux上，这应该自动工作。
在Windows上，你必须编辑C:\Windows\Wystem32\Drivers\etc\hosts文件作为管理员。 以与我们上面为* nix版本做的相同的方式添加行。
在您的本地工作站上编辑主机文件后，您应该能够通过访问您的域名访问测试服务器。 测试您可能可以做的一切，并确保所有组件可以相互通信并以正确的方式响应。
完成测试后，请记住再次打开hosts文件，并删除您添加的行。
迁移防火墙规则
请记住，您需要将防火墙规则迁移到新服务器。 要了解如何做到这一点，本教程： 如何迁移iptables防火墙规则到新服务器 。
请注意，在将规则加载到新服务器之前，您需要查看需要更新的任何内容，例如更改的IP地址或范围。
更改DNS设置
当您彻底测试新服务器时，请查看您的迁移脚本，并确保没有任何部分可逆转您所做的修改。
然后，再次运行该脚本，以覆盖源服务器的最新数据。
一旦您拥有目标服务器上的所有最新数据，就可以修改域的DNS服务器，使其指向新服务器。 确保对旧服务器IP的每个引用都将替换为新服务器的信息。
如果您正在使用DigitalOcean的DNS服务器，你可以了解如何配置你的域名在这里。
DNS服务器将需要一些时间进行更新。 在所有DNS服务器获得您的新更改后，您可能必须最后运行迁移脚本，以确保仍传输到您的原始服务器的任何散落请求被传输。
仔细查看你的MySQL命令，以确保你不会丢弃或覆盖已写入旧的或新的服务器的数据。
结论
如果一切顺利，您的新服务器应该已经启动并运行，接受请求并处理您以前的服务器上的所有数据。 你应该继续密切监测情况，并留意任何可能出现的异常。
迁移，当正确完成时，不是微不足道的，很多问题可以出来。 成功迁移活动服务器的最佳机会是在开始之前尽可能了解您的系统。 每个系统是不同的，每次，你将不得不解决新的问题。 如果您没有时间排除可能出现的问题，请不要尝试迁移。
