企业官网建设流程全解析

Ubuntu 20.04 系统备份和还原：从新手翻车到恢复如初的完整实操记录

一个搞运维和开发的朋友，最怕听到的一句话是什么？不是“服务器又挂了”，而是“系统起不来了，你之前装的环境还在吗”。我自己的Ubuntu 20.04主力机，也曾因为一次内核升级失败，开机直接卡在initramfs，折腾了一下午才把数据救回来。整个过程让我深刻体会到：在Linux上，备份和还原不是可选项，而是每个靠这台机器吃饭的人的必修课。

这篇博文我会把Ubuntu 20.04的备份和还原讲透，覆盖从最简单但最耗时的tar打包，到整盘级别的dd克隆，再到适合批量部署的Clonezilla再生龙方案。每个方案不仅讲怎么做，还会解释为什么这么做，以及还原过程中那些让你抓狂的引导修复问题。不管你是刚装好Ubuntu想做个安全快照，还是已经遇到系统崩溃急着救数据，这篇文章都能给你一套可以直接照抄的作业。

1. 为什么Ubuntu备份比Windows更需要技术含量

1.2 先搞懂备份的本质：系统状态的可复现性

很多从Windows转过来的朋友，第一反应是用ghost那套思路来处理Linux，拿个PE盘就想进去把整个C盘打包。但诚实地讲，这条路在Ubuntu上行不通。原因很简单：Windows的启动依赖C盘里那一坨引导文件和注册表，ghost备份的是“能把Windows硬件层一起带走的镜像”；而Ubuntu的系统逻辑是“内核+initramfs+根文件系统+Grub引导”，它跟特定硬件绑得不那么死，但跟分区结构、UUID、引导方式（UEFI还是Legacy BIOS）绑定得非常深。

所以备份Ubuntu前，首先得想清楚你要备份的到底是什么状态。按我的实践经验，可以分成三类：一是“系统配置状态”，比如/etc下的网络配置、用户账号、SSH密钥、APT软件源；二是“应用数据状态”，比如Docker容器和镜像、数据库文件、NVIDIA驱动的安装结果；三是“整个磁盘的物理状态”，包括分区表、引导区、EFI分区里的所有字节。

很多教程一上来就让你拿dd整盘克隆，说“什么都能备份”。这话没毛病，但代价是时间、空间和风险。dd是把每一个扇区都原样复制，哪怕那个扇区是空的，对着1TB的硬盘跑一次dd可能要三四个小时，生成一个同样1TB的镜像文件。而如果你只是想“防止系统配置崩了能快速回滚”，那tar打包就够用，十几分钟搞定一个几GB的压缩包，还原起来也快。先把需求想清楚，再选工具，这是我在Ubuntu上折腾几年后最深的体会。

1.2 主流备份方案的一次深度对比

先放一张我从实际使用角度做的对比表，看完基本就能自己选型了：

我个人的选择习惯是：主力开发机上用tar做每周级全备，配合Timeshift做系统更新前的回滚点；遇到要换硬盘或者做虚拟机模板，才上dd或者Clonezilla。这个组合在实际使用中兼顾了速度和可靠性，下面我会把每个方案的实操细节都拆开讲。

2. 动手前的环境检查和备份策略规划

2.1 摸清磁盘布局：你的系统到底是怎么启动的

备份之前，第一件事不是急着敲命令，而是搞清楚这台Ubuntu 20.04的底细。我习惯用一根Ubuntu Live U盘启动到体验环境，然后执行以下三组命令来摸清磁盘布局。

首先是查看全盘分区表：

sudo fdisk -l

这个命令会列出你机器上所有磁盘及其分区。重点看两点：磁盘的扇区大小、分区表类型（gpt还是dos）。如果显示的是Disklabel type: gpt，那说明你的系统是UEFI+GPT模式；如果显示dos或者Disklabel type: dos，说明是传统的Legacy BIOS+MBR。这两种模式的引导修复方式完全不同：UEFI需要EFI分区里有.efi引导文件，Legacy需要MBR里写引导代码。很多还原后“开机黑屏”或“找不到引导设备”的案例，根源就是没区分这一点。

第二步是查看文件系统挂载情况：

lsblk -f

lsblk -f会列出所有块设备的文件系统类型和UUID。注意看有没有一个FAT32格式、通常几百MB的分区挂载在/boot/efi下，这就是UEFI引导的关键。如果这台机器是双系统（Windows+Ubuntu），EFI分区里还会同时存在微软和Ubuntu的引导文件，备份还原时不要把整个EFI分区无脑格式化。

第三步是查看当前的引导模式：

efibootmgr -v

