Server

用一份脚本给 VPS 做“体检”：vps_healthcheck.sh 深度解析

在迁移 VPS、排查服务器不稳定、评估主机质量时，仅凭“感觉卡”是远远不够的。真正有价值的，是一份能够在某个时间点完整记录服务器运行状态的“体检报告”。 本文介绍并解析一个实用的 Bash 脚本 —— vps_healthcheck.sh，它的作用是：在几秒钟内抓取 VPS 的 CPU、内存、磁盘、IO、网络、内核状态，并保存为可追溯的日志文件。 这类脚本广泛用于运维取证、迁移前后对比、主机质量评估等场景。 一、完整脚本（脱敏版） 二、脚本的核心定位 该脚本并不尝试修复系统，也不对服务器进行任何修改。它的唯一目标是： 在某一时刻，对 VPS 进行一次完整、可留存的健康快照。 这份快照可以用于： 三、为什么这个日志设计很专业 脚本使用： 意味着： 所有输出 → 屏幕 + 文件 同步写入 这样可以： 这是标准运维“取证型日志”设计方式。 四、采集了哪些关键指标 1. CPU 与虚拟化环境 通过 lscpu 可判断： 用于识别 VPS 是否存在严重超售。 2. 内存与 OOM 风险 free -h + /proc/meminfo 可以看到： 这是判断系统是否会因内存压力杀进程的核心依据。 3. …

Server

使用 SFTP 迁移文件时，如何正确保留时间与权限

在服务器迁移、VPS 更换、或跨主机复制文件时，一个常见需求是：既要保证文件内容一致，也要尽量保留原始的时间戳和权限设置。 很多人会选择 SFTP 作为传输工具，但对它的“属性保留能力”存在误解。本文将从协议能力、客户端行为和实际使用方式三个层面进行说明。 SFTP 是否支持文件属性传输？ 是的。SFTP 协议在设计时就包含了“文件属性”的字段，除了文件内容以外，还可以携带： 也就是说，SFTP 并不是一个“只传字节流”的协议，它天生就支持基本元数据的同步。 关键在于：客户端是否开启 preserve 虽然协议支持，但很多 SFTP 客户端默认不会保留这些属性。以 OpenSSH 自带的 sftp 为例，必须显式启用 -p 参数。 -p 表示：preserve（保留属性） 开启后，这个会话中所有的文件传输都会自动携带属性信息。 使用 sftp -p 后会保留什么？ 在 OpenSSH 的实现中，-p 实际保留的是： 属性 是否保留 文件权限（rwx / mode） ✅ 修改时间（mtime） ✅ 访问时间（atime） 多数实现支持 所有者（uid / gid） ❌ ACL ❌ xattr …

Server

在云服务器上识别并精简运行中的 systemd 服务：一次 VPS 体检与迁移前准备

在进行 VPS 迁移或系统重构之前，对当前服务器中正在运行的服务进行一次系统级审计是非常必要的。这不仅可以避免迁移过程中出现端口占用、服务冲突，还可以发现隐藏的云厂商组件与多余的后台服务，从而为构建一个“干净、可控的中继节点”打下基础。 本文记录了一次对云服务器 systemd 服务的完整盘点、来源识别以及迁移前停机处理的全过程。 一、列出正在运行的服务 在 Linux VPS 上，可以通过 systemd 查询当前所有处于 running 状态的服务： 这一步可以看到当前系统里有哪些 daemon 正在常驻运行，例如网络服务、日志系统、安全组件以及第三方业务服务。 二、识别服务来源（系统 vs 用户 vs 云厂商） 仅仅看到服务名是不够的，关键在于知道它们是： 最重要的信息是每个 service unit 的 FragmentPath，即它的 .service 文件位于哪里： 经验规律： 路径 含义 /lib/systemd/system/ 系统包提供 /usr/lib/systemd/system/ 系统或第三方包 /etc/systemd/system/ 用户或云厂商手动放入 这一步可以精确区分哪些服务是系统必须的，哪些是后期被引入的。 三、识别“真正的业务服务” 通过 unit 路径与已手动安装的软件包列表（apt-mark showmanual）对照，可以清晰分离出真正用于公网通信与远程访问的核心服务： 类型 作用 代理服务 提供对外的网络代理入口 …

Server

在 Ubuntu 服务器上精确识别「用户自己安装的 systemd 服务」

