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）对照，可以清晰分离出真正用于公网通信与远程访问的核心服务： 类型 作用 代理服务 提供对外的网络代理入口 …

Hardware

使用 hdparm 和 hd-idle 管理 iMac 内置硬盘的待机状态

很多用户在给 iMac 安装 Linux 后，会选择把系统和数据放在 USB 外接 SSD 或硬盘上，而让内部的 NVMe 与 3.5 寸机械盘“闲置”。但一个非常重要的事实经常被忽略： 即便没有分区、没有挂载、完全不使用，内置机械盘也会在通电状态下持续旋转。 这不仅会造成不必要的功耗，还会持续消耗机械寿命并产生热量。 本文介绍一种工程级的解决方案，使 iMac 内部的 1TB 机械盘在 Linux 下真正成为“冷备用盘”。 一、机械硬盘“没用也在转” 在 Linux 中，使用： 可以查看机械盘的当前状态。 典型输出： 这表示： 即便磁盘没有任何分区或文件系统，这个状态也不会改变。 对一块 3.5″ 7200RPM 的桌面级 HDD（如 Apple 定制的 ST1000DM003）来说，这意味着 持续 5–8W 的功耗和持续机械磨损。 二、将内置 HDD 手动送入真正的 Standby Linux 允许直接向 SATA 设备发送停转命令： 再检查状态： …

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 错误检查 查看内核是否记录了存储层异常： …

Network

一次典型的 Postfix 邮件堆积事故：从 DNS 错误到 SMTPUTF8 协议不匹配

摘要 某台运行 Postfix 的 Linux 服务器在连续多天内无法向自建 Mailcow 邮件服务器发送系统告警邮件，邮件队列持续增长。表面错误为 DNS 解析失败（4.4.3 Host not found），在 DNS 修复后仍存在投递异常。最终发现是 SMTPUTF8 协议能力不匹配导致部分邮件被永久拒绝（5.6.7）。 本文完整记录该事故的诊断路径与修复策略。 1. 事故现象 Postfix 日志中持续出现： 邮件队列中积压多封系统邮件（root → admin），时间跨度超过 5 天。 2. 第一层问题：DNS 故障导致长期队列堆积 检查发现系统的 /etc/resolv.conf 曾指向错误的网关地址（例如 192.168.0.1 而不是实际使用的 192.168.1.1），导致 Postfix 在那段时间无法解析 mail.example.net。 DNS 修复后： 均返回正确 IPv4 地址，说明系统 DNS 已恢复。 但邮件仍不断失败，是因为 Postfix 会对 4.x.x …

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

Hardware

Nikon P900 / P900s 与 Galaxy S23 相机对比

为什么一台十年前的长焦机，仍然有存在价值 在如今智能手机影像高度发达的时代，一台 2015 年发布的尼康 P900 看起来似乎已经“过时”。但在实际使用中，它依然有一个手机无法替代的领域：超远摄。 本文从型号差异、市场价格、成像原理和实际使用场景出发，解释 P900 / P900s 与 Galaxy S23 的真实关系。 一、P900 和 P900s：名字制造的混乱 在二手市场中，常常会看到 P900s 的价格比 P900 更高，这让很多人误以为它是升级版。 事实上： 这意味着： P900s 并不是更好的相机，只是一个地区/批次标识不同的版本。 价格更高，主要来自： 本质上，这是一个 命名误导导致的二手市场错价。 二、P900 的真实定位 Nikon P900 的核心不是画质，而是它的镜头。 参数 Nikon P900 传感器 1/2.3″ 16MP 焦距等效 24–2000mm 光学变焦 83× 类型 固定镜头桥式机 2000mm 等效焦距意味着什么？ 这是 物理光学能力，不是软件放大。 …