部署 Uptime Kuma，监控网站是否在线

网站打不开，Uptime Kuma 可以定时检查并通知你。想连整台 VPS 断网、关机也能发现，最好把监控放在另一台机器；与网站同机时，两者可能一起停掉。

监控节点放在哪里

已有独立 VPS 可以先用它。只有一台机器、又需要监控整机可用性时，再比较月付 VPS 的试用与续费成本，为监控单独安排节点。节点所在地区会影响访问结果：从海外能访问，不等于国内每个网络都正常。

监控少量站点可以先选小型 Linux 实例，把检查间隔、历史记录与通知需求列出来；关键是尽量放在不会与业务机一起故障的位置。可查看 Evoxt 的监控节点地区，或比较 雨云 RCS 的独立实例。先以短周期试访问目标网站，并测试故障和恢复通知，后续增加检查对象时再观察资源，别为了监控选与业务机相同的大规格。

HTTP 检查适合网站入口，TCP 检查用于确认指定端口能否接收连接；端口开放不能证明业务页面正常。登录后的操作还需要另外设计检查，不宜把管理账号随手放进公开监控地址。

用官方 2 系列镜像启动

前提是 Linux VPS 已安装 Docker Engine 和 Compose 插件。建立独立项目目录，把下列内容保存为 compose.yaml：

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2.5.5@sha256:c74379ac4509ce2d2c2633f509e67003ee2e45b6e995c5e43fc101f45a0e1fbe
    environment:
      UPTIME_KUMA_DB_TYPE: sqlite
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data

data 是持久化目录，使用服务器本地磁盘；官方不支持将它放在 NFS 这类文件系统上。上面固定的是 2.5.5 和对应的多平台镜像索引摘要，并明确选用 SQLite。已有实例先保留自己实际运行的版本与数据库类型，不要为了套用示例直接覆盖配置。2 是会变化的系列标签，正式运行时记录实际镜像摘要；重新拉取镜像可能换了版本，升级前仍要备份。

docker compose config -q
docker compose up -d
docker compose logs --tail=100 uptime-kuma

端口只绑定服务器回环地址。从自己的电脑运行 SSH 转发，把 your-vps 换成实际 SSH 主机名：

ssh -N -L 3001:127.0.0.1:3001 your-vps

打开本机 http://127.0.0.1:3001，建立管理员。终端需要保持连接；本机端口已占用时，可以修改 -L 的第一个端口。需要域名访问，再按宿主机 Caddy 反向代理教程接入 HTTPS。

从一个公开页面开始检查

新增 HTTP 监控，填写真正要观察的页面，先确认正常响应。网站返回 200 却显示错误页时，增加关键词检查；若目标本来会跳转，检查最后到达的页面是否仍是自己的业务。

故障记录里，DNS 解析失败、TLS 错误、连接超时和 HTTP 错误码对应不同处理方向。不要看到一次红色记录就换服务器；先看发生时间、持续多久，以及应用日志是否有同一时段的错误。

把通知绑定到监控项，再试一次故障

添加自己使用的通知渠道后，先发一条测试消息，再把渠道绑定到监控项。用自己控制的测试地址制造失败，确认收到故障通知；让测试地址恢复，再确认恢复通知。仅收到测试消息，不能说明正式监控的通知配置已生效。

按网站容忍度设置检查间隔和重试。过于频繁的请求可能给目标增加负担，偶发抖动也容易造成重复告警。公开状态页只放准备对外展示的项目，用未登录浏览器确认没有暴露内网地址、私有接口或管理入口。

数据备份要连同版本保留

容器可以重新创建，监控项目、历史记录、通知渠道和登录信息却存放在 data。只保存 Compose 文件不能恢复这些内容。下面是 SQLite、本地 ./data 挂载和同版本镜像的冷备份；使用外部数据库的实例还需要该数据库自己的完整备份，不能只拷贝目录。

先在管理界面暂停这份备份中的全部监控项，记录各项目原来的启用或暂停状态。这样副本启动后也会保持全部真实监控暂停，不会立即向真实通知渠道重复告警。随后在原项目目录执行：