如果输出里能看到BootCurrent之类的信息，说明当前是UEFI模式。如果提示EFI variables are not supported，说明你是Legacy BIOS模式。这个区别直接决定了后面还原引导时的命令和步骤。

2.2 理清“必须备份”和“可以丢弃”的内容

Ubuntu的文件系统是树状的，但并非所有目录都值得备份。我总结了一套“精简原则”，在打包系统时能省下不少时间和空间。

必须备份的内容包括：

• /etc：整个系统配置的核心，网络配置（Netplan文件）、用户组信息、APT源列表、系统环境变量全在这里。备份了这个目录，重装后基本能恢复八九成的系统配置。
• /home：用户目录，里面有你所有的文档、下载、项目代码、隐藏配置文件（.bashrc、.config等）。很多人的劳动成果全在这里，丢了这个等于白备份。
• /root：root用户的目录，虽然平时用得少，但有人的脚本和SSH密钥放在这里。
• /var/lib/docker：如果你用Docker，这里存着所有镜像、容器和卷。Ubuntu上装Docker容易，但重新拉镜像和重建容器的成本很高。
• /usr/local：很多手动编译安装的软件默认装在这里，比如NVIDIA驱动、自行编译的OpenCV等，重装起来特别麻烦。

明确不用备份的内容：

• /proc、/sys、/dev、/run：这些都是虚拟文件系统或内存文件系统，每次开机动态生成，备份它们除了浪费空间没有任何意义。
• /tmp、/var/tmp：临时文件，没备份价值。
• /var/cache/apt/archives：APT下载的deb安装包缓存，删了顶多以后下载慢一点，不值得占用备份空间。
• /swapfile或交换分区：交换文件就像虚拟内存的存放地，里面全是不重要的临时数据，备份它纯粹徒增体积。

把这些目录记下来，后面的tar打包命令里会用--exclude参数把它们排除掉。每次备份前，我也会顺手用du -sh估算一下所有要备份目录加起来有多大，好预估需要准备多大容量的备份介质。我一般是备份到外接移动硬盘或者另一块独立的数据盘，不建议备份到本机同一块物理磁盘的另一个分区——一旦整块盘挂了，备份也跟着没了。

3. Ubuntu 20.04的备份实操：三种方案手把手演示

3.1 方案一：tar文件级备份，日常恢复效率最高的选择

tar是Linux里最经典的归档工具，它本身不做压缩，但可以通过参数调用gzip或其他压缩算法。Ubuntu 20.04系统备份最主流的做法就是用tar带-cvpzf参数打包整个根文件系统，同时排除不需要的目录。

我的备份命令通常长这样：

sudo tar -cvpzf /mnt/backup/ubuntu_20.04_system_$(date +%Y%m%d).tar.gz \ --exclude=/proc \ --exclude=/sys \ --exclude=/dev \ --exclude=/run \ --exclude=/tmp \ --exclude=/mnt \ --exclude=/media \ --exclude=/lost+found \ --exclude=/var/cache/apt/archives \ --exclude=/swapfile \ --one-file-system \ /

解释一下几个关键参数，如果你用过tar做简单打包，可能对-cvpzf比较眼熟，但其中每个字母都值得细说：

• -c表示创建归档，-v是显示详情（第一次备份时开着可以看到过程，以后嫌吵可以去掉），-p表示保留权限属性，这非常关键。很多新手还原后出现文件无法访问、服务起不来的问题，就是因为打包时丢了权限位。
• -z表示用gzip压缩，如果你不怕体积大想追求速度，可以改成-J（xz压缩）或者干脆不加压缩参数。但xz压缩在小内存机器上很吃CPU，我一般还是用gzip。
• -f后面紧跟归档文件路径，注意-f后面的路径要在所有参数的最后，因为tar会把-f后面的第一个字符串当作文件名。
• --one-file-system这个参数容易被忽略，但非常有用。它会告诉tar不要跨越文件系统边界，避免把挂载在当前目录下的其他磁盘分区也备份进去。比如你把数据盘挂载到了/data，如果不加这个参数，tar会把/data里的内容也打包进去，导致备份体积爆炸。

备份目标路径/mnt/backup是我手动挂载的外部存储设备。这里强调一点：备份文件不要放在要备份的那个磁盘上，否则就跟“给房子刷漆时人站在房子里”一样，永远有丢的风险。这个注意事项几乎是所有备份事故的共因。

等备份跑完，我会顺手做两个验证动作。第一，看压缩包大小是否在合理范围内；第二，用tar -tzf 备份文件 | head -20随机列出压缩包内容，确认根目录、/etc、/home这些关键路径确实打进去了。如果哪天系统出了问题，这个包就是你重建家园的种子。

