1. 为什么要做安装包备份——先聊聊背景和适用场景用Ubuntu做主力系统的人应该都体会过那种“重装一时爽配环境火葬场”的感觉。我刚接触Linux那会儿系统崩了第一反应就是重装装完系统本身倒不费劲真正让人头疼的是那些年积月累装下来的软件、驱动、依赖库和自定义配置。每次重装完光是把开发环境恢复到能用就得折腾大半天踩过的坑还要再踩一遍。后来我学乖了开始研究系统安装包备份这件事。说白了就是把当前系统里已经下载好的.deb安装包、软件源列表、PPA仓库地址、甚至Snap包这些“家底”统统打包留存。这样做的直接好处有三个一是重装系统后可以离线恢复大部分软件不用再重新下载二是遇到依赖破损、软件源失效的情况能用手头的备份包完成修复三是如果你要在多台机器上部署相同环境备份包就是现成的“环境迁移工具”。可能有朋友会说现在网速快、源又多重新下载不就行了这话在软件源正常、网络通畅的情况下确实没错但现实中总会碰到尴尬场景公司的内网环境不允许随意访问公网软件源某天软件源挂掉或者某个软件在新版本源里被移除了或者你需要的特定版本软件官方仓库早就把链接删了。这些时候一份完整的本地安装包备份就是你的救命稻草。这个方案适合谁我觉得主要三类人一是经常在Ubuntu上折腾开发环境的技术人员二是管理多台Linux服务器的运维同学三是喜欢折腾桌面版Ubuntu的普通用户。这篇文章我会从备份什么、怎么备份、怎么恢复三个维度把我自己的操作流程和踩过的坑一次性说清楚。2. 备份方案选型——先别急着动手理清楚要备份哪些东西2.1 安装包备份的几个常见方案对比Ubuntu下做安装包备份工具和方式其实不少我列出几种主流的方案备份内容恢复方式优点缺点/var/cache/apt/archives目录apt下载的deb包直接拷贝回目录后dpkg -i零成本不需要额外工具只覆盖apt安装的软件不包含源码编译的程序apt-clone软件包列表 缓存deb包apt-clone restore一键恢复自带恢复脚本留存包列表需要单独安装apt-clone工具dpkg-repack已安装软件重新打包为debdpkg -i逐个安装能把配置也打包进去逐包处理较慢手动备份/etc/apt/sources.list等软件源配置手动复制回去简单直接只备份源不备份包本身我实测下来最舒服的组合是apt缓存目录 apt-clone 源列表备份三管齐下。apt缓存解决“手头已有的deb包”问题apt-clone解决“系统里装了哪些包”的清单问题源列表备份解决“重装后从哪里下载”的问题。三者各司其职漏掉任何一个恢复的时候都会有不痛快。2.2 为什么不能只拷贝/var/cache/apt/archives碰到过不少新手听别人说把/var/cache/apt/archives备份一下就行结果恢复的时候发现一大堆依赖缺失。这个目录本身没问题它是apt下载deb包时的默认缓存位置正常情况下会自动保留下载过的安装包。但你需要知道三个事实第一这个目录默认会做清理你用apt clean或者apt autoclean之后缓存包就会被删掉第二它只包含“通过apt下载”的deb包你用源码编译安装的软件、dpkg -i手动装的包、以及pip/npm这类包管理器安装的包统统不在里面第三如果你装某软件时依赖已经存在了那依赖包未必会被下载到这个目录里。所以正确做法是把apt缓存备份作为整个备份方案的一部分而不是全部。真正能精确还原系统软件状态的还得靠apt-clone这种能记录完整包列表的工具。2.3 还有哪些容易被忽略的“隐形成员”除了deb包本身我建议你把以下几类内容一并纳入备份范围/etc/apt/sources.list和/etc/apt/sources.list.d/下的所有源配置文件PPA仓库的key文件通常在/etc/apt/trusted.gpg.d/和/etc/apt/keyrings//var/lib/dpkg/status这个文件记录了所有deb包的管理状态如果用了Snap就是/var/lib/snapd/snaps/目录下的snap包注意snap的备份和deb不是一套逻辑/etc/apt/preferences.d/下的APT偏好配置这部分容易被漏掉后面恢复的时候你会感谢自己当初备份了这些东西。很多“恢复后软件装不上”的疑难杂症根子就在这些被忽略的配置上。3. 实操篇——手把手完成安装包备份3.1 备份前准备确认系统状态和清理工作在动手备份之前有几个准备工作建议先做。用下面命令确认当前系统的版本信息这个信息在恢复时有用不同版本的Ubuntu对应的软件源和依赖版本会有差异lsb_release -a uname -m确认完系统版本后我习惯先做一次系统更新让本地缓存的包列表和已安装软件尽量处于“最新且一致”的状态sudo apt update sudo apt upgrade -y这一步不是必须的但它能保证你备份出来的包列表是干净的不会有“包里记录着旧版本实际系统已升级”这种状态差。更新完系统后建议顺手做一次sudo apt autoremove --purge清理无用依赖减少备份文件的体积。如果有不太干净的包状态先用下面命令修复一下再继续sudo dpkg --configure -a sudo apt install -f这些准备工作不花多少时间但能让后面的备份结果更干净可靠。我见过有人跳过这步直接备份结果备份文件里残留了半截安装状态的记录恢复的时候报错报得莫名其妙。3.2 核心备份操作一备份apt缓存deb包完成准备工作后第一步就是备份apt缓存里的deb安装包。先看一下当前缓存目录占了多大空间du -sh /var/cache/apt/archives如果这个目录基本是空的说明系统下载完安装包之后被清理过了这一层备份能获得的东西很有限。如果里面已经积累了不少deb文件那就直接压缩打包带走sudo mkdir -p /backup/apt-backup sudo cp -r /var/cache/apt/archives/* /backup/apt-backup/这一步我建议用cp而不是mv原因是apt进程可能还在后台运行缓存目录里的文件还在被使用直接移动可能导致apt异常。复制完成后自行检查一下文件数量ls /backup/apt-backup/ | wc -l如果在服务器场景下可能直接打tar包更方便转移sudo tar -czf /backup/apt-cache-backup.tar.gz -C /var/cache/apt/archives .要注意的是这个tar包里包含了partial子目录里面通常是未下载完的临时文件。打包时可以排除它sudo tar -czf /backup/apt-cache-backup.tar.gz --excludepartial -C /var/cache/apt/archives .3.3 核心备份操作二用apt-clone生成包列表备份了deb包缓存还需要把“系统装了哪些包”这个清单记录下来。apt-clone是干这个的正经工具安装它sudo apt install apt-clone然后生成克隆描述文件sudo apt-clone clone /backup/apt-clone-backup/执行完成后会在/backup/apt-clone-backup/目录下生成一个类似apt-clone-系统名-日期.tar.gz的文件。这个文件的内容很丰富除了已安装软件包列表还包括软件源配置、系统基本信息、甚至一些软件包的自动安装标记。如果想看这个备份文件里记录了什么可以解压后查看tar -tzf /backup/apt-clone-backup/apt-clone-ubuntu-*.tar.gz里面会有var/lib/dpkg/status等关键文件这就是恢复时的依据。3.4 核心备份操作三备份软件源配置和密钥apt-clone虽然会带上一部分源配置但为了保险起见我从来都是再单独手动备份一份源配置。原因是我遇到过apt-clone恢复的时候源配置没完全还原的情况尤其是自定义的.list文件和带signed-by参数的第三方源。需要的备份内容包含sudo mkdir -p /backup/sources-backup sudo cp -r /etc/apt/sources.list /etc/apt/sources.list.d /etc/apt/trusted.gpg.d /etc/apt/keyrings /etc/apt/preferences.d /backup/sources-backup/如果某些目录不存在复制时会报错不影响其他目录的复制但最好先确认一下哪些目录存在ls /etc/apt/如果用的是新版Ubuntu22.04及以上源文件通常在/etc/apt/sources.list.d/ubuntu.sources这个格式里也要一并备份。3.5 附加备份Snap、Flatpak、手动安装的程序Ubuntu现在很多软件是通过Snap安装的这部分的备份逻辑跟deb完全不同。Snap包的缓存目录/var/lib/snapd/snaps/里保存的是已经安装的snap文件。直接复制这个目录即可sudo mkdir -p /backup/snap-backup sudo cp -r /var/lib/snapd/snaps/ /backup/snap-backup/但说实话snap的恢复体验不如deb流畅。就算你把snap文件备份了恢复的时候还是需要snapd服务正常运行而且snap有自动更新机制你恢复后它可能立刻自动更新到新版本。所以snap我更建议的做法是备份“已安装snap包的列表”这样重装后按列表重新snap install反而省心snap list /backup/snap-list.txtFlatpak同理flatpak list --app /backup/flatpak-list.txt对于那些通过源码编译安装的程序比如自己编译的nginx、Python备份文件本身意义不大建议把编译时用到的源码包、配置文件和安装路径记录下来。可以把/usr/local/src、/opt下的内容按需打包sudo tar -czf /backup/local-src-backup.tar.gz -C /usr/local/src .3.6 备份文件归档和存储建议上面几步操作完/backup目录下应该有以下内容/backup/ ├── apt-backup/ # apt缓存的deb包 ├── apt-clone-backup/ # apt-clone生成的备份文件 ├── sources-backup/ # 软件源和key配置 ├── snap-backup/ # snap包缓存 ├── snap-list.txt # snap包列表 ├── flatpak-list.txt # flatpak包列表 └── local-src-backup.tar.gz # 源码包备份这些内容不建议只放在系统盘里因为重装系统时系统盘会被格式化放在本机等于白备份。我通常把它们拷贝到移动硬盘或者另一台机器的存储目录也可以用rsync同步到NASsudo rsync -avh /backup/ /mnt/nas/ubuntu-backup/如果备份中包含大量deb包文件体积可能会很可观拷到移动设备前建议先统计下体积du -sh /backup/*压缩率方面deb包本身已经压缩过tar.gz对deb包的体积缩减效果有限不建议为了省空间强行压缩而浪费时间。4. 恢复实操——从备份到可用的完整流程4.1 全新系统下恢复软件源配置恢复操作通常是和系统重装配套的。装好新系统后第一步不是急着装软件而是先把软件源配置恢复回去。将之前备份的sources-backup目录里的文件拷回系统对应位置sudo cp /backup/sources-backup/sources.list /etc/apt/sources.list sudo cp -r /backup/sources-backup/sources.list.d/* /etc/apt/sources.list.d/ sudo cp -r /backup/sources-backup/trusted.gpg.d/* /etc/apt/trusted.gpg.d/ sudo cp -r /backup/sources-backup/keyrings/* /etc/apt/keyrings/如果恢复的源配置里涉及自定义GPG key还需要确认key已经正确导入。可以用这条命令检查当前APT信任的key列表apt-key list注意在新版本Ubuntu里apt-key命令已经提示deprecated了但这只是提醒查看key列表还是可以用的。更规范的方式是直接在/etc/apt/keyrings/目录确认key文件存在。恢复完源配置后执行sudo apt update这时候如果报错十有八九是key不匹配或者源地址访问不了。先不要急着往下走把源的问题解决了再说否则后续恢复会踩连环坑。4.2 用apt-clone一键恢复已安装软件列表源恢复正常后接下来就用apt-clone的备份文件恢复软件包列表。先解压或者直接跑恢复命令sudo apt-clone restore /backup/apt-clone-backup/apt-clone-ubuntu-*.tar.gz执行这个命令apt-clone会根据备份时记录的包列表调用apt从软件源下载并安装所有需要恢复的软件包。这个过程本质上就是批量安装耗时取决于包的数量和网速。这里要特别说明一下apt-clone恢复时的包来源是软件源不是你备份的deb缓存。也就是说如果某个软件在源里已经不在了恢复会报错。这种情况下备份的deb缓存就派上用场了后面会说。如果恢复过程中遇到因为个别包出问题导致整个恢复中止先排查是哪些包的问题必要时从备份清单中排除特定包。apt-clone支持参数sudo apt-clone restore /backup/apt-clone-backup/apt-clone-ubuntu-*.tar.gz --exclude 包名4.3 用备份的deb包做离线安装这是最体现备份价值的场景。如果新系统网络受限或者软件源里已经找不到需要的包那就手动把之前备份的deb包装回去。方式一将备份的deb包复制回apt缓存目录让apt从本地缓存中安装sudo cp /backup/apt-backup/*.deb /var/cache/apt/archives/然后正常用apt安装它会优先使用缓存目录里的deb包不重新下载。方式二直接用dpkg批量安装cd /backup/apt-backup sudo dpkg -i *.deb但dpkg批量安装有个经典问题如果包之间存在依赖关系安装顺序不对会报依赖错误。我踩过这个坑最好的做法是不要用dpkg -i *.deb这种暴力方式而是用下面这个组合cd /backup/apt-backup sudo dpkg -i --force-depends *.deb sudo apt install -f先强制安装忽略部分依赖冲突再用apt install -f修复依赖。这样能解决大部分顺序问题。如果还是有依赖缺失那说明备份的缓存本身就不完整只能通过网络源补充。4.4 恢复Snap和Flatpak软件Snap恢复相对简单前提是snapd服务正常运行sudo apt install snapd如果备份了snap包缓存可以将snap文件复制回缓存目录后手动安装sudo cp /backup/snap-backup/snaps/*.snap /var/lib/snapd/snaps/ sudo snap install /var/lib/snapd/snaps/xxx.snap --dangerous但如果只是备份了snap list列表则按列表逐个安装while read -r name version rev tracking publisher notes; do if [ $name ! Name ] [ $name ! snap list ]; then sudo snap install $name fi done /backup/snap-list.txt这段脚本里跳过标题行和表头实际用的时候注意调整。Flatpak恢复类似while read -r app; do flatpak install -y flathub $app done /backup/flatpak-list.txt4.5 恢复后的检查清单恢复不等于完事装完软件后我习惯按下面这个清单逐项确认dpkg -l确认关键软件包状态是ii正常安装执行which确认主要命令能找到可执行文件逐个启动核心服务确认没报依赖库缺失检查snap list确认snap包状态是active跑一遍自己常用的开发命令比如python --version、gcc --version、node -v这一套检查下来基本上就能确认系统软件环境已经恢复到可用状态了。5. 常见问题与排查技巧实录5.1 apt-clone恢复时报“无法找到软件包”这个我遇到的频率不低原因很直接备份环境里的某个包在恢复环境的软件源里已经不存在了。可能因为源版本变化也可能因为你恢复的是旧备份但新系统换成了更新的Ubuntu版本。排查思路先确认源配置是否正确恢复执行apt update看源是否正常找到报错的具体包名用apt-cache policy 包名查一下源里有没有如果确认源里没有用--exclude排除它如果这个包对你很重要考虑更换第三方源或者添加对应PPA我吃过一次亏备份时系统里有某个第三方内核模块包恢复的时候源里已经找不到了。当时没注意排除了事后来发现某个硬件功能不正常费了不少劲才定位到是这个模块缺失。5.2 dpkg批量安装报依赖错误用dpkg -i *.deb批量安装时经常出现这种提示dpkg: error processing package xxx (--install): dependency problems - leaving unconfigured这很正常因为deb包之间是有依赖关系的*.deb通配符安装时包的顺序是乱序的排在后面的包如果依赖排在前面的包就会暂缓配置。解法我在前面已经提过就是用apt install -f兜底修复。更省事的方案是用gdebi这类工具sudo apt install gdebi-core sudo gdebi xxx.debgdebi会自动解析依赖确保依赖先装好再安装主包体验比dpkg直接装好不少。5.3 工具记录表经常有朋友问你这个备份方案里到底用了哪些命令、哪个阶段用哪个我把核心操作整理成一个速查表方便你对照操作操作目标关键命令输出/产物查看系统版本lsb_release -a uname -m系统版本和架构备份apt缓存包sudo cp -r /var/cache/apt/archives/* /backup/apt-backup/deb包文件集合生成软件包清单sudo apt-clone clone /backup/apt-clone-backup/压缩的apt-clone文件备份源配置sudo cp -r /etc/apt/sources.list /etc/apt/sources.list.d /etc/apt/trusted.gpg.d /backup/sources-backup/源和key配置文件备份snap列表snap list /backup/snap-list.txtsnap包名清单恢复源配置sudo cp 对应文件回/etc/apt对应目录 sudo apt update软件源恢复可访问一键恢复包列表sudo apt-clone restore /backup/apt-clone-backup/apt-clone-ubuntu-*.tar.gz软件包自动重装批量离线安装debcd /backup/apt-backup sudo dpkg -i --force-depends *.deb sudo apt install -f离线包安装完成5.4 备份工具自身的稳定性问题最后聊一个很多人不注意的点备份操作本身也要考虑可靠性。我的经验是做备份的时候不要只跑一次就万事大吉建议留一份备份文件做完整性校验。比如tar包做完后记录一下校验值sha256sum /backup/apt-cache-backup.tar.gz /backup/apt-cache-backup.sha256恢复前先校验sha256sum -c /backup/apt-cache-backup.sha256这个习惯在关键数据备份上尤其重要等恢复时发现压缩包损坏那时候才叫一个绝望。另外apt-clone备份偶尔会碰见权限问题导致clone失败建议恢复操作全程用sudo不要用普通用户执行。我遇到过有些包安装后配置目录被改成普通用户可读直接clone会报权限不足加上sudo基本能避开这类问题。6. 备份的后续扩展——让备份变成可复用的环境部署工具备份做到这一步其实已经算是完整方案了。但如果你愿意再往前走一步备份这件事还可以演变成更强大的工具。一个方向是把备份文件自动化。可以用cron定时执行备份脚本比如每周日凌晨自动备份一次apt缓存和包列表。这样即使平时疏于管理系统状态也能被周期性记录。我写过一个简单的备份脚本核心逻辑就是上面那些命令的封装配合cron执行长期跑下来非常省心#!/bin/bash BACKUP_DIR/backup/auto mkdir -p $BACKUP_DIR cp -r /var/cache/apt/archives/* $BACKUP_DIR/apt-cache/ 2/dev/null apt-clone clone $BACKUP_DIR/apt-clone/ /dev/null 21 cp -r /etc/apt/sources.list /etc/apt/sources.list.d $BACKUP_DIR/sources/ 2/dev/null定时任务加一行0 3 * * 0 /usr/local/bin/apt-backup.sh另一个方向是结合网络安装源做批量部署。备份包列表后可以把它导出成一份可复用的软件清单配合PXE、Ansible这样的工具在十几台机器上批量部署相同环境。这种情况下apt-clone备份的文件是标准的部署依据配合Ansible的apt模块就能把环境复制到任意多台机器上。其实备份的核心价值不在于“备份”这个动作本身而在于它为系统提供了一个可靠的回滚点和快速恢复能力。很多时候你会发现重装系统不是因为系统坏了而是因为环境配置太乱、改不回去了。有了备份在手里你就有底气去尝试各种系统级改动反正随时能把环境拉回来。这种从容感是我觉得最值得推荐的部分。我在实际使用中最大的体会是备份不是服务器运维的专利个人桌面系统同样需要。而且越早开始备份你积累的备份文件就越有价值因为其中包含了你几年使用过程中沉淀下来的软件选型、源配置、环境偏好。这些东西可不好重新“下载”回来。