Pg

问题的背景 最近，一台部署在 Azure 上的 Linux 服务器突然出现 CPU 持续 100% 的情况。排查后发现，服务器上存在一个以 postgres 用户身份运行的恶意程序，并通过 cron 定时任务维持运行。 这台服务器上的 PostgreSQL： 没有通过 Azure NSG 向公网开放 5432； 没有被当前业务使用； 业务实际使用的是本机 MySQL； 但 PostgreSQL 服务仍然安装并运行； 系统中保留了 postgres 用户、主目录、cron 和历史脚本。 这次事件说明： PostgreSQL 没有向公网开放，并不代表服务器上与 PostgreSQL 相关的组件完全没有风险。 需要特别说明的是，目前的证据只能证明恶意程序利用了 postgres 操作系统用户及其目录进行持久化，不能证明攻击者一定是通过 PostgreSQL 的 5432 端口进入服务器的。初始入口也可能是历史配置、SSH、Web 应用、容器、旧镜像或其他漏洞。 如果生产环境确实需要 PostgreSQL，但没有必须自建数据库服务器的特殊要求，建议优先使用： Azure Database for PostgreSQL，并通过私有网络访问，关闭公共网络入口。 这样可以减少自建数据库所带来的操作系统用户、SSH、cron、systemd、补丁、备份和主机入侵等风险。 发现问题：服务器 CPU 持续占满 最初是在服务器上执行 htop 时发现异常。 从截图中可以看到： 服务器共有 4 个 CPU 核心； 4 个核心全部达到 100%； Load Average 长期维持在 4 左右； 多个进程以 postgres 用户运行； 进程名称为随机字符串 dzZ7yVrxv7； 单个进程的 CPU 使用率超过 200%； 进程占用了大量内存。 进一步执行：...

随着 OpenWebUI 中的用户、对话、文件和知识库数据不断增长，原先部署在 Azure VM 上的自建 PostgreSQL 带来了越来越多的运维工作，包括数据库补丁、备份、故障恢复、存储监控和安全维护。 为了降低维护成本并提高数据库可靠性，我将 OpenWebUI 的业务数据库从 VM 本地 PostgreSQL 迁移到了 Azure Database for PostgreSQL Flexible Server。 这次迁移采用了： 在线全量迁移 + 数据一致性验证 + 活跃对话增量同步 + 快速切换 全量数据库导出和恢复期间，OpenWebUI 始终保持在线。最终切换仅涉及一次很短的 Docker 容器重建，用户侧基本无感。 本文中的服务器地址、数据库名称、用户名、密码和资源标识均已隐藏或替换为占位符。 迁移背景 OpenWebUI 以 Docker 容器形式运行在 Azure VM 中，最初使用安装在同一台 VM 上的 PostgreSQL。 迁移前的架构如下： 用户 │ ▼ Azure VM ├── OpenWebUI Docker 容器 │ └── 连接 VM 宿主机 PostgreSQL │ └── PostgreSQL └── 数据保存在 VM 本地磁盘 这种部署方式比较简单，但随着应用逐渐稳定运行，数据库维护也成为了新的负担。...