3.2 方案二：dd整盘克隆，适合换硬盘和虚拟机快照场景

对于“要求完整还原、一个字节都不能差”的场景，tar就力不从心了，因为tar只能备份已挂载的、文件系统可见的内容。而dd是把整个块设备从第一个扇区到最后一个扇区逐个复制，它能帮你保留MBR/GPT分区表、EFI系统分区、隐藏的保留分区，甚至连文件系统里的“空洞”都原样搬走。

dd的基本用法是：

sudo dd if=/dev/sda of=/mnt/backup/disk_sda.img bs=64M status=progress conv=sync,noerror

参数含义：

• if是输入文件，在这个场景下就是你要备份的整个磁盘，比如/dev/sda。
• of是输出文件，可以是另一个磁盘上的镜像文件，也可以是另一块裸盘（比如/dev/sdb，这就是俗称的“硬盘对拷”）。
• bs是一次读写的块大小。设成64M甚至128M能显著提高吞吐量，因为每次读写的数据块越大，系统调用的开销占比就越低。但别贪大，实测下来64M是性能和内存占用比较平衡的取值。
• status=progress会显示实时的拷贝进度，不然dd默认是“闷声干活”，跑几个小时你都不知道它动没动。
• conv=sync,noerror的作用是遇到读取错误时填充零而不是直接中断。对整盘备份来说，宁可是一个“不完美但完整”的镜像，也不要在中途直接停下来。

用dd克隆单个分区也类似：

sudo dd if=/dev/sda1 of=/mnt/backup/efi_partition.img bs=64M status=progress

在VMware虚拟机里装好Ubuntu后，很多人习惯直接给虚拟机做快照，其实dd在这种场景下也很香——你把整个虚拟磁盘dd成一个镜像文件，将来就算虚拟机的快照崩了，也能用一个慢速但绝对可靠的原始镜像把人捞回来。热词里搜“vmware虚拟机安装ubuntu”的人特别多，我的建议是：虚拟机里做系统测试时，先用dd把系统盘克隆到本地，再随便折腾，反正有后悔药。

3.3 方案三：Clonezilla再生龙，物理机和批量部署的救星

tar和dd都是命令行工具，对不熟悉终端的用户不够友好。如果你更习惯“选择菜单、下一步”的操作方式，那Clonezilla（国内常叫“再生龙”）会更适合你。它是一个基于Parted Magic和DRBL的轻量级Linux发行版，做成启动U盘后，开机从U盘启动就能进入图形化菜单操作。

Clonezilla的核心优势有两点：一是文件系统感知，它认出ext4、xfs、NTFS后会只备份实际使用的数据块，配合压缩算法，生成的镜像体积可能只有dd的十分之一；二是对UEFI+GPT的支持非常完善，能自动处理EFI分区和Grub引导的恢复。

用Clonezilla备份系统的基本流程：

1. 先从官网下载Clonezilla的ISO镜像，用启动盘制作工具（比如balenaEtcher）写入U盘。
2. 目标机器从U盘启动，选择Clonezilla live (Default settings)。
3. 依次选择语言、键盘布局，进入模式选择菜单。日常备份通常选device-image（设备到镜像），也就是把磁盘或分区备份成一个镜像文件。
4. 选择镜像文件保存位置，这一步很关键——不要选“本机硬盘”里那个正在被备份的系统盘，而是选外接存储设备或网络共享。
5. 选择备份模式。新手我一般推荐beginner（初学者模式），选项少、安全。想精细控制的高级用户选expert模式，可以自定义压缩率、扇区对齐策略等。
6. 选择要备份的来源：整盘备份选sda，分区备份选sda1这样的分区名。
7. 最后确认操作，Clonezilla会列出即将执行的命令，比如ocs-sr -q2 -c -j2 -z1p -i 2000 -p true savedisk 20250322_backup sda，这类命令其实本质就是调用Partclone去复制分区，确认无误后回车开始。

克隆结束后，把U盘拔掉再开机，系统应该还是原来的样子。Clonezilla是我给实体服务器做全备的首选，镜像文件可管理性好，还原速度也快。但很多网友反馈“再生龙还原后启动不了”，这通常不是Clonezilla的锅，而是还原后Ubuntu的Grub引导没有正确重置到EFI分区。这个问题的解决办法我放在第4章专门讲。

4. 还原全流程：从镜像到你能正常开机

4.1 tar备份还原：重装系统后把配置和数据接回来

