Linux

从 SteamCMD 到 Docker：一次 Ubuntu 服务器的 i386 架构彻底清理实录

摘要 在长期运行的 Ubuntu 服务器上，历史遗留的 32 位（i386）架构往往来自早期软件需求，例如 SteamCMD。这类依赖在功能退役后若不清理，会增加系统复杂度、降低可预测性。本文记录了一次完整、可控的 i386 架构移除过程，并最终将异构需求交由 Docker 处理，使宿主系统回归纯 amd64 状态。 一、问题背景 在一台 Ubuntu 22.04 服务器上，通过以下命令确认系统启用了 i386 架构： 输出显示： 进一步检查已安装的 32 位软件包： 结果发现系统中存在大量 libc6:i386、libssl3:i386、zlib1g:i386 等基础库，但唯一的应用级包来源是 SteamCMD（32 位）。 随着使用策略调整，决定不再在宿主机直接运行 SteamCMD，而改用 Docker 容器 承担此类需求，于是启动了 i386 架构的彻底清理。 二、初步尝试与关键误区 在移除 SteamCMD 后，直接尝试移除架构： 结果失败： 原因很明确：只要系统中仍存在任何 :i386 包，dpkg 就不会允许移除该架构。 三、apt 通配符陷阱 尝试使用 apt 通配符清理： …

Backup

将 Anki Sync Server 数据迁移至应用目录的实践

在非系统包管理（非 APT/YUM 等）环境下运行 Anki Sync Server 时，默认的数据存储位置与传统 Linux 目录结构往往不利于长期维护、迁移和备份。本文记录了一次将 Anki Sync Server 的数据目录从默认位置迁移并集中到应用目录下的实践过程，并总结了其中涉及的关键机制与注意事项，为需要“手动管理应用”的使用场景提供一种可复制的方案。 一、问题背景 Anki Sync Server 官方支持通过 Python 模块 anki.syncserver 运行同步服务。在默认配置下： 在以下场景中，上述默认行为会带来不便： 因此，有必要将 Anki Sync Server 的数据目录显式迁移到应用自身目录中。 二、官方机制说明（关键前提） 根据 Anki 官方文档说明： 这意味着，任何迁移方案都必须围绕 SYNC_BASE 这一官方支持的接口展开。 三、目标设计：应用自包含目录结构 迁移的目标并非简单“换路径”，而是形成一种清晰、稳定、可迁移的目录布局： 该结构具有以下特点： 四、迁移步骤概述 1. 停止同步服务 在任何数据操作之前，应先停止正在运行的同步服务，避免并发写入。 2. 准备目标数据目录 在应用目录下创建专用的数据子目录（例如 data/），并确保权限正确。 3. 迁移已有服务端数据 将默认数据目录中的内容整体迁移到新的数据目录中，保持原有目录层级（每个用户一个子目录）。 迁移完成后，新的结构应直接呈现为： …

Code

从 10GB 到 512MB：一次数据库内存回收带来的整机重生

——PVE + Docker + Web 应用场景下的真实优化案例 一、问题背景 在一台运行于 Proxmox VE（PVE）上的 Linux 虚拟机中，同时部署了多种服务，包括： 该虚拟机分配了约 23GB 内存，长期观察到： 初步怀疑数据库内存配置不合理。 二、关键发现：InnoDB Buffer Pool 被设置为 10GB 通过查询数据库内部参数发现： 结果显示： 这是一套典型的数据库专用服务器配置，而当前系统实际上是一个多服务混合运行的 Web 主机。 在这种环境下： 其直接后果是： 三、目标：尽可能小，但不影响实际性能 该系统的目标是： 在不影响 Web 应用体验的前提下，将数据库内存压缩到合理的下限。 最终采用如下配置： 设计原则： 四、效果：数据库从“内存黑洞”变为“可控组件” 重启后验证： 数据库进程内存占用： 与 512MB 的 buffer pool 高度一致，说明配置准确生效。 五、整机内存结构发生根本变化 优化后系统状态： 含义： 本质变化是： 从“数据库私有缓存主导”→ “操作系统统一缓存主导” …

Server

在 VPS 迁移中完整保留 Fail2ban 封禁历史的正确方法

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

Server

从 30Mbps 到 1Gbps：一次 VPS 网络层级的跃迁

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

Server

从混乱云镜像到极简稳定 VPS：一次 Ubuntu 服务器瘦身与修复实战

在云服务器环境中，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 依赖已恢复： …

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. …

Backup

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

Mac

使用 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 设备发送停转命令： 再检查状态： …