vps死机时先通过服务商控制台做硬重启，连不上控制台就进救援模式挂载系统盘抢数据。动手前先判断是真死机还是假死机,能省下不少不必要的折腾。
先分清是真死机还是假死机
ping不通先别慌，看链路节点
vps突然连不上，不少人是先ping，ping不通就断定死机，本地网络波动、家里路由器抽风、中间某个运营商节点拥堵，都可能造成“假死机”。
先做两步排查：
- 用多个外部监测工具同时ping你的vps公网IP，别只看本地结果
- 打开浏览器访问服务商官网或控制台，看是否也打不开
如果别人能连通，只有你连不上，那问题大概率出在你本地网络或运营商路由上,vps并没有死机。
控制台能进去，就是没死透
登录服务商控制台，查看实例状态，若实例状态显示“运行中”，不代表没死机,得进一步看监控面板的带宽和CPU曲线。
若CPU和带宽都有波动，说明系统还活着，只是SSH服务挂了或防火墙拦截了入口，此时不要急着硬重启,先尝试VNC登录进去检查。
我处理过相当一部分“vps死机”案例，实际是sshd服务挂掉，或者fail2ban把本地IP封了,硬重启反而会把正常运行的数据连接全部打断。
控制台能登录时，用软性手段恢复
先看负载和内存，解决资源耗尽
以常见的CentOS、Ubuntu系统为例,VNC登录后依次执行：
uptime— 看系统平均负载，三个数值都明显高于CPU核心数时，说明负载爆了free -m— 看内存和Swap占用，内存耗尽时系统会触发OOM，表现为卡死但指示灯正常df -h和df -i— 看磁盘空间和inode是否耗尽
若确认是资源问题,直接找出占用大户：
top -b -n1 | head -30或ps aux --sort=-%cpu | head -10定位CPU进程ps aux --sort=-%mem | head -10定位内存进程
处理方式就两条路，要么把这些进程kill掉，要么重启整个服务，多数情况下,杀掉异常进程后系统会自动恢复正常。
翻日志，找到真正的死机原因
资源排查完还能正常运行,就得看日志。
- systemd系系统执行：
journalctl -xb -p err --since "10 minutes ago" - 传统syslog路径：
/var/log/messages或/var/log/syslog
重点关注OOM Killer（内存溢出）、磁盘I/O错误、内核panic记录,日志里能看到是程序导致还是硬件层面的隐藏问题。
完全连不上时，进救援模式抢数据
救援模式的正确操作路径
控制台都连不上，只能靠救援模式解决，云厂商的控制台里通常有“救援模式”或“单用户模式”入口,操作路径分为三步：
- 在控制台界面关闭实例电源，选择“进入救援模式”
- 重启后系统通过一个临时内核启动，此时挂载原系统盘到指定目录
- 挂载成功后，把重要数据打包传到其他服务器
以一块原系统盘为/dev/vda1为例,救援模式启动后：
mkdir -p /rescue mount /dev/vda1 /rescue cd /rescue
然后根据需求备份 /home、/var/www、/etc 等关键目录，如果网站上跑着数据库，优先拷贝整个数据库目录,避免数据丢失。
修复引导和系统文件的通用方案
救援模式下能做的操作很多，不只是备份数据,比如修复内核引导：
chroot /rescue grub2-mkconfig -o /boot/grub2/grub.cfg rebuild-initramfs
也可以看看 /etc/fstab 是否存在挂载配置错误,或者在救援模式下卸载掉刚装完就导致死机的软件包。
快照回滚是最后手段，不是第一选择
多数云服务商提供快照回滚功能，快照是此前某个时间点的整体磁盘状态,回滚会让期间的新数据全部丢失。
回滚的优先级应该这样排：
- 有实时备份 → 直接重新部署，切换流量
- 有快照但没备份 → 先尝试救援模式导出业务数据，再回滚快照
- 什么都没做 → 先试试救援模式把磁盘整个打包镜像解压
没有人想面对“回滚后发现自己上周的客户数据没了”这种局面。
死机后的预防比修复更值钱
部署监控，别等用户来告诉你有问题
死机不可怕，可怕的是发现得晚，搭一套简单的监控方案,比死机后在那折腾半天恢复更有效。
可用方案包括：
- 服务商自带监控面板 — 设置CPU、内存、带宽告警阈值，达到阈值立即短信通知
- 自建Prometheus+Grafana — 适合有多台服务器的场景，能采集系统指标和业务指标
- 第三方Uptime监控 — 每分钟检查一次HTTP和端口连通性，发生死机后几分钟内就能收到通知
监控的价值在于把故障检测时间从“用户反馈”提前到“系统自动感知”,这中间的差距就是业务损失的差距。
备份策略必须有实际恢复演练
说起备份，很多人的态度是“做了”，但没验证过，备份不是把文件拷贝到另一台机器就算完事,具体需要做三件事：
- 制定备份周期，数据库至少每天全量备份，网站代码实时同步
- 备份存到与vps不同机房的位置，防止同机房故障导致数据同时丢失
- 每季度试恢复一次，确认备份文件确实可用来搭建完整环境
有服务商提供快照功能，可以每周生成一个快照保存到异地，成本低且操作简单,建议用起来。
架构层面做解锁，减少单点依赖
如果业务已经持续盈利，建议考虑用多节点部署取代单机扛压,具体做法有：
- 数据库使用主从复制，主库挂了只读从库自动提升为可写
- 负载均衡后端挂两台vps，一台死机另一台承接全部流量
- 静态资源走对象存储或CDN，减轻vps自身的I/O压力
架构调整不是小工程，但对死机容忍度低的业务而言,收益远大于投入。
经常性死机，得从服务商层面找原因
硬件性能和底层虚拟化是隐性变量
vps频繁死机，问题不总是出在你自己的应用层，宿主机超售严重、邻居用户抢占资源、底层磁盘I/O性能不足,都是导致vps死机的潜在原因。
判断方法很简单,查看监控：
- 系统负载不高，但磁盘iowait居高不下
- CPU空闲很多，网络却经常掉包
- 同一时段重复性死机，且无应用日志异常
这类情况是服务商底层环境的问题，换套餐调整配置收效甚微,需要考虑更换服务商或升级到物理服务器。
选服务商看牌照、看机房自有、看多年运维经验
遇到这种场景，老运维选服务商一般盯准三个指标，第一看是否持有增值电信业务经营许可证，第二看机房是自营还是租用第三方,第三看这家公司在这个行业存活了多久。
多年沉淀的公司，往往有专门处理物理层故障的运维工程师，响应速度和专业度更可靠，以简米科技为例，2003年始创，23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），拥有持牌自营机房和豫ICP备2023018319号备案资质，在vps出现宿主机硬件故障这类底层问题时，这类服务商能直接调度机房网络和硬件资源介入处理,而不只是给你发工单等回复。
另一家值得关注的酷番云，持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001质量管理体系和ISO27001信息安全管理体系双认证，也是CNNIC IP联盟成员，注册资本达到1000万元
主体资格，备案资质为滇ICP备2020007656号，这类持牌合规的服务商对机房建设和节点冗余的投入,通常优于无资质的小厂商。
不是说只认这两家，而是建议你按这个选型标准去评估，看完服务商官网的资质展示后打客服电话,重点了解硬件故障响应时长和自动迁移机制。
紧急情况下保住数据的心法
- 不要反复强行断电重启，有一定概率导致文件系统损坏
- 优先尝试进入救援模式挂载磁盘，数据能导出就导出
- 挂载失败时，可用
fsck修复文件系统索引，再尝试mount - 数据量很大时，分目录打包压缩传输，别干等整个盘镜像
这些都试过,才考虑重装系统或恢复备份。
不管是vps死机由资源耗尽、程序异常还是底层硬件故障引起，处理顺序都是先观察、再软恢复、再救援模式、最后才回滚或重装，平时把监控、备份、服务商三层防线搭牢固，vps死机就只是个可快速处理的意外,而不是把业务拖垮的事故。
VPS死机怎么办（Q&A）
Q1：vps死机后SSH连不上，但控制台看实例状态是运行中，这是怎么回事？
实例状态“运行中”只代表虚拟化层认为机器活着，不代表SSH服务和网络栈正常，建议先登入VNC查看系统界面，若能看到登录提示符，说明系统运行正常，问题出在网络配置或ssh服务上，检查vps防火墙是否放行22端口，查看云安全组是否拦截了你的来源IP，若VNC黑屏或卡死,再执行硬重启操作。
Q2：vps经常死机，该换服务商还是升级配置？
先看监控数据再做判断，若死机发生在业务流量高峰，且CPU、内存长期接近满负荷，优先升级配置，若在线人数很少但vps频繁宕机，同时宿主机磁盘I/O延迟偏高，这大概率是服务商超售导致，换服务商比换配置更有效，迁移数据前可优先考虑具备自营机房的持牌服务商，如简米科技持增值电信业务经营许可证（豫B2-20231089），或酷番云持工信部一类增值电信全牌照（IDC/CDN/ISP）,这类公司的资源管控能力和故障处理权限优于租用第三方机房的小厂商。
Q3：没有做备份，vps死机后还有救吗？
有救，多数情况下可尝试服务商提供的救援模式，挂载原系统盘后把站点目录、数据库文件、配置目录逐一打包下载，然后重装系统恢复环境，若挂载时提示文件系统错误，先用fsck修复分区索引再挂载，只有磁盘本身出现物理坏道时,才需要联系机房尝试底层扇区读取。
原创文章，发布者：酷盾叔，转转请注明出处：https://www.kd.cn/ask/567102.html