set -eu
umask 077
backup_root="$HOME/kuma-backups"
mkdir -p "$backup_root"
backup_dir="$backup_root/$(date -u +%Y%m%dT%H%M%SZ)"
mkdir "$backup_dir"
cid="$(docker compose ps -a -q uptime-kuma)"
test -n "$cid"
docker inspect "$cid" --format '{{.Image}}' > "$backup_dir/image-id.txt"
image_id="$(cat "$backup_dir/image-id.txt")"
docker image inspect "$image_id" --format '{{json .RepoDigests}}' > "$backup_dir/image-repodigests.json"
docker compose stop --timeout 30 uptime-kuma
test "$(docker inspect "$cid" --format '{{.State.Running}}')" = false
if ! tar -czf "$backup_dir/kuma-data.tar.gz" data compose.yaml; then
  echo '备份失败，保持停机，检查输出后再处理' >&2
  exit 1
fi
(cd "$backup_dir" && sha256sum kuma-data.tar.gz > SHA256SUMS)
chmod 600 "$backup_dir"/*
docker compose start uptime-kuma

确认原实例启动正常，再在界面恢复原来启用的项目。备份包含账号、通知配置与可能的私密地址，只放在有访问限制的目录；异地保存时加密传输和存储。另行保留实际使用的代理配置，证书或通知凭据不要放进公开仓库。

恢复机器先安全复制备份包、校验文件和镜像记录。下面的路径要显式替换为实际位置；不要依赖原终端里的变量。恢复目录必须是新目录，先验证校验和，再解包：

set -eu
umask 077
backup_dir='/实际受保护路径/20261014T000000Z'
test -r "$backup_dir/kuma-data.tar.gz"
test -s "$backup_dir/kuma-data.tar.gz"
(cd "$backup_dir" && sha256sum -c SHA256SUMS)
restore_dir="$HOME/uptime-kuma-restore"
test ! -e "$restore_dir"
mkdir "$restore_dir"
tar -xzf "$backup_dir/kuma-data.tar.gz" -C "$restore_dir"
cd "$restore_dir"

打开恢复目录中的 compose.yaml，保留备份时的镜像版本和摘要，把宿主端口改为独立的 127.0.0.1:3002:3001。确认挂载仍是恢复目录的 ./data:/app/data，避免指向原实例数据。不要让两个容器同时读写同一份 SQLite 目录；也不要先拉一个新版本，让它改写旧备份。

docker compose -p kuma-restore config -q
docker compose -p kuma-restore up -d
docker compose -p kuma-restore logs --tail=100 uptime-kuma

通过独立的 SSH 转发访问副本，用原账号登录。检查监控类型、URL、请求方式、间隔、重试、接受的状态码、通知渠道与绑定，再看旧故障和恢复记录是否还在。演练时保持真实业务监控暂停，只启用指向自己测试地址的项目和本地测试通知，验证一次新的失败与恢复。确认完毕先停下副本，再按计划切换，避免两个监控节点重复发送通知。

本次在本机 Docker 的 Linux/ARM64 容器中，用固定 2.5.5 镜像、SQLite 和独立数据卷做了隔离演练。冷拷贝的数据库与配置文件在恢复启动前逐文件校验一致；原账号可以登录，监控完整定义、通知配置与绑定、实验内原有的 3 条历史记录均保留。随后只对实验内的合成 HTTP 地址制造失败与恢复，本地 Webhook 收到了对应事件，新历史增加，原记录未变。

演练没有使用真实网站或外部通知渠道，也没有验证公网 HTTPS、邮件或即时消息外送、AMD64 主机和大版本迁移。上面的 Compose 与 tar 命令按 Linux 本地目录实例组织；隔离演练使用独立命名卷，其结果用于说明同版本数据恢复，不是对所有部署环境的保证。

同版本恢复与升级是两件事。大版本迁移可能修改数据库；升级失败后单独退回旧镜像，不一定能读取已经升级的数据。回退应同时恢复升级前的数据副本和对应版本，并按官方迁移前提处理。