Category: Server

在实际运维中，Fail2ban 不只是一个防护工具，它还是一台服务器长期遭受攻击后形成的“安全记忆库”。当更换或迁移 VPS 时，如果只重新安装 Fail2ban 而不迁移其历史状态，就等于让攻击者从零开始重新测试新服务器的防御边界。 本文介绍一种可验证、可复现、可迁移的 Fail2ban 完整状态迁移方法。 一、Fail2ban 的真实数据在哪里 Fail2ban 的运行状态由两部分构成： 类型 目录 配置与规则 /etc/fail2ban 封禁状态与历史 /var/lib/fail2ban 其中 /var/lib/fail2ban 通常包含一个 SQLite 数据库，用于存储： 这是 Fail2ban 最重要的“资产”。 二、为什么不能在运行时备份 Fail2ban 在运行中会持续写入数据库： 如果在运行中直接复制数据库文件，极容易得到： 这会导致迁移后 Fail2ban 启动失败或悄然失效。 因此，正确做法是：先停服务，再备份数据。 三、确认 Fail2ban 运行模式 Fail2ban 有两种运行模型： 模式 特征 root 模式 系统中没有 fail2ban 用户 非 root 模式 …

摘要 一次看似“降配”的 VPS 更换（更低 CPU / 内存 / 磁盘），却带来了使用体验上的巨大飞跃。原因不在计算资源，而在 网络层级：从受限的国际云出口，迁移到了具备 1Gbps 端口的日本本土数据中心。本文记录了测速、延迟、路由与实际 4K 流媒体体验的对比分析，展示了为什么带宽和网络拓扑在现代自托管系统中比 CPU 和内存更重要。 一、原始环境与问题 原有 VPS 位于日本，但属于大型中国云厂商的海外节点，标称参数为： 项目 旧 VPS CPU 1 vCore 内存 1 GB 磁盘 20+ GB 流量 1 TB 端口带宽 30 Mbps（标称） 地点 东京 实际测速（使用 Cloudflare 测试节点）： 而部分国际测速点（如欧洲镜像）甚至只有： 这意味着： 网络成为系统瓶颈。 二、新 VPS 配置 迁移到一家日本本土云厂商的轻量实例： …

在云服务器环境中，Ubuntu 官方 Cloud Image 往往为了“通用性”而内置了大量面向物理机、桌面或开发环境的组件。这些组件在 VPS 上不仅没有意义，还会带来磁盘浪费、升级风险以及依赖混乱。 本文记录了一次真实的 Ubuntu 24.04（noble）云主机修复与极简化过程，从发现磁盘异常、定位无用组件，到修复 APT 依赖与源混乱，最终将系统恢复为一个干净、稳定、适合长期运行网络服务的 VPS 系统。 一、问题的起点：异常臃肿的 /usr/lib 通过分析 /usr/lib 目录发现系统体积远大于典型 VPS： 其中包含大量不应出现在 VPS 上的组件： 这些都是典型“桌面 / 物理机 / 开发环境”遗留物。 二、发现根因：APT 源跨区域导致版本漂移 进一步排查发现系统使用了： 在 Ubuntu 24.04 的 .sources 格式下，这种跨站点组合极易导致： 表现为： 这是典型的仓库不一致导致的依赖破坏。 三、正确做法：统一为日本官方仓库 Ubuntu 24.04 采用 /etc/apt/sources.list.d/ubuntu.sources，必须修改该文件，而不是传统 sources.list。 统一切换到日本官方镜像（JAIST）： 然后清空索引并重建： 验证 systemd 依赖已恢复： …

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

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

在运维 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 …