在运维 Linux 服务器时，经常会遇到这样的问题：系统里注册了大量 systemd 服务，但其中绝大多数属于操作系统自带组件，而真正由管理员后期安装、配置过的服务却被淹没在其中。如果无法区分这两类服务，就很难判断哪些服务是业务依赖，哪些是历史遗留或冗余组件。 本文以一台 Ubuntu 服务器为例，系统性地展示如何识别「用户自行安装的服务」，包括正在运行和已经停用但仍然存在的部分。 一、为什么 running 列表不够用 很多人会使用： 来查看系统当前运行的服务。这个命令只能回答一个问题： “现在有哪些服务在跑？” 但它完全无法反映以下信息： 因此，仅依赖 running 视图会得出错误结论，例如误以为系统“只有 Apache 和 MySQL”。 二、真正的总清单：所有已注册的服务 systemd 中，所有服务的定义都存放在 unit files 中，可以通过： 获得完整列表。这个列表显示： 在示例服务器中，共列出了 249 个 unit 文件。 但其中绝大多数是 Linux 与 Ubuntu 自带组件（systemd、udev、networkd、fsck、plymouth 等），需要进一步过滤。 三、用服务内容反推系统画像 通过分析 unit 文件，可以反推出这台服务器的历史和用途： 1. Web 与数据库业务 这是一套典型的 LAMP Web 服务器栈。 …

Server

树莓派 SD 卡健康状态检测与判定实录

在树莓派系统中，SD 卡既承担启动分区，又承担根文件系统与日志写入，是整个系统中最容易损耗、却最关键的部件。当树莓派被用作服务器、运行 Docker、执行大量 rsync 或系统迁移时，SD 卡的寿命与稳定性就变得尤为重要。 本文记录了一次完整、工程化的 SD 卡健康检测过程，并给出明确的技术结论。 一、存储设备基本信息 首先确认树莓派当前使用的存储设备： 输出显示： 说明系统使用的是一张 8GB 级别的 SDHC 卡（约 7.48GiB 可用容量），设备型号显示为 NCard，属于无品牌或低端 SD 卡类别。 二、eMMC 寿命寄存器检测 尝试读取 eMMC 的寿命寄存器（EXT_CSD）： 返回： 这是正常现象。 EXT_CSD 只存在于 eMMC 设备中，而普通 SD 卡物理上并不支持这一寄存器，因此无法读取。这一结果并不表示故障，而是说明该存储介质是标准 SD 卡。 三、文件系统一致性检查 对根分区执行只读检查： 结果： 这代表： 如果 SD 卡出现物理退化或闪存错误，这里通常会出现 I/O 错误或结构损坏提示。 四、内核 I/O 错误检查 查看内核是否记录了存储层异常： …

Server

当机械硬盘开始“自己修复”：一次磁盘濒死前的真实信号

在一次例行磁盘检查中，一块 1TB 机械硬盘出现了 SMART 报警（CrystalDiskInfo 显示 Bad），同时 Windows 的 CHKDSK 报告却显示： “Windows 已发现问题并联机修复了所有问题。无需采取进一步操作。” 这看起来像一个矛盾的结果：一边是“磁盘已坏”，一边是“文件系统正常”。 实际上，这种组合恰恰是机械硬盘进入失效前期的经典表现。 一、SMART 与 CHKDSK 检查的根本区别 很多人会误以为 CHKDSK 能“修好硬盘”，但它的职责仅限于： 层级 检查内容 SMART 磁头、扇区、磁道、重映射、读写错误 CHKDSK NTFS 文件系统结构（目录、索引、权限） 换句话说： SMART 判断的是“盘还能不能用”，CHKDSK 修的是“文件系统还拼不拼得回来”。 二、这次 CHKDSK 实际做了什么？ 在日志中可以看到，CHKDSK 修复了三类问题： 1. 目录索引（$I30）丢失 部分文件仍存在于磁盘，但它们已经从目录树中“消失”，这意味着 NTFS 索引损坏。 CHKDSK 将这些文件重新挂回目录。 2. 孤立文件（Orphan Files） 多个 .tar.gz …

Server

在 Proxmox VE + Proxmox Backup Server 架构下进行磁盘健康自检的一次完整实战

在使用 Proxmox VE（PVE）+ Proxmox Backup Server（PBS） 搭建私有虚拟化与备份平台时，磁盘健康状况是整个系统中最关键的单点风险。本篇文章记录了一次对生产节点（PVE）与备份节点（PBS）磁盘进行全面 SMART 健康检查与风险评估的过程。 目标不是“预测磁盘寿命”，而是回答一个工程上更重要的问题： 现在的磁盘是否“暂时没坏”，是否处于可控状态？ 一、整体架构 系统采用典型的两机分离结构： 角色 存储介质 用途 PVE 主机 8TB 企业级 HDD 生产数据（VM / 存储） PBS 主机 8TB 企业级 HDD 备份数据 两台主机 128GB SSD / NVMe 各自的系统盘 两块 8TB 机械盘分属不同主机、不同电源与负载环境，物理隔离。 二、第一步：确认磁盘结构 在 PVE / PBS 中统一使用： 目的： 这是所有 SMART 分析的前提。 三、SMART …

