介绍
有许多情况下,您可能需要将数据和操作需求从一个服务器迁移到另一个服务器,您可能需要在新的数据中心实现解决方案,升级到更大的机器,或过渡到新的硬件或新的VPS提供商。
无论你的原因是什么,在从一个系统迁移到另一个系统时,你应该考虑很多不同的因素。如果你不使用 Chef、Puppet 或 Ansible 等配置管理解决方案,就很难获得功能相同的配置。
在本系列的最后一篇文章中,您涵盖了 如何使用 rsync 传输包和其他数据。
步骤 1 – 迁移用户和群组
Linux 包管理器是非常强大和可重复的,通过在上一节教程中迁移您的系统包,您将迁移大部分所需的配置设置,但是,这会忽略一些您可能在旧服务器上手动更改的设置,如用户和组权限。
幸运的是,所有 Linux 用户和组设置都包含在几个文件中,这些文件包括:
- /etc/passwd: 此文件定义用户及其属性. 尽管其名称,但此文件不包含密码信息. 它包括用户名、用户和主要组号、主目目录和默认壳。
- /etc/group: 此文件包含每个用户的实际密码设置。 它应该包含在
passwd文件中定义的每个用户的行,以及他们的密码的哈希和一些密码政策的信息。 - /etc/group: 此文件定义了您系统上可用的每个组。 此文件包括组名称和相关组号,以及任何组成员。
- /etc/shadow: 此文件包含系统上的每个组的行。 它列出了一个
您绝不应该将这些文件直接从一个实时系统复制到另一个系统。在每个系统上创建时,用户和组号自动增加,如果它们不匹配,就会产生冲突。
创建迁移文件
您将创建与上述每个文件相关的新迁移文件,这将使您能够系统地迁移它们,从 `/etc/passwd 开始。
首先,你需要确定正常用户 ID 是否在源系统上从 500 开始计算,或者从 1000 开始计算。大多数现代 Linux 环境开始从 1000 开始计算,以便为系统用户留下更多的空间,但如果你正在从非常旧的系统迁移,它可能会从 500 开始计算。
1[environment second]
2less /etc/passwd
1[secondary_label Output]
2…
3vault:x:997:997::/home/vault:/bin/bash
4stunnel4:x:112:119::/var/run/stunnel4:/usr/sbin/nologin
5sammy:x:1001:1002::/home/sammy:/bin/sh
在这种情况下,它将是1000,因为您的常规用户ID,在输出的第三列,似乎是1000或更大。
使用awk,您可以为您的/etc/passwd文件创建同步文件。本教程中的awk命令将提供为,由于其复杂的语法,但请记住,您可以 了解更多关于使用 awk在另一个教程中。
1[environment second]
2awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > ~/passwd.sync
接下来,您可以使用相同的语法和相同的用户 ID 限制来导出您的 /etc/group 文件:
1[environment second]
2awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > ~/group.sync
要解析 /etc/shadow,您可以使用您的 /etc/passwd 文件中的数据作为输入:
1[environment second]
2awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > ~/shadow.sync
对于 `/etc/gshadow 来说,相同的方法是有效的:
1[environment second]
2awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > ~/gshadow.sync
在测试这些命令并验证它们是否从真实数据创建导出文件后,您可以将它们添加到您从上一本教程中维护的sync.sh脚本中。
1[label `~/sync.sh]
2ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > ~/passwd.sync"
3ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > ~/group.sync"
4ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > ~/shadow.sync"
5ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > ~/gshadow.sync"
6rsync source_server:~/passwd.sync ~/
7rsync source_server:~/group.sync ~/
8rsync source_server:~/shadow.sync ~/
9rsync source_server:~/gshadow.sync ~/
将这些数据导出到目标计算机后,您可以自动将用户和组添加到目标计算机中,但与其他命令不同的是,如果该命令在相同的环境中重新运行,则该命令会创建重复,因此您应该手动执行,而不是将其添加到迁移脚本中。
有一个命令称为新用户,可以从输入文件中添加多个用户,但首先,您需要使用另一个命令awk来从同步文件中删除数字ID:
1awk 'BEGIN { OFS=FS=":"; } {$3=""; $4=""; } { print; }' ~/passwd.sync > ~/passwd.sync.mod
然后你可以将该文件传递给新用户:
1newusers ~/passwd.sync.mod
这将将所有用户从文件添加到本地 /etc/passwd 文件. 它还将自动创建相关的用户组. 您将不得不手动添加与用户无关的其他组到 /etc/group 文件. 使用您的同步文件作为参考点来编辑相应的目标文件。
对于 /etc/shadow 文件,您可以将您的 shadow.sync 文件的第二列复制到新系统中的相关帐户的第二列. 这将将您的帐户的密码转移到新系统。
步骤2 - 将工作转移到新系统
现在您的用户、包和其他数据已从旧系统中传输,还有一个步骤 - 传输每个用户的系统工作和邮件。
<$>[注]
Linux上的 /var/spool 目录正式包含等待某种形式的后续处理的数据。在实践中,这通常包括您配置的任何 cron 工作,以及系统本身处理的任何邮件。
您可以通过为 Spool 目录编写另一个 rsync 命令开始此过程,而spool目录通常包含cron,mail和一些其他日志:
1[environment second]
2ls /var/spool
1[secondary_label Output]
2anacron cron mail plymouth rsyslog
要将邮件目录转移到我们的目标服务器,您可以将另一个rsync命令添加到您的迁移脚本中:
1[label ~/sync.sh]
2rsync -azvP --progress source_server:/var/spool/mail/* /var/spool/mail/
您应该注意的 /var/spool 目录中的另一个目录是 cron 目录. 此目录包含 cron jobs,用于计划任务。
转移你的crontabs使用rsync:
1[label ~/sync.sh]
2rsync -azvP --progress source_server:/var/spool/cron/crontabs/* /var/spool/cron/crontabs/*
这将处理个别用户的cron配置,但它不会捕捉任何系统范围内的cron设置。在/etc目录中,有一个系统范围内的crontab和一些其他包含cron设置的目录。
1[environment second]
2ls /etc/cron*
1[secondary_label Output]
2cron.d
3cron.daily
4cron.hourly
5cron.monthly
6crontab
7cron.weekly
crontab文件包含整个系统的 cron 细节. 其他项目是包含其他 cron 信息的目录. 查看它们并决定是否包含您需要的任何信息。
再一次,使用rsync将相关的cron信息传输到新系统:
1rsync -azvP --progress source_server:/etc/crontab /etc/crontab
例如, Nginx Web 服务器将其配置存储在 `/etc/nginx 中,您应该确保您的迁移脚本捕获了此信息。
一旦你在你的新系统上有你的cron信息,你应该验证它是否工作。做正确的唯一方法是作为每个用户登录,并手动运行每个用户crontab中的命令。
步骤 3 – 测试网站和服务
在此时,您应该完成将命令添加到迁移脚本并传输数据。下一步是开始在新服务器上重新启动所有相关服务。例如,您可以通过运行sudo systemctl restart nginx来重新启动nginx网页服务器,尽管在您在新服务器上安装了 Nginx 包时,这将自动完成。对于任何其他服务,您可能已经 写了自己的单元文件,或通过Docker部署,您应该手动测试重新启动它们。
例如,如果您有一个/data目录,您已通过rsync传输,您可以在源和目标计算机上导航到该目录,并运行du命令来验证其大小:
1cd /data
2du -hs
1[secondary_label Output]
2471M .
如果你的两个系统之间存在差异,你应该调查。
接下来,您可以检查在每个机器上运行的流程. 您可以使用顶部来获得活跃流程的概述:
1top
1[secondary_label Output]
2top - 21:20:33 up 182 days, 22:04, 1 user, load average: 0.00, 0.01, 0.00
3Tasks: 124 total, 3 running, 121 sleeping, 0 stopped, 0 zombie
4%Cpu(s): 1.0 us, 1.0 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
5MiB Mem : 981.3 total, 82.8 free, 517.8 used, 380.7 buff/cache
6MiB Swap: 0.0 total, 0.0 free, 0.0 used. 182.0 avail Mem
7
8 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9 11 root 20 0 0 0 0 I 0.3 0.0 29:45.20 rcu_sched
10 99465 root 20 0 685508 27396 5372 S 0.3 2.7 161:41.83 node /root/hell
11 104207 vault 20 0 837416 236528 128012 S 0.3 23.5 134:53.49 vault
12 175635 root 20 0 11000 3824 3176 R 0.3 0.4 0:00.03 top
13 1 root 20 0 170636 9116 4200 S 0.0 0.9 8:50.40 systemd
14 2 root 20 0 0 0 0 S 0.0 0.0 0:01.04 kthreadd
15 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
16 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
17 . . .
您还可以复制您最初在源机上进行的一些检查,以查看您是否在新机上正确地复制了您的环境。
1netstat -nlp
1[secondary_label Output]
2Active Internet connections (only servers)
3Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
4tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 104207/vault
5tcp 0 0 0.0.0.0:1935 0.0.0.0:* LISTEN 3691671/nginx: mast
6tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3691671/nginx: mast
7tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3691671/nginx: mast
8tcp 0 0 0.0.0.0:1936 0.0.0.0:* LISTEN 197885/stunnel4
9tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 162540/systemd-reso
10tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 129518/sshd: /usr/s
11tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 99465/node /root/he
12tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN 3691671/nginx: mast
13tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3691671/nginx: mast
14tcp 0 0 0.0.0.0:56733 0.0.0.0:* LISTEN 170269/docker-proxy
15tcp6 0 0 :::80 :::* LISTEN 3691671/nginx: mast
16tcp6 0 0 :::22 :::* LISTEN 129518/sshd: /usr/s
17tcp6 0 0 :::443 :::* LISTEN 3691671/nginx: mast
18tcp6 0 0 :::56733 :::* LISTEN 170275/docker-proxy
19udp 0 0 127.0.0.53:53 0.0.0.0:* 162540/systemd-reso
20raw6 0 0 :::58 :::* 7 162524/systemd-netw
21raw6 0 0 :::58 :::* 7 162524/systemd-netw
22Active UNIX domain sockets (only servers)
23Proto RefCnt Flags Type State I-Node PID/Program name Path
24unix 2 [ ACC ] STREAM LISTENING 5313074 1/systemd /run/systemd/userdb/io.systemd.DynamicUser
25unix 2 [ ACC ] SEQPACKET LISTENING 12985 1/systemd /run/udev/control
26unix 2 [ ACC ] STREAM LISTENING 12967 1/systemd /run/lvm/lvmpolld.socket
27unix 2 [ ACC ] STREAM LISTENING 12980 1/systemd /run/systemd/journal/stdout
28unix 2 [ ACC ] STREAM LISTENING 16037236 95187/systemd /run/user/0/systemd/private
29…
您也可以重新运行lsof:
1lsof
1[secondary_label Output]
2COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
3node\x20/ 99465 root 20u IPv4 16046039 0t0 TCP 127.0.0.1:3000 (LISTEN)
4vault 104207 vault 8u IPv4 1134285 0t0 TCP *:8200 (LISTEN)
5sshd 129518 root 3u IPv4 1397496 0t0 TCP *:22 (LISTEN)
6sshd 129518 root 4u IPv6 1397507 0t0 TCP *:22 (LISTEN)
7systemd-r 162540 systemd-resolve 12u IPv4 5313507 0t0 UDP 127.0.0.53:53
8systemd-r 162540 systemd-resolve 13u IPv4 5313508 0t0 TCP 127.0.0.53:53 (LISTEN)
9docker-pr 170269 root 4u IPv4 1700561 0t0 TCP *:56733 (LISTEN)
10docker-pr 170275 root 4u IPv6 1700573 0t0 TCP *:56733 (LISTEN)
11stunnel4 197885 stunnel4 9u IPv4 1917328 0t0 TCP *:1936 (LISTEN)
12sshd 3469804 root 4u IPv4 22246413 0t0 TCP 159.203.102.125:22->154.5.29.188:36756 (ESTABLISHED)
13nginx 3691671 root 7u IPv4 2579911 0t0 TCP *:8080 (LISTEN)
14nginx 3691671 root 8u IPv4 1921506 0t0 TCP *:80 (LISTEN)
15nginx 3691671 root 9u IPv6 1921507 0t0 TCP *:80 (LISTEN)
16nginx 3691671 root 10u IPv6 1921508 0t0 TCP *:443 (LISTEN)
17nginx 3691671 root 11u IPv4 1921509 0t0 TCP *:443 (LISTEN)
18nginx 3691671 root 12u IPv4 2579912 0t0 TCP *:8088 (LISTEN)
19nginx 3691671 root 13u IPv4 2579913 0t0 TCP *:1935 (LISTEN)
20nginx 3691674 www-data 7u IPv4 2579911 0t0 TCP *:8080 (LISTEN)
21nginx 3691674 www-data 8u IPv4 1921506 0t0 TCP *:80 (LISTEN)
22nginx 3691674 www-data 9u IPv6 1921507 0t0 TCP *:80 (LISTEN)
23nginx 3691674 www-data 10u IPv6 1921508 0t0 TCP *:443 (LISTEN)
24nginx 3691674 www-data 11u IPv4 1921509 0t0 TCP *:443 (LISTEN)
25nginx 3691674 www-data 12u IPv4 2579912 0t0 TCP *:8088 (LISTEN)
26nginx 3691674 www-data 13u IPv4 2579913 0t0 TCP *:1935 (LISTEN)
如果您转移了 Web 服务器或面向 Web 的应用程序,您还应该在新服务器上测试您的网站。 根据您的配置,您可能需要迁移您的域名并重新注册 HTTPS 证书,然后才能这样做。
您还需要 迁移您的防火墙规则,这些规则通常包含在 /etc/sysconfig/iptables 和 /etc/sysconfig/ip6tables 中。
在将规则加载到新服务器之前,您应该查看需要更新的任何内容,例如更改的 IP 地址或范围。
第4步:更改 DNS 设置
一旦您在目标服务器上有所有最新数据,并测试了您的网页终端,您可以修改域名的DNS服务器,以指向新服务器。
如果您正在使用 DigitalOcean 的 DNS 服务器,您可以阅读有关 如何配置您的域名。
DNS 更改通常需要几分钟到一个小时的时间来传播到大多数家庭互联网服务提供商. 您的 DNS 更新后,以反映您的更改,您可能需要执行最后一次迁移脚本,以确保仍然会转移到原始服务器的任何错误请求。
结论
您的新服务器现在应该运行,接受请求并处理您以前的服务器上的所有数据,您应该继续密切监控新服务器的任何异常。
迁移不是微不足道的。成功迁移现场服务器的最佳机会是在开始之前尽可能了解您的系统。每一个系统都是不同的,每次你都必须处理新问题。
接下来,你可能想了解有关 配置和部署使用 Ansible 的服务器的信息。