tar备份的还原场景跟dd不太一样，它更适合这样的情形：系统彻底崩了，但你有Live U盘，能启动到一个临时的Ubuntu环境；你的备份包放在外接硬盘里；然后你的计划是先装一个最小化Ubuntu 20.04到目标磁盘，再把备份包解压覆盖回去。

具体步骤：

第一步，用Live U盘启动，打开终端，确认目标磁盘的设备名：

sudo lsblk -f

假设目标磁盘是/dev/sda，系统分区是/dev/sda2，EFI分区是/dev/sda1。没有分区的话可以用gparted或者fdisk手动创建，这里假设你已经用安装器把基础系统装好了，此时目标盘上应该是空系统。

第二步，把系统根分区挂载到一个临时目录：

sudo mkdir -p /mnt/ubuntu sudo mount /dev/sda2 /mnt/ubuntu

第三步，解压备份包到根分区。这一步是整个还原过程的核心，也是最容易出问题的地方。务必注意解压时需要保留权限和所有属性，并且把备份包里的内容解压到/mnt/ubuntu这个挂载点下，而不是解压到Live环境本身的根目录：

sudo tar -xvzpf /media/ubuntu/backup/ubuntu_20.04_system_20250322.tar.gz -C /mnt/ubuntu

关键参数是-x（解压）、-v（显示详情）、-z（gzip解压）、-p（保留权限）、-f（指定文件），最后用-C指定解压目标目录。这里缺少-p的话，所有系统文件的权限都会乱掉，还原后连sudo都用不了。

第四步，挂载虚拟文件系统并chroot进入目标系统，重新生成引导。这一步对UEFI模式尤其重要，命令序列如下：

sudo mount --bind /dev /mnt/ubuntu/dev sudo mount --bind /proc /mnt/ubuntu/proc sudo mount --bind /sys /mnt/ubuntu/sys sudo mount --bind /run /mnt/ubuntu/run sudo mount /dev/sda1 /mnt/ubuntu/boot/efi sudo chroot /mnt/ubuntu

进入chroot环境后，先确认当前系统识别到的设备：

lsblk -f df -h

然后查看Grub的配置文件是否存在，最后重新生成引导：

update-grub grub-install /dev/sda

grub-install这个命令会把Grub引导程序写入磁盘的MBR或EFI引导条目（取决于你是Legacy还是UEFI模式）。如果你是UEFI模式，grub-install还会自动在/boot/efi里写入或更新EFI引导文件。这就是为什么第四步必须先挂载EFI分区到/mnt/ubuntu/boot/efi再chroot——不然grub-install不知道UEFI固件该去哪找引导文件。

退出chroot、重启之前，别急着拔U盘。用fdisk -l再看一眼分区结构是否正常，确认备份包解压后/etc/fstab里记录的UUID跟当前磁盘分区的UUID对得上。因为备份里的fstab记录的是备份时系统的UUID，如果你换了新硬盘或者分区有调整，UUID就会对不上，系统启动时找不到根分区，直接掉进initramfs。遇到这种情况，可以在chroot里执行blkid查到实际UUID，再用nano /mnt/ubuntu/etc/fstab改回来。

4.2 dd镜像还原和Clonezilla还原后的引导修复

dd镜像的还原则简单粗暴得多。你之前用dd备份了整盘镜像disk_sda.img，现在要把一块新硬盘还原成一样的状态，直接执行：

sudo dd if=/mnt/backup/disk_sda.img of=/dev/sda bs=64M status=progress

dd的还原不需要先分区，因为它连分区表一起写进去了。整个流程没有技术难度，难度在风险评估：of写错盘符的后果是毁灭性的，会直接抹掉目标盘里的所有数据。所以我每次执行这种命令前，都会执行三遍lsblk和fdisk -l，反复确认目标盘是空盘或确认可以覆盖。

Clonezilla的还原也类似，启动到Clonezilla后选择device-image->restoredisk，选源镜像再选目标磁盘，一路确认就完事。Clonezilla还原后启动不了的经典场景我处理过好几次，现象是开机后直接卡在品牌Logo或者直接进入BIOS设置界面，根本看不到Grub菜单。原因是还原时没有把UEFI的启动条目写进NVRAM，或者写进去的条目路径不对。

这种情况下，最快的修复办法是用Ubuntu Live U盘重新启动，按第4.1节的步骤挂载根分区和EFI分区，然后执行：

sudo mount --bind /dev /mnt/ubuntu/dev sudo mount --bind /proc /mnt/ubuntu/proc sudo mount --bind /sys /mnt/ubuntu/sys sudo mount --bind /run /mnt/ubuntu/run sudo mount /dev/sda1 /mnt/ubuntu/boot/efi sudo chroot /mnt/ubuntu apt install --reinstall grub-efi-amd64 grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu update-grub