Server

使用 Proxmox Backup Server 恢复大容量虚拟机时的真实速度分析

在一次大规模 Proxmox VE → Proxmox Backup Server → 新节点恢复的过程中，多个虚拟机磁盘被从 PBS 还原为 qcow2 格式。通过分析 restore 日志，可以清楚地看到：影响恢复时间的关键并不是虚拟磁盘标称容量，而是其中“实际非零数据量”。 本文基于多台 VM（102 / 104 / 106 / 101）的真实恢复日志，分析了 restore 性能、零块跳过比例以及对 6TB 级虚拟机恢复时间的准确估计方式。 一、PBS restore 的关键机制：–skip-zero 所有恢复命令都使用了： 这意味着： PBS 会识别磁盘中的“全零块”，直接跳过，不向目标磁盘写入。 因此： 这也是为什么 PBS restore 日志中会显示： zeroes 百分比越高，真正要写的数据越少，速度越快。 二、不同 VM 的真实恢复速度 从几台 VM 的 restore 完成日志可直接看到最终速度： VM …

Server

使用 rsync 与 tar 迁移 Proxmox VE 宿主机系统（排除虚拟机磁盘）

在 Proxmox VE（PVE）环境中进行宿主机迁移时，正确区分“系统数据”和“虚拟机数据”是关键。宿主机应当只包含操作系统、Proxmox 配置、网络与服务状态，而虚拟机磁盘（qcow2、raw、LVM-thin 等）应交由 PBS 或单独备份处理。这样可以在迁移、恢复或硬件更换时保持高可控性和可恢复性。 本文介绍一种稳定、可重复的做法：在运行中的 PVE 上备份宿主机系统，同时排除虚拟机磁盘文件。 一、系统与虚拟机数据的分离原则 在典型 PVE 安装中，虚拟机磁盘可能以 qcow2 文件的形式存在于： 这类文件往往单个就有数 TB 大小，且已经通过 Proxmox Backup Server（PBS）等方式被单独备份，因此在迁移宿主机时应明确排除。 应当备份的内容包括： 不应当备份的内容包括： 二、推荐方式：使用 rsync 在线备份宿主机 rsync 非常适合做“可恢复的系统复制”，在宿主机运行时也可安全执行。 示例命令 参数说明 该方式不会影响正在运行的虚拟机，只会产生少量“运行中变更文件”的时间差，这在系统迁移场景中是可接受的。 三、tar 打包方式（需要注意排除运行态目录） 如果需要生成一个单一的归档文件（如 .tar.gz），可以使用 tar，但必须排除动态伪文件系统和 lxcfs。 稳定可用的 tar 模板 为什么要排除 /var/lib/lxcfs lxcfs 是 LXC 容器使用的运行时虚拟文件系统，用于显示 CPU、内存等动态状态。这些文件： 若不排除，会看到大量类似： 这类警告不是磁盘损坏，也不是 …

Server

在 Proxmox VE 中将 /var/lib/vz 挂载到独立 LVM 磁盘并实现启动容错

在 Proxmox VE（PVE）环境中，/var/lib/vz 是一个非常关键的目录，用于存放虚拟机磁盘、CT 容器、ISO 镜像、模板以及部分备份数据。如果该目录与系统盘混用，一旦发生磁盘故障，既可能影响虚拟化数据，也可能拖垮整个宿主机系统。 一种更加专业和稳健的做法，是将 /var/lib/vz 单独放在一块独立磁盘上，并使用 LVM（Logical Volume Manager）进行管理，同时设置为“即使磁盘缺失也不阻断系统启动”。 本文将完整介绍这种架构的设计思路与实现方式。 一、设计目标 该方案的目标是： 最终结构如下： 二、创建 LVM 磁盘结构 假设新磁盘为 /dev/sdb。 1. 初始化为物理卷 2. 创建卷组 3. 创建逻辑卷（占满磁盘） 三、创建文件系统 可以使用 ext4 或 xfs，这里以 ext4 为例： 四、迁移原有 /var/lib/vz 数据 1. 临时挂载新磁盘 2. 拷贝数据（保留权限与属性） 五、正式替换挂载点 确认挂载： 六、配置开机自动挂载（容错模式） 获取 UUID： 编辑 /etc/fstab： 添加一行： 这行配置的意义 …