Category: Tech

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

在树莓派系统中，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 错误检查 查看内核是否记录了存储层异常： …

在一次例行磁盘检查中，一块 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 …

在使用 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 …

在一次大规模 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 …

在 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、内存等动态状态。这些文件： 若不排除，会看到大量类似： 这类警告不是磁盘损坏，也不是 …