这里的核心是把grub-efi-amd64包重新装一遍，然后用grub-install显式指定EFI目录和启动项ID，最后执行update-grub重新扫描内核和系统条目。做完之后再重启，基本就能从UEFI固件里看到Ubuntu的启动项了。

4.3 还原后不能忽略的检查清单

还原只是“能开机”的前置条件，不代表系统已经完全恢复如初。我有几次还原后看似成功，一进系统才发现网络没配置、Docker起不来、NVIDIA驱动没装上，折腾半天比重装还累。所以还原完成后，不要着急庆祝，按这个顺序检查一遍：

先看系统关键服务状态：

systemctl --failed

这条命令会列出当前所有启动失败的服务。如果出现failed状态的服务，针对性地查看日志，比如journalctl -u docker.service -n 50排查Docker没起来的原因。

然后检查网络配置：

ip a ip route show

Ubuntu 20.04用Netplan管理网络，还原后如果发现没有IP，检查/etc/netplan/*.yaml是否存在且内容正确。Netplan里记录的网卡名称可能跟新环境下不一致，比如之前是ens33现在是enp0s3，这种时候要么修改yaml里的网卡名，要么用netplan generate重新生成应用。

最后检查数据完整性，这部分靠个人需求定制了。我至少会验证/home下的关键项目代码能否正常编译、数据库服务能否正常启动、Docker容器列表是否恢复：

docker ps -a

如果之前有NVIDIA显卡驱动，还可以跑一下nvidia-smi确认驱动和CUDA版本能正常输出。

5. 常见故障排查实录和避坑经验

5.1 一份拿来即用的Ubuntu备份还原问题定位表

这些年我处理过不少备份还原故障，也参考过大量社区里的求助帖，把最常见的问题汇总成了一张表。你遇到问题时可以先对号入座，省得从零开始排查。

5.2 我踩过的坑：三个真实的备份事故复盘

第一个坑，是tar备份时没有加--one-file-system。那时候我把一块数据盘挂载到了/data，结果数据盘里正好有个几TB的大目录，tar打包时完全不设防，把挂载点下的整个数据盘全卷进去了，备份跑了几个小时还没结束，最后把我移动硬盘的空间彻底塞爆。这个体验让我给所有朋友讲备份时都会强调：做系统备份之前，先看看你系统里挂载了哪些额外的文件系统，该排除的目录一个都不能漏。

第二个坑，是dd的时候把of写反了。那段时间我在实验室帮同事迁移磁盘，原本是想把旧盘克隆到新盘，结果脑子一热，if和of写反了，直接把旧盘当成了目标盘。幸亏当时那块旧盘上已经没有重要数据，不过那一瞬间的冷汗够我记一辈子。后来我给自己立了一个规矩：执行dd这种破坏性命令之前，先echo把命令打印到屏幕上，盯一眼确认无误再回车，绝不凭肌肉记忆复制粘贴。

第三个坑，是UEFI模式下tar还原后忘了挂载EFI分区，直接chroot进去执行update-grub。结果grub-install报了一堆错，系统重启后直接进BIOS。我开始以为是备份包的问题，后来才发现是EFI分区没挂载，导致grub-install把引导写到了根分区而不是EFI分区，UEFI固件根本找不到启动文件。从那以后，我的还原流程里把“挂载EFI分区”写在了chroot之前，并且会检查ls /mnt/ubuntu/boot/efi/EFI/ubuntu/里是否生成了grubx64.efi文件。

6. 最后分享一点关于备份习惯的个人体会

做了这么多年Linux系统的备份还原，我的总结是：工具本身并不复杂，难的是坚持和预案。tar、dd、Clonezilla这三种工具我都推荐你提前在虚拟机里练一遍，哪怕只是备份一个几百兆的测试系统，也要从头到尾把“备份-还原-修复引导-验证”这个流程跑通。真到了系统崩的那天，你才能心不慌手不抖地操作。

我个人的经验是，备份这件事要跟“写代码”一样形成肌肉记忆：系统装好后做一次全盘克隆，之后每周做一次tar增量备份，每次升级内核、装驱动、改大版本配置之前，都先花五分钟做个Timeshift快照。这个习惯帮我无数次从“手贱把系统玩坏”的边缘救回来。备份文件也别忘了定期做校验，我一般会在备份完顺手生成一个SHA256校验文件存到备份目录里，还原之后用它来验证备份包的完整性。

希望这篇Ubuntu 20.04备份和还原的实操分享，能让你少走一些弯路。如果你在备份还原中还有别的坑，欢迎交流，毕竟这些经验都是拿时间换来的。