2026年3月10号这天我把手头这套Linux服务器从内核到应用层彻底推倒重建了一遍。项目代号就叫“2026.3.10Linux”说到底这是一个时间节点也是一次“旧账清零”的机会。这篇文章不打算写成一本正经的安装手册而是把我当时怎么设计、怎么选型、怎么配、怎么踩坑的过程完整记录下来给同样需要做系统迁移或者全量重建的朋友一个能直接参考的样板。这套机器跑了好几年累计了无数历史包袱内核版本老旧、磁盘分区当年拍脑袋留得太小、依赖库版本互相打架、还有一堆不知道谁装的乱七八糟的服务。增量修修补补已经没法解决根上的问题只能是“拆了重盖”。如果你现在也面临类似的情况或者单纯想系统性地把Linux这块啃得更扎实这篇文章适合你慢慢读。1. 为什么要在 2026.3.10 做一次 Linux 全量重建1.1 这台机器经历了什么先说背景。这台服务器虽然不是一台特别核心的生产机但上面跑的东西不少几个内部Web服务、一个文件共享、一个定时任务调度还兼职当网关和存储。早年间搭建时比较随意分区就分了一个根分区和一个swap后续扩容全靠加盘挂载。时间一长根分区被日志和临时文件占得满满的docker的overlay2目录还在同一块盘上磁盘满的情况几乎每个月都要手工清理一次。软件层面就更加混乱。这台机器的系统版本停在一个很老的阶段软件源里好多包都已经不再更新安全补丁自然也没有。某些服务为了跑起来当时用过各种“编译安装大法”导致系统llib目录里堆了一堆手动装的库和发行版自带的版本冲突。每次升级包管理器都担心把哪个跑着的服务弄挂。在这种状态下与其继续缝缝补补不如直接来一次全量重建把系统安装、软件部署、配置管理都重新规划一遍把所有东西收拢到“可解释、可审计、可重复部署”的状态。1.2 全量重建前的三个决策重建方案里最核心的是三个决策想清楚这三件事后面基本不会跑偏。第一发行版选什么。旧的这台用的是一套比较老的发行版体系停更了。我这次选的是基于Debian体系的长期支持版原因是它的软件源稳定安全更新周期长文档和社区资料都非常充分。对于这种要稳稳跑几年的服务器追新版本意义不大稳定和通用来得更实在。第二要不要上虚拟化或者容器化。以前这台机器是“裸奔”的什么服务都直接装在系统里互相影响。这次我决定系统层上面跑容器运行时新服务一律容器化。这样每个服务都有自己的文件系统和依赖环境互相隔离升级某一个不影响其他回滚也方便。第三是不是全自动无人值守。我评估了一下规模化需求——以后可能还要再加几台机器如果每一台都靠手工敲命令部署维护成本会高到不可接受。所以这次的基础配置、服务部署、监控、备份全部写成了可重复执行的脚本和配置文件从空机器到可用状态能够在较短时间内部完成。这三点定了整个重建的大方向就清楚了后面所有操作都围绕它们展开。2. 安装与基础系统配置全流程2.1 安装介质与启动参数重装的第一步是制作安装介质。我用一台Windows机器下载了网络安装镜像写入U盘。这里有一个容易踩的坑不要用什么软碟通直接写入ISO很多情况下U盘会无法引导。正确做法是使用专用的写盘工具以raw方式把镜像写入U盘这才符合UEFI启动的预期。启动服务器进入BIOS把启动模式改成UEFI优先关闭CSM兼容模式。这里很多人会忽略导致系统装好以后无法引导。进入安装程序之后语言、区域、键盘布局按需选好网络先不要急着配置保持DHCP。安装程序到分区一步时我选择了手动分区。这一步我建议每个人都认真做不要偷懒用“安装到整个磁盘”的选项。因为后面你需要知道自己每个分区在干什么、未来的扩容怎么做。手动分区的具体方案下一节说。网络安装的一个关键点是软件源。我建议安装时就用国内镜像源如果安装程序默认源在国外网络会很慢甚至会中转。安装基础系统过程中我顺手把SSH服务装上了因为后续要远程操作总不能在机房蹲一天。2.2 磁盘分区与 LVM 这道数学题老机器最大的教训就是分区太小扩容难。这次我直接把分区方案按“能扩尽量扩”的原则来做。实际情况是这样的机器上一共两块物理磁盘一块是SSD另一块是机械盘。SSD这块我全部拿来放系统、程序和容器运行数据机械盘则用来做数据盘。分区表用GPT启动方式采用UEFI。SSD上划分了这几个分区/boot/efi512MBESP引导分区。/boot1GB放内核和引导文件独立出来是为了避免根分区损坏时内核文件跟着遭殃。/50GBXFS文件系统用来装系统本身和常规软件。/var/lib/docker剩下的所有空间XFS文件系统专门给容器存储用。机械盘则直接整盘做LVM物理卷然后划分逻辑卷来挂载数据目录。有人会问为什么根分区只给50G不把整个SSD都给它我给50G是因为系统文件加日志加软件包正常情况下跑几年也就三十四G的用量。把SSD剩下的都给容器存储是因为Docker镜像和容器日志非常吃空间是未来最可能爆掉的地方。根分区爆掉远比存储分区爆掉难处理所以宁可给容器存储留富余。LVM那部分我使用的是默认的ext4文件系统。考虑到这是一块机械盘性能和顺序写入没有太大差异ext4兼容性和扩展性反而更好。划分好物理卷之后创建卷组然后在卷组里建一个逻辑卷作为数据盘挂载点另一个逻辑卷给交换分区。机械盘速度慢交换分区放机械盘上其实是无奈之举但如果没有更好的位置也只能这样。SSD上我没单独划swap因为要优先保证系统和容器的读写。注意分区方案一定要记录成文档。很多人在系统坏了需要救援时根本想不起自己的分区是怎么分的临时用fdisk查询会浪费救援时间。2.3 网络配置、镜像源与应用包管理器选型基础系统装完第一步是固定网络配置。服务器不像笔记本IP地址一定要静态配置好。我在网络配置文件里把网卡设置成静态地址同时设置好网关和DNS。这里有个经验DNS要至少配两个一个主用一个备用不然一个DNS挂掉就会造成域名解析全部超时。接下来换软件源。Debian体系的软件源配置文件在/etc/apt/sources.list和/etc/apt/sources.list.d/下。我把默认源注释掉改成国内镜像源然后执行apt update apt upgrade。这里提醒一下如果机器是生产环境升级系统前先看一下当前环境里有没有跑重要服务特别是数据库这类有状态的程序。我是在重建阶段系统还是全新的所以可以直接升级到当前版本的最新补丁不会影响任何现有业务。包管理器这一块Debian体系就是apt老三件套update更新索引upgrade升级已装包install装新包。有几个小技巧装软件前先用apt search查一遍包名避免装错装好软件后不要随便卸载它依赖的库尽量让系统自己管理依赖。3. 核心服务部署与数据安全落地3.1 容器运行时与 Nginx 反向代理服务部署这一块我采用容器化方案。容器运行时选择的是Docker的社区版虽然现在有替代品但Docker的资料最多迁移成本最低生态也最成熟。安装方式直接从官方源装就可以装完把当前用户加进docker组避免每次敲命令都要sudo。装好后建了一个共享网络让多个容器之间可以通过容器名互相访问。例如Web应用容器叫app数据库容器叫dbapp容器内连数据库时直接连接db端口即可不用关心IP地址变化。对外统一通过Nginx反向代理接入。Nginx这边我用容器方式跑但配置文件挂载到宿主机——这样修改配置后只需要nginx -s reload不需要重新构建容器。配置里设置了HTTP/2、压缩、静态资源缓存同时为几个内部域名分别设置了虚拟主机根据域名把请求转发到不同应用容器的端口。TLS证书这里内网服务用的自签名证书外网服务用了ACME自动申请和续期。需要特别注意的是ACME协议要求服务器必须在80端口完成验证所以申请证书前要确保Nginx的80端口正常开放并保证域名解析到这个IP。3.2 数据库选型与备份还原演练数据库是这台机器上一个非常关键的组件。考虑到内部服务的数据量并不是特别大但要求稳定可靠、备份容易我选择的是PostgreSQL。它的数据一致性做得很扎实备份工具也成熟是Linux服务器上很稳的选择。数据库也是容器部署但数据目录必须用卷挂载到宿主机的LVM数据盘上。容器删除重建都不怕只要数据目录还在数据库就还能恢复。备份方案我做成“两层”一层是逻辑备份用pg_dump导出SQL文件每天凌晨定时执行另一层是物理备份定期对数据库数据目录做文件级快照式复制使用rsync同步到另一块盘上。这样即使逻辑备份有问题物理备份还能兜底。配置备份同样重要Nginx配置、Docker Compose文件、系统网络配置、定时任务列表全部打包存一份。我把这些配置文件放在一个目录里并用Git做版本管理。这样每次修改配置都有历史记录出问题的时候可以很清楚地看到改了什么。数据安全不能只停在“有备份”还原演练必须做。我们模拟了一次“数据目录不小心删除”的场景用备份文件恢复了数据库。第一次演练就发现了一个问题数据库运行状态下直接恢复数据目录会导致文件权限错乱正确做法是先停掉容器再恢复文件然后重启。这个教训写进了操作文档里。4. 系统监控、日志与性能调优4.1 systemd 服务编排和日志治理新系统上所有服务都由systemd管理。虽然很多服务跑在容器里但容器本身的守护进程、以及一些系统级的定时任务还是尽量用systemd service的方式来统一编排。每个服务都写一个unit文件放在/etc/systemd/system/下服务日志统一交给journald。体系多了之后日志文件增长会非常快。我在/etc/systemd/journald.conf里加了SystemMaxUse1G的限定让journald自动轮转和清理日志不会无限制占用磁盘。单个容器服务的stdout日志则由daemon的log-opts配置来限制大小。这里要强调一下日志是排查问题的第一手资料但很多人遇到故障时第一反应是“重启服务”这一重启就把日志里的上下文刷掉了非常可惜。我自己的习惯是看到异常先看journal日志和容器日志确认不是明显原因后再考虑重启。4.2 一套轻量监控脚本监控这一块我没有上比较重的监控软件因为机器规模不大用脚本加系统命令完全够用。我写了一套轻量监控脚本每5分钟跑一次核心监控四个维度CPU、内存、磁盘、网络。CPU使用top或mpstat采集用户态和系统态占用率超过阈值时记录进程快照。内存用free查看可用内存和swap使用情况特别注意内存回收有没有频繁发生。磁盘用df -h查看各分区使用率达到80%时发告警。网络用ss查看连接数用iftop或vnstat统计流量确认没有异常外联。这个脚本的输出写入一个日志文件同时通过简单的消息通知机制把告警发到管理员那里。我用的是内网消息机器人你也可以根据自己的环境接钉钉、企业微信或者邮件。挂了告警之后能提前发现很多潜在问题。有一次磁盘增长异常就是告警先发现的。查下来发现是一个应用容器把调试日志开到了debug级别每天都在写十几个GB的日志。如果没监控这台机器迟早会被日志塞爆。5. 这半年踩过的坑与排查实录5.1 四个典型的故障场景重建完成后的这几个月我陆陆续续遇到了几个比较典型的故障这些坑很有代表性单独拿出来说说。第一个坑是UEFI引导丢失。有一次机房意外断电重启后服务器直接进了shell而不是正常引导系统。排查后发现是引导分区在异常断电后文件系统损坏。修复的办法是使用救援盘进入系统重新挂载/boot/efi然后用efibootmgr重新注册引导项。这个经历提醒我引导分区这种关键目录平时就要有备份和救援文档。第二个坑是apt源更新时报签名错误。原来源里一个第三方软件仓库的GPG公钥过期了导致apt update一直报错。解决办法是重新添加新的公钥并删除废弃仓库配置。这里有个经验不要因为省事就关掉GPG验证GPG验证是软件供应链安全的重要防线一定要保持开启。第三个坑是LVM扩容后没有立即生效。我加了一块新盘扩展卷组之后逻辑卷大小看起来没变。原因是我忘记了resize2fs或xfs_growfs这个关键的扩大文件系统步骤。LVM扩容是“先扩逻辑卷、再扩文件系统”两步走只做第一步是无效的。第四个坑是Nginx的worker进程CPU占用居高不下。一开始以为是流量太大排查后发现是一个应用接口存在死循环每次调用都消耗大量计算资源。用ss确认连接数正常再用top定位到Nginx进程最后抓包发现大量重复的API请求问题根源还是在应用层。这个案例说明很多性能问题表面上在系统层实际上根源在上层应用。5.2 问题排查速查表把上面遇到过的零碎问题整理成一张表方便遇到类似问题时对照处理。现象可能原因排查命令解决方案服务器启动直接进紧急模式/etc/fstab挂载项出错或引导分区损坏journalctl -xb查看启动日志修复分区文件系统并修正fstabapt update报GPG签名错误仓库密钥过期或仓库地址失效apt-get install -f或手动检查sources更新/重新导入公钥删除失效仓库磁盘space不足但实际文件不大日志或容器overlay占空间du -sh /*逐级定位大目录清日志、清理无用镜像和容器LVM扩容后容量未变忘了扩展底层文件系统lvs和df -h对比执行resize2fs或xfs_growfs内存使用率异常高应用内存泄露或页缓存未回收free -h、ps aux --sortrss定位进程检查应用配置网卡流量异常有进程在大量外发数据ss -tp、nethogs或iftop定位进程切断外联这张表只是一个起点。实际排查的时候最重要的是养成看日志的系统习惯先看journalctl再看应用日志最后用系统命令验证推断。不要跳过日志直接重试操作那样会让问题掩盖得越来越深。6. 写在最后的一点体会这套Linux系统从2026年3月10日重建到现在整体运行算得上平稳最大的一次故障也就是那次断电引发的引导问题其余大部分隐患通过监控脚本提前暴露并处理掉了。我个人最大的感受是重建系统这件事三分靠安装七分靠管理。装系统只花了一个晚上但把配置文档、备份策略、监控告警、故障预案补齐前前后后花了将近一周。再分享一个小技巧每次修改系统配置前先拷贝一份原文件到带日期后缀的备份。这个习惯非常小但关键时刻能救命。很多配置文件改动后不会立即报错而是在下一次重启时才爆发。有一点备份回退就是一瞬间的事没有备份你可能得花一晚上查改了什么。如果你也准备把自己的Linux环境来一次彻底整理我的建议是先梳理现有业务和目录结构再做方案选型最后动手。多花一点时间在设计上后面运维会轻松很多。