Linux服务器基础维护中，绝大部分宕机和被入侵事故，根源不是操作复杂，而是文件权限、日志轮转、时间同步这类小细节被长期忽视。 把下面这些点逐个排查一遍，比装任何付费工具都管用。
文件系统维护里藏得最深的三个坑
inode耗尽比磁盘满更致命
很多人习惯用df -h看磁盘，却很少留意df -i的输出，Linux系统里，磁盘空间和inode数量是两套独立资源，一旦inode耗尽，服务器会提示“No space left on device”，但df -h看着还有几十G空闲，这类问题常见于邮件服务器、消息队列、定时任务脚本疯狂生成小文件的场景。
排查方法：执行df -i，确认已用百分比是否超过90%，找出具体元凶，用for i in /; do echo $i; find $i | wc -l; done逐层定位，或者用find / -xdev -printf '%hn' | sort | uniq -c | sort -k1 -rn | head统计哪个目录文件数量最多，多数情况下，是/tmp、/var/spool或某个应用日志目录里堆积了上百万个碎片文件。
止损方案：清空对应目录后，把find /tmp -type f -mtime +1 -delete这类命令加入crontab，让系统每周自动清理一次，注意，/tmp下如果跑着服务，千万别一刀切全删，按修改时间逐批处理最稳妥。
权限检查只盯着755还是不够
常规做法是chmod 755和chown root:root，但有一个细节很多人会漏掉SUID权限位，一个带SUID的文件，用户执行时会临时拥有文件属主的权限，如果属主是root，就等于给任何执行者一把root权限的钥匙，排查方法很简单，一条命令：
find / -perm -4000 -type f 2>/dev/null若发现/usr/bin/passwd这类系统自带文件没问题，但出现/tmp或/home下的陌生SUID文件，基本可以断定服务器已经被上传过Webshell或者入侵工具，处理方式：chmod -s /path/to/file去掉位，再溯源文件是怎么进去的。
挂载参数少写一个noexec
数据盘挂载时,不少人只关注rw和defaults，没想过加上noexec、nosuid、nodev，如果/tmp或/var/tmp这类用户可写目录没禁用执行权限，攻击者上传的恶意脚本就能直接运行。
推荐挂载写法（以/data为例）：
- 普通目录：
defaults,noatime -
用户可写目录（如上传目录）：
defaults,noexec,nosuid,nodev,noatime - 数据库数据目录：
defaults,noatime,nobarrier（取决于文件系统类型，ext4和xfs稍有差异）
安全配置中容易被忽视的细节
SSH配置只改端口不彻底
多数人知道改SSH端口、禁用root登录，但有一个反直觉的细节：修改端口后，如果Port行没放在#Port 22之上覆盖掉默认配置，或者没有调整SELinux的ssh端口策略，重启sshd服务直接就起不来了，业内专家指出，这类“自己把自己关在门外”的操作，在服务器维护事故里占比相当可观。
安全加固至少做到这几条：
PermitRootLogin no，日常用普通用户加sudoPasswordAuthentication no，只用密钥登录（前提是密钥已妥善配置）MaxAuthTries 3，防止暴力破解AllowUsers指定可登录用户白名单- 别忘了
Protocol 2，SSHv1早已淘汰
防火墙规则有顺序上的门道
firewalld和iptables的规则顺序就是一切。iptables是自上而下匹配的，如果顶部有一条ACCEPT放行所有流量，底部再写DROP规则等于白写，实际维护中，最常见的问题是在规则追加时用了-A而不是-I插到顶部，导致新规则永远排在了放行规则后面。
调试命令推荐：
iptables -L -n --line-numbers看每条规则的序号,若设了默认策略DROP，那就先把22、80、443这些端口的放行规则写好，再执行service iptables save固化，但凡改动防火墙，都建议开一个临时会话窗口保持ssh连接，规则出错还能回滚，这是最实在的保命操作。
定时任务里藏着挖矿脚本
crontab -l你看的是自己用户的计划任务，但/etc/cron.d/、/var/spool/cron/、/etc/crontab这些地方也可能有别人塞进去的条目，很多服务器上马，就是靠一个带web权限的进程写入了计划任务。
完整检查思路：
- 查看
/etc/crontab和/etc/cron./目录下的文件 cat /etc/cron.d/逐一确认内容- 用
ls -la /var/spool/cron/看有没有非预期用户的cron文件 - 留意路径里带
/tmp、/dev/shm或随机字符串的执行命令
性能与日志的记录盲区
日志轮转配置没写对触发条件
logrotate是Linux自带的日志管家，默认每天轮转一次，但有几个细节容易被忽略：一是copytruncate选项的取舍，文件很大时用copytruncate避免重启应用服务，但可能丢掉少量日志；二是compress选项可以压缩归档，能省不少磁盘，真正容易出问题的，是某些应用会自己持有文件句柄，logrotate如果不配copytruncate，老日志删不掉，新日志写不进，应用运行一段时间就开始异常。
一个稳妥的nginx日志轮转示例：
/var/log/nginx/.log {
daily
rotate 30
compress
missingok
notifempty
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript
}注意kill -USR1的作用是让nginx重新打开日志文件，这个信号不能少，否则日志一直在旧文件里累积。
时间同步的偏移量会静默放大
服务器时间不同步的隐患在于,它不是立刻爆发的，而是慢慢侵蚀系统，日志时间错乱影响排查故障的定位，而Kerberos认证、SSL证书校验、数据库主从复制的时间戳逻辑，都强依赖准确时间，不少运维排查主从延迟时，半天找不到原因，结果一对比时间，两台机器差了五分钟。
维护建议：
- 统一使用
chrony替代老旧的ntpd，配置更简单，同步精度更高 /etc/chrony.conf里配置多个NTP服务器，pool 2.centos.pool.ntp.org iburst- 用
chronyc sources -v验证同步状态，看到^标记才算锁定成功
内存检查只看free是不够的
free -h显示的available字段在较新内核里才准确反映可分配内存，但很多人还停留在看used列后来判断内存紧张，Linux会把空闲内存用作页缓存，这部分随时可以释放给应用，不算真正的“用完”。
真正需要警惕的是Swap使用率和内存碎片化。vmstat 1连续观察几秒，若si和so（swap写入和读取）不停跳动，说明物理内存已经吃紧，应用开始用磁盘做交换了，更进一步的排查用cat /proc/meminfo关注CommitLimit和Committed_AS，这两个值能体现系统是否还在安全水位内。
备份恢复里的自欺欺人
备份文件可执行权限必须清除
备份脚本把网站文件压缩打包,顺手放在/backup目录，这本身没问题，问题在于，如果备份命令用的是tar或zip，而目录结构里包含一些原本就有执行权限的文件（比如被攻击者上传的后门脚本），那这份备份就等于把恶意程序原样保存了下来，用备份直接恢复时，后门也随之复活，稳妥的做法，是备份完成后对压缩包执行chmod 600，限制读取权限，定期对备份文件做扫描。
恢复演练才是检验备份的唯一标准
行业共识认为,备份的常见误区是把“能拷贝”当成“能恢复”，实际运维中，备份文件损坏、备份不完整、因路径变化导致恢复报错的情况，远比想象中频繁，建议至少一个月做一次演练，核心操作流程可以确定为三条：
- 从备份文件恢复到临时目录,对比关键文件的内容哈希值
- 在当前环境模拟故障,从最新备份完整恢复到原路径
- 验证恢复后的服务端口、进程、数据读写是否正常
大部分服务器故障的复盘结论
回到开头那句话：细节才是决定服务器能不能安稳运行的根本因素，权限位多一个s，挂载参数少一个noexec，定时任务里多一条陌生记录这些在平时“看不见”的差异，到了出问题时就成了“看不起”的代价，把文件系统、安全配置、日志监控、备份恢复这四层逐一夯实，Linux服务器完全可以在无人值守的情况下稳定跑上一整年。
关于Linux服务器日常维护的常见疑问
Linux服务器维护需要专门购买服务吗？
这取决于你对业务可用性的容忍度,如果只是个人测试环境，自己按文档操作即可，但若是生产环境，涉及实时监控、故障响应、数据库优化这类硬功夫，雇一个专业运维或采购运维服务更划算，具体选择时要结合预算和业务规模来评估。
如何检查服务器是否被暴力破解过？
先看系统登录日志,CentOS系检查/var/log/secure，Debian/Ubuntu系检查/var/log/auth.log，用grep "Failed password"统计失败次数，如果短时间内有大量来自不同IP的失败记录，说明正在被爆破，安全加固方向是改端口、禁用密码登录、配置fail2ban做自动封禁IP，记住一条习惯：last和lastb两个命令，分别看成功登录和失败尝试的记录，这两份日志平时多看两眼，很多问题可以提前发现。