Linux服务器基础维护的核心不是花哨的监控面板和高深的内核调优，而是把swap分区、inode计数、日志轮转、时间同步、SSH防护这些看似不起眼的细节伺候到位，服务器才能长期稳如老狗。很多运维新手甚至老手，都在这些细节上栽过跟头，明明配置了却像没配置一样,直到故障发生才追悔莫及。
别等磁盘满了才想起linux服务器磁盘满了处理方法
磁盘空间告急是最常见的故障，但真正让人头疼的是“明明删了文件，空间却没释放”和“磁盘看着没满，系统却不干活了”，前者多是被进程占用的已删除文件,后者大概率是inode耗尽。
swap分区：服务器崩溃前的最后一根稻草
国内云厂商的默认镜像，相当一部分不带swap分区，内存一紧张，内核的OOM Killer就开始乱杀进程，数据库、Java应用往往是第一个受害者，业界专家指出，生产环境务必规划独立swap，哪怕只有内存的一半,也能给系统争取到宝贵的缓冲时间。
操作路径：先用 free -m 看当前swap大小；如果为0，立刻用 fallocate -l 2G /swapfile 创建文件，mkswap /swapfile 格式化，swapon /swapfile 启用，最后写入 /etc/fstab 保证重启生效，定期检查swap使用率，长期超过70%，说明物理内存已经吃紧,该加内存了。
inode耗尽：磁盘有空间，文件却写不进去
这是个经典的隐蔽故障。df -h 显示还有几十G空闲，但应用疯狂报错“No space left on device”，查一下 df -i，发现inode使用率已经100%，大量的小文件、未清理的邮件队列、程序异常产生的临时文件,都会把inode吃干抹净。
排查路径：使用 find / -xdev -type f | wc -l 统计文件总数，再用 for dir in /var/spool/; do echo $dir; find $dir -type f | wc -l; done 锁定重灾区，一次性清理干净，日常维护中，把inode监控加入告警项,比盯着磁盘空间更重要。
文件描述符不够：高并发下的隐形瓶颈
Nginx、Redis这类高并发服务，跑着跑着突然报“too many open files”，多数情况下不是程序出bug，而是操作系统的进程文件描述符限制太低，编辑 /etc/security/limits.conf，添加 soft nofile 65535 和 hard nofile 65535，修改后需要重启进程生效，同时检查系统级限制 sysctl fs.file-max,不够就同步调大。
linux服务器被攻击了怎么办，基础的防线要从登录环节做起
被入侵的服务器，绝大多数是从弱口令和未修补漏洞进去的，与其等被攻击后手忙脚乱,不如先把常规防御动作做全。
SSH防护：别把钥匙直接挂在门锁上
行业共识认为，直接开放SSH的root密码登录，等于告诉扫段脚本“欢迎来爆破”，三步走降低风险：第一，修改 /etc/ssh/sshd_config 中的 PermitRootLogin no，禁止root直连；第二，PasswordAuthentication no 强制走密钥登录；第三，安装fail2ban，监控 /var/log/auth.log，对连续认证失败的IP自动封禁，改完配置记得 systemctl restart sshd，并且保持当前连接不要断开,以防配置语法错误把自己锁在外面。
补丁与内核更新：修漏洞要修到重启这一步
很多运维用yum或apt打了安全补丁，看到提示就以为完事了，内核补丁生效必须重启服务器，你可以用 uname -r 对比当前内核版本和 yum list installed | grep kernel 的版本，不一致就说明还没生效，如果业务不能立刻重启，至少要确认漏洞对应的内核模块已列入黑名单，或者用 sysctl 临时缓解,但这只是权宜之计。
登录后的可疑行为排查
真被入侵了，首要任务是切断攻击路径，而不是急着删文件，先 last -20 查看登录记录，再 ps aux | grep -i '/tmp\|nc\|perl' 排查异常进程，接着用 crontab -l 和 cat /etc/crontab 找后门计划任务，排查期间善用 ss -tunp 看清当前所有网络连接，遇到可疑外联IP,直接封禁。
linux服务器时间不对怎么修改？日志错乱比时间偏差更危险
时间偏差看似小问题，但会造成日志时间轴错乱、HTTPS证书验证失败、Kerberos鉴权崩溃，分布式架构下，多个服务器时间不统一,排查故障时连先后顺序都理不清。
定时任务的PATH陷阱
Crontab里写的脚本，手动执行一切正常，交给cron执行就报“command not found”，原因很简单：cron环境的PATH极其精简，不包含 /usr/local/bin 这类路径，最简单的解决办法是脚本开头用绝对路径，比如把 /usr/bin/python3 或 /usr/local/bin/python3 写死，别用裸露的 python3，同时注意，cron不加载用户的环境变量文件，需要依赖环境变量的脚本,得在脚本内部显式source。
时间同步一致性方案
现在主流是systemd-timesyncd或chrony，注意，ntpdate和chronyd共存会互相打架，先用 timedatectl 查看当前时区和NTP状态，确认Set time zone 正确，使用chrony时，编辑 /etc/chrony.conf 指定国内NTP服务器，systemctl restart chronyd，畸形的时间跳变会让数据库主从同步直接断开，所以同步策略建议用平滑调整,不要一次性大幅跳变。
内核参数改了不生效
修改 /etc/sysctl.conf 后，很多人忘了执行 sysctl -p 加载，更隐蔽的是，有些参数依赖特定内核模块加载后才有对应文件，net.ipv4.ip_forward，正确的检查方式是 sysctl net.ipv4.ip_forward 查看运行时值，确认与配置文件一致，临时改完想持久化，必须写入配置文件再执行加载，double check一下。
系统日志的无上限增长
/var/log/messages 和 journald 日志不清理，可以轻松吃掉几十G磁盘，systemd-journald默认没有严格大小限制，运行一年以上的服务器，/var/log/journal 体积相当可观，设置日志上限，执行 journalctl --vacuum-size=200M 立即回收，并修改 /etc/systemd/journald.conf 中的 SystemMaxUse=200M 持久化。
维护的真相：习惯比技术重要
服务器维护里最贵的操作，不是那些难啃的内核优化,而是每天的基础习惯。
备份不验证等于没备份。 备份脚本跑完，只检查日志里没有报错，从不做恢复演练，真等服务器硬盘挂掉，才夸夸其谈地说有备份，结果恢复时发现备份文件因为磁盘坏道早已损坏，备份恢复演练，一个季度至少真刀真枪做一次,别等到出事才验证。
改配置不备份原文件。 手一抖改错一个参数，服务起不来，又忘了原来的内容是什么，凡是动 /etc 下的文件，先 cp config config.bak.$(date +%F) 留个后手,这是成本最低的保险策略。
登录历史不看。 有空时翻一翻 history，看看有没有自己不认识的命令，尤其是涉及 curl、wget、chmod 的操作,这也是发现入侵痕迹的最直接方式。
linux服务器基础维护高频问题答疑
问：linux服务器磁盘满了但du找不到大文件，是哪里占用了空间？
答：先执行 df -h 确认挂载点，再用 lsof | grep deleted 查找已被删除但仍被进程占用的文件，这类文件无法用du直接看到，需要定位对应进程PID，确认可重启后，杀死进程或重启服务释放空间，同时用 df -i 排除inode耗尽的情况。
问： linux服务器linux被暴力破解过密码后，要重装系统才安全吗？
答：不一定要重装，先断网隔离，清除cron后门和SSH授权密钥，修改所有账号密码，升级受影响软件包，彻底检查 /tmp 目录，如果攻击者拿到了root权限，内网横向移动过的其他机器也要一起排查，重装系统是最终手段,不是首选方案。
问：为什么按网上教程配了swap，重启后就没了？
答：swapon /swapfile 只对当前会话生效，必须在 /etc/fstab 底部添加一行对应配置，确认挂载项和文件路径正确，每次配置完，执行 swapoff -a && swapon -a 验证语法无误，再配合 free -m 确认最终生效结果。
Linux服务器维护的核心，说到底就一句话：别让细节变成事故，把上述每个坑都踩平,服务器自然会回报你长期稳定的运行周期。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/774391.html
