Databasus v3.63.1 Docker Compose 部署指南

目标：在一台 Linux 服务器上以 Docker Compose 完成数据库备份平台 Databasus 的完整落地——部署服务、初始化管理员、接入 PostgreSQL 与 MySQL 备份目标、配置并执行加密备份、完成恢复验证与通知链路实测。本文全部命令与回显均来自 2026-10-24 的真实部署实测，环境口径见第一章。

一、环境信息

本章说明实测环境口径，便于读者复现。

实测日期：2026-10-24；
实测版本：Databasus v3.63.1（GET /api/v1/system/version 返回 {"version":"3.63.1"}）；
操作系统：Linux（Docker Engine 宿主机）；
数据库交付形态：Docker 镜像 databasus/databasus:v3.63.1（约 1.59 GB，Docker Hub 与 ghcr.io/databasus/databasus 同版本双源发布，Docker Hub 被限流或拉取停滞时可改用 ghcr 源，镜像内容一致）；
备份目标实例：PostgreSQL 16（逻辑备份）、PostgreSQL 17（物理备份，summarize_wal=on）、MySQL 8.0（逻辑备份）；
网络规划：独立桥接网段 10.89.67.0/24（避免与其他业务网段重叠），服务端口 8142（映射到容器内 4005）；
前置依赖：Docker Engine 20.10+ 与 Docker Compose v2.0+（官方最低要求为 1 CPU / 500 MB 内存 / 5 GB 磁盘，另加备份存储空间）。

二、部署前准备

本章确认资源与网络规划，避免部署中途返工。

2.1 端口与网段检查

Databasus 默认监听 4005，生产建议映射为高位端口。部署前确认端口未被占用，并规划一个不与现有业务冲突的容器网段：

# 确认宿主机端口空闲（以 8142 为例）
ss -ltn | grep 8142
# 无输出即空闲

若宿主机上已有大量 Docker 业务栈，务必为备份平台单独划网段（本文用 10.89.67.0/24），且创建前复核目标网段未被既有网络占用（网段重叠会导致网络创建失败，实测排障见第十章）。

2.2 目录规划

/opt/databasus/                 # 部署根目录（官方脚本默认安装位置，可自定义）
├── docker-compose.yml          # 栈定义
├── pg_hba.conf                 # 物理备份目标的自定义访问控制（见第五章）
├── initdb/                     # PostgreSQL 目标库初始化脚本
├── initdb-mysql/               # MySQL 目标库初始化脚本
└── databasus-data/             # Databasus 全部数据（凭据密钥、内部库、备份文件）

databasus-data 是整个实例的生命线：secret.key（加密主密钥）与 pgdata/（内部 PostgreSQL，存全部配置与备份元数据）都在其中，官方 FAQ 明确「备份 Databasus 自身」就是备份这个目录。目录权限问题会启动失败，报 Permission denied 时执行 sudo chown -R $USER:$USER ./databasus-data && chmod -R 755 ./databasus-data。

三、Docker Compose 部署

本章给出官方模板与本文实测栈。Databasus 单体服务内嵌 PostgreSQL 作为元数据库，不需要额外的中间件容器；备份目标数据库（被备份的业务库）按需加入同一网络。

3.1 官方最小模板

官方文档的 Compose 模板只有 Databasus 本体一个服务：

services:
  databasus:
    container_name: databasus
    image: databasus/databasus:latest
    ports:
      - "4005:4005"
    volumes:
      - ./databasus-data:/databasus-data
    restart: unless-stopped

生产环境建议固定版本号（如 v3.63.1）而非 latest——该项目小版本迭代密集，历史上发生过破坏性变更（agent 备份模式在 v3.42.0 后被移除），盲目追 latest 有升级风险。

3.2 本文实测栈（多目标库同栈部署）

将备份目标库与 Databasus 编入同一 compose 栈，便于统一管理（docker-compose.yml）：

name: databasus-v3.63.1-stack

services:
  databasus:
    container_name: databasus-v3.63.1-app
    image: databasus/databasus:v3.63.1
    ports:
      - "8142:4005"
    volumes:
      - ./databasus-data:/databasus-data
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "databasus", "healthcheck"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 120s
    networks:
      - dbnet

  pg16-target:
    container_name: databasus-v3.63.1-pg16
    image: postgres:16
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: q1w2e3r4
      POSTGRES_DB: appdb
    volumes:
      - ./initdb:/docker-entrypoint-initdb.d:ro
    restart: unless-stopped
    networks:
      - dbnet

  pg17-target:
    container_name: databasus-v3.63.1-pg17
    image: postgres:17
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: q1w2e3r4
      POSTGRES_DB: appdb
    volumes:
      - ./initdb:/docker-entrypoint-initdb.d:ro
      - ./pg_hba.conf:/etc/pg_hba.conf:ro
    command: ["postgres", "-c", "summarize_wal=on", "-c", "hba_file=/etc/pg_hba.conf"]
    restart: unless-stopped
    networks:
      - dbnet

  mysql80-target:
    container_name: databasus-v3.63.1-mysql80
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: q1w2e3r4
      MYSQL_DATABASE: appdb
    volumes:
      - ./initdb-mysql:/docker-entrypoint-initdb.d:ro
    restart: unless-stopped
    networks:
      - dbnet

networks:
  dbnet:
    name: databasus-v3.63.1-net
    driver: bridge
    ipam:
      config:
        - subnet: 10.89.67.0/24

要点说明：

镜像选型：主服务固定 databasus/databasus:v3.63.1；PG17 目标库用于物理备份链路，PG17 起服务端支持 summarize_wal（WAL 摘要），这是 Databasus 块级增量与 PITR 的前置条件，所以启动参数显式 -c summarize_wal=on；MySQL 8.0 走逻辑转储路线；
pg17 挂载自定义 pg_hba.conf 的原因见第五章 5.2 排障实录；
start_period: 120s：官方文档明确首次启动最长约 2 分钟（内部 PostgreSQL 初始化），健康检查宽限期要给足；
网段显式声明 10.89.67.0/24，防止默认地址池与其他栈冲突。

3.3 启动与健康确认

docker compose up -d

实测启动后约 50 秒健康检查通过：

$ docker compose ps
NAME                        STATUS
databasus-v3.63.1-app       Up (healthy)
databasus-v3.63.1-mysql80   Up
databasus-v3.63.1-pg16      Up
databasus-v3.63.1-pg17      Up

用官方健康端点确认服务就绪（实测回显）：

$ curl -s http://localhost:8142/api/v1/system/health
{"status":"Application is healthy, internal DB working fine and disk usage is below 95%. You can connect downdetector to this endpoint"}

该端点返回 200 即对外可服务；异常时返回 503 并附原因（内部数据库、缓存、磁盘用量超 95%、数据库客户端工具、备份调度器、验证代理存活度六项检查）。官方特别提示它只用于外部监控告警，不要当作编排系统的存活探针——「降级但仍在服务」也会返回 503，会误杀健康进程；编排探针应使用内置的 databasus healthcheck 命令。

四、服务初始化

本章完成管理员账号与工作区初始化。

4.1 创建管理员账号

浏览器访问 http://<服务器IP>:8142，注册的第一个账号自动成为实例管理员。用 API 等价操作为：

POST /api/v1/users/signup
{"email":"admin@example.com","password":"q1w2e3r4","name":"admin"}

→ {"userId":"ffadc237-...","email":"admin@example.com","token":"eyJhbGciOiJIUzI1NiIs..."}

首个账号注册成功即持有管理员角色；后续注册的账号自动为成员角色，需管理员在用户管理中提权。忘记管理员密码时官方提供控制台重置：

docker exec -it databasus ./main --new-password="新密码" --email="admin@example.com"
docker exec -it databasus ./main --list-admins   # 列出管理员账号
docker exec -it databasus ./main --create-user --email="ops@example.com" --password="密码" --role=admin  # 免 UI 建号

4.2 创建工作区

Databasus 以工作区（Workspace）隔离数据库、存储与通知资源，登录后先建工作区（实测 POST /api/v1/workspaces）：

{"id":"fa0e4f67-6957-4cf6-b7c1-a8fd819c36ac","name":"prod-workspace","userRole":"WORKSPACE_OWNER"}

所有后续资源（数据库、存储、通知渠道）都挂在这个 workspace 下。

五、备份目标接入

本章把 PostgreSQL 与 MySQL 实例接入 Databasus，包括只读备份用户的准备与两处实测排障。

5.1 业务库与只读用户准备

目标库预置了业务数据（customers 200 行、orders 1000 行）供恢复核对。为遵循最小权限原则，为 Databasus 建专用只读账号（PostgreSQL）：

CREATE ROLE backup_ro WITH LOGIN PASSWORD 'q1w2e3r4';
GRANT USAGE ON SCHEMA public TO backup_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO backup_ro;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO backup_ro;   -- 关键，见排障实录
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO backup_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON SEQUENCES TO backup_ro;

MySQL 侧同理（initdb-mysql/01-app.sql）：

CREATE USER 'backup_ro'@'%' IDENTIFIED WITH mysql_native_password BY 'q1w2e3r4';
GRANT SELECT, SHOW VIEW, PROCESS, LOCK TABLES ON *.* TO 'backup_ro'@'%';
FLUSH PRIVILEGES;

Databasus 接入数据库时会做三层只读校验（角色级非超级用户、库级无 CREATE/TEMP、表级零写权限），发现写权限会告警；它也提供一键创建只读用户的功能（/api/v1/databases/create-readonly-user）。物理备份则不同：pg_basebackup 走复制协议，需要具备 REPLICATION 权限的角色，本文直接使用目标库超级用户。

5.2 排障实录一：物理备份目标 pg_hba 拒绝复制连接

现象：接入 PostgreSQL 17 物理备份（类型 POSTGRES_PHYSICAL）时，连接测试返回：

{"code":"pg_hba_no_entry"}

原因：物理备份走 PostgreSQL 复制协议（连接属性 database=replication），而官方 postgres 镜像默认生成的 pg_hba.conf 中 host all all all 一条不覆盖 replication 连接（pg_hba 规则中 all 数据库不匹配复制连接），因此远程复制连接被拒。

解决：为目标库挂载自定义 pg_hba.conf，显式放行复制连接：

local   all             all                                     trust
host    all             all             all                     scram-sha-256
host    replication     appuser         10.89.67.0/24           scram-sha-256

并在 compose 中以 command: postgres -c hba_file=/etc/pg_hba.conf 指定后重建容器。复测连接测试返回 {"message":"connection successful"}。

5.3 排障实录二：只读用户缺 SEQUENCE 权限被拒

现象：接入 PG16 逻辑备份（backup_ro 只读角色）时连接测试报错：

{"error":"insufficient permissions for backup: role \"backup_ro\" cannot read everything pg_dump would dump.
Missing SELECT on: public.customers_id_seq, public.orders_id_seq. Grant USAGE ON SCHEMA, SELECT ON ALL TABLES
IN SCHEMA and SELECT ON ALL SEQUENCES IN SCHEMA to \"backup_ro\" ..."}

原因：pg_dump 会连序列（sequence）一起导出，Databasus 的接入预检比「能连上」严格——它校验目标角色能否读全 pg_dump 将导出的所有对象，缺序列 SELECT 直接拒绝，避免备份产物不完整。

解决：补 GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO backup_ro; 并配置默认权限（见 5.1），复测通过。

5.4 正式接入三个备份目标

在 Web 控制台「New Database」向导中逐一接入（API 等价 POST /api/v1/databases/create），实测三条记录：

名称	类型	引擎版本	连接	结果
pg16-appdb	POSTGRES_LOGICAL	16	backup_ro@10.89.67.2:5432/appdb	创建成功
pg17-physical	POSTGRES_PHYSICAL	17	appuser@10.89.67.3:5432	创建成功
mysql80-appdb	MYSQL	8.0	backup_ro@10.89.67.5:3306/appdb	创建成功

接入响应中连接密码已呈 enc: 前缀的密文（AES-256-GCM 加密落库），而非明文回显，符合官方安全设计（加密主密钥在 databasus-data/secret.key，不进数据库）。

六、备份任务配置与执行

本章配置存储目的地、备份计划与加密，并实测手动备份。

6.1 配置本地存储

控制台添加存储目的地（POST /api/v1/storages），类型选 Local：

{"id":"44c8c746-9f42-4642-8348-0b7721322dc1","name":"local-main","type":"LOCAL"}

支持的存储类型还包括 S3 及兼容（含 Cloudflare R2）、Google Drive、Azure Blob、NAS、FTP、SFTP、rclone 等，配置方法同构。备份文件将写入 databasus-data/backups/ 目录。

6.2 备份计划（含加密与保留策略）

为每个数据库配置备份计划（POST /api/v1/backup-configs/save）。实测 pg16-appdb 的完整配置：

{
  "databaseId": "2b4356f2-be8d-4f24-8c3f-4d060b7125e2",
  "isBackupsEnabled": true,
  "backupInterval": {"type": "DAILY", "timeOfDay": "04:00"},
  "storage": {"id": "44c8c746-9f42-4642-8348-0b7721322dc1"},
  "retentionPolicyType": "TIME_PERIOD",
  "retentionTimePeriod": "3_MONTH",
  "encryption": "ENCRYPTED",
  "sendNotificationsOn": ["BACKUP_SUCCESS", "BACKUP_FAILED"],
  "isRetryIfFailed": true,
  "maxFailedTriesCount": 3
}

配置项说明（均为 v3.63.1 实测取值）：

backupInterval：hourly/daily/weekly/monthly/cron 五类；daily/weekly/monthly 需给 timeOfDay（UTC 时间，官方建议选低峰时刻如凌晨 4 点）；
retentionPolicyType：TIME_PERIOD（按时间，取值 DAY/WEEK/MONTH/3_MONTH/6_MONTH/YEAR/…/FOREVER）、COUNT（按份数，retentionCount）、GFS（祖孙三代分层，retentionGfsHours/Days/Weeks/Months/Years）；物理备份链另有 chainsRetention 与 fullBackupsRetention（LAST_N / GFS 两类策略）；
encryption：ENCRYPTED 开启 AES-256-GCM 备份加密，每份备份用「主密钥 + 备份 ID + 随机盐」派生的独立密钥；存储端拿到密文无主密钥不可读；
物理备份计划：独立走 POST /api/v1/backup-configs/physical/save，可分别配置全量计划与增量计划（fullBackupInterval / incrementalBackupInterval），备份链类型支持 FULL / FULL_INCREMENTAL / FULL_INCREMENTAL_WAL_STREAM 三档；
isRetryIfFailed + maxFailedTriesCount：失败自动重试，默认 3 次。

6.3 排障实录三：未绑定存储时手动备份「假成功」

现象：配置好计划前直接触发手动备份，API 返回 {"message":"backup started successfully"}，但备份列表始终为空。

取证：服务日志出现：

level=ERROR msg="backup config storage ID is nil" database_id=2b4356f2-...

结论：备份目标必须先在计划中绑定存储目的地，否则手动触发会静默失败（API 层无报错，仅服务日志可见）。先配置 storage，再触发备份。物理备份同理，且其配置走独立的 physical/save 端点。

6.4 执行备份与结果核对

绑定存储后触发手动备份（逻辑备份 POST /api/v1/backups，物理备份 POST /api/v1/backups/physical/database/<id>/trigger，body {"type":"full"}），实测三路全部完成：

pg16-appdb      COMPLETED  原始 0.18 MB → 加密压缩后 0.013 MB（约 14 倍压缩）耗时 67ms
mysql80-appdb   COMPLETED  加密压缩后 0.009 MB
pg17-physical   COMPLETED  pg_basebackup 全备 3.3 MB / 195ms，timeline 1，
                           LSN 0/3000028 → 0/3000120，备份用复制槽用后自动清理

产物落在 databasus-data/backups/，每份备份附带 .metadata / .manifest 元数据文件。逻辑备份为引擎原生格式（PostgreSQL 为 pg_dump custom 格式 + zstd 压缩，MySQL 为 mysqldump 产物），文件名含引擎、时间戳与备份 ID。

七、恢复验证

本章完成全链路恢复演练：从加密备份恢复出数据并与源库逐行核对。备份成功不等于可恢复，恢复演练是备份体系验收的硬指标。

7.1 恢复目标与执行

在数据库详情页的恢复向导中指定目标实例与目标库（API 等价 POST /api/v1/restores/<backupId>/restore）。实测 PostgreSQL 侧：

POST /api/v1/restores/54427e0f-52ec-4ee9-b845-42f2b01097e7/restore
{"postgresqlDatabase":{"host":"10.89.67.2","port":5432,"username":"appuser","password":"q1w2e3r4","database":"restore_check"}}

→ {"message":"restore started successfully"}

注意目标库需预先存在（pg_restore 不会自动建库），否则报 database "restore_check" does not exist (SQLSTATE 3D000)。

7.2 恢复结果与源库核对

恢复任务状态查询与逐行核对（实测回显）：

恢复任务：{"status":"COMPLETED","restoreDurationMs":40,"failMessage":null}

恢复库 restore_check：SELECT (SELECT count(*) FROM customers), (SELECT count(*) FROM orders);
→ 200 | 1000
源库   appdb：       SELECT (SELECT count(*) FROM customers), (SELECT count(*) FROM orders);
→ 200 | 1000

抽查（恢复库）：
 id |  name   |       email
----+---------+--------------------
  1 | 客户_1  | user1@example.com
  2 | 客户_2  | user2@example.com
(与源库完全一致)

MySQL 侧同流程复测：恢复任务 COMPLETED，恢复库 customers=200, orders=1000，与源库一致。两引擎的加密备份均经过「密文 → 服务端解密 → 原生恢复工具 → 数据核对」全链路，恢复验证通过。

7.3 自动恢复验证（Restore Verification）

除手动演练外，Databasus 支持按计划自动做真实恢复验证：设置「Scheduled verification」（每次备份后 After backup，或 hourly/daily/weekly/monthly/cron），验证代理会把最新备份真实恢复到临时数据库、逐表清点行数并出报告，结果状态机为 Pending → Running → Successful / Failed / Canceled。同库新备份到达时，排队中的旧验证会被取消、只验最新一份，避免队列无限增长。验证代理的部署与预算参数见第十章 10.4。

八、通知渠道实测

本章以 Webhook 为例实测通知链路（Slack/Discord/Telegram/Teams/Mattermost/Email 配置方法同构）。

8.1 准备接收端与创建通知渠道

在可达的服务器上起一个极简 HTTP 接收器（记录 POST 头与载荷），实测监听 :8146：

# webhook_receiver.py 监听 8146，POST 内容落 webhook.log
python3 webhook_receiver.py 8146 &

控制台创建 Webhook 通知渠道（POST /api/v1/notifiers）：

{
  "name": "ops-webhook",
  "workspaceId": "fa0e4f67-6957-4cf6-b7c1-a8fd819c36ac",
  "notifierType": "WEBHOOK",
  "webhookNotifier": {
    "webhookUrl": "http://10.89.67.1:8146/databasus-hook",
    "webhookMethod": "POST",
    "headers": [],
    "skipTlsVerify": false
  }
}

注意请求体字段是 notifierType（响应中才显示为 type）；WEBHOOK 支持 POST/GET 两种投递方法与自定义 headers。创建后可先点「发送测试通知」验证连通性。

8.2 触发备份验证通知到达

在备份计划中把通知渠道与 BACKUP_SUCCESS / BACKUP_FAILED 事件绑定后触发备份，接收端实测收到：

POST /databasus-hook
Content-Type: application/json
User-Agent: Go-http-client/1.1

{"heading":"✅ Backup completed for database \"pg16-appdb\" (workspace \"prod-workspace\")",
 "message":"Backup completed successfully in 0m 0s.\nCompressed backup size: 0.01 MB"}

通知为备份完成事件实时推送，正文含数据库名、工作区、耗时与压缩后体积。通知实测中还发现一个网络细节：接收端端口若与其他服务冲突（本文首次选的 8143 已被其他组件的 SMTP 映射占用），Databasus 的报错会把对端返回的非 HTTP 响应原样带出（malformed HTTP status code），排查通知不通时先确认接收端端口确实空闲。

8.3 排障实录四：通知渠道 500 panic

现象：创建通知渠道时若把类型字段写成 type（响应字段名），服务端直接 500 空响应。

取证：服务日志 panic 栈显示 panic: unknown notifier type: ""（入口 internal/features/notifiers/model.go 的 getSpecificNotifier）。

结论：创建/更新请求体的类型字段名为 notifierType；直接调用 API 时务必使用该字段名，通过 Web UI 操作则无此问题。

九、定时策略与调度

本章汇总与定时执行相关的实测结论。

备份计划：逻辑与物理备份计划均可设 hourly/daily/weekly/monthly/cron；daily 及以上粒度需指定 UTC 时刻（如 04:00 即 UTC 凌晨 4 点），cron 为 UTC 时区表达式。计划保存后由内置调度器按计划自动触发，无需外部 crontab；
失败重试：isRetryIfFailed: true 且 maxFailedTriesCount: 3 时，失败任务自动重试最多 3 次；
保留策略自动清理：按 TIME_PERIOD/COUNT/GFS 设定的保留策略在每次备份后自动评估，过期备份自动删除，控制存储成本；
健康检查：按分钟级间隔探测数据库连通性，连续失败判定宕机并触发 HEALTHCHECK_FAILURE 通知，恢复时同样通知；
物理备份链：全量 + 块级增量 + WAL 持续流的组合支持 PITR（恢复到任意一秒），增量依赖 PostgreSQL 17 服务端 WAL 摘要（summarize_wal=on）；WAL 流延迟可通过 walLagThresholdBytes 阈值监控告警（WAL_GAP 事件）。

十、排障实录汇总与验证代理

本章汇总本文全部实测排障，并补充恢复验证代理的部署要点。

10.1 网段冲突

现象：docker compose up 报 invalid pool request: Pool overlaps with other one on this address space。原因：规划的 10.89.63.0/24 已被宿主机上其他业务网络占用。解决：docker network inspect 逐个复核既有网络网段，改用空闲的 10.89.67.0/24 后正常创建。多栈共存的服务器上划网段前务必先盘点。

10.2 pg_hba 拒绝复制连接

见 5.2。物理备份走复制协议，host all all all 不覆盖 replication 连接，必须显式添加 host replication <用户> <网段> <认证方式> 规则。

10.3 备份静默失败（storage ID 为 nil）

见 6.3。先绑定存储再触发备份；物理备份的存储绑定走独立端点。

10.4 恢复验证代理（Verification Agent）

自动恢复验证需要额外部署一个验证代理（小型 Go 二进制）——它从 Databasus 领取验证作业，在代理所在机器上拉起与目标引擎同大版本的临时数据库执行真实恢复并回传报告。部署要点：

前置条件：代理所在主机可出网访问 Databasus URL、有 Docker 环境（用于拉起临时库容器）、磁盘需容纳「备份文件体积 + 数据库原始体积 + 最多 5 GB 安全余量」、每并发作业至少 1 CPU + 512 MB 内存；
下载与启动（从实例直接分发，实测端点存在）：

curl -L -o verification-agent "http://<服务器IP>:8142/api/v1/system/verification-agent?arch=amd64" && chmod +x verification-agent
./verification-agent start \
  --databasus-host=http://<服务器IP>:8142 \
  --agent-id=<控制台生成的代理ID> \
  --token=<控制台一次性令牌> \
  --max-cpu=2 --max-ram-mb=2048 --max-disk-gb=20 --max-concurrent-jobs=1

四个 --max-* 是预算而非单作业配额，按并发作业均摊（下限单作业 1 CPU + 512 MB）；--databasus-host 必须为 https，纯 HTTP 本地测试需显式 --allow-insecure-http；
同一二进制提供 status / stop / start / run 四个子命令（run 为前台运行，适合 systemd 或容器托管）；令牌泄露可在控制台 Rotate token，旧令牌在代理下次心跳后失效。

十一、常见问题

首次启动很慢？ 官方说明首次启动最长约 2 分钟（初始化内部 PostgreSQL），健康检查 start_period 建议给足 120 秒；
端口 4005 已被占用？ 修改映射宿主端口即可（本文映射 8142），容器内端口保持 4005；
数据目录权限报错？ sudo chown -R $USER:$USER ./databasus-data && chmod -R 755 ./databasus-data；
升级怎么做？ 官方流程：docker compose stop → 清理旧镜像缓存 → 改镜像标签为下一版本后 docker compose up -d；升级前先备份 databasus-data（尤其 secret.key 与 pgdata/）；
如何从 Postgresus 迁移？ 官方明确「仅改镜像名不够」——Postgresus 与 Databasus 数据目录与内部库命名不同，需用新的卷路径全新安装 Databasus 后手工重建数据库、存储与通知配置，迁移期两者可并存；
忘记管理员密码？ 见 4.1 的 --new-password / --list-admins 控制台命令；
备份文件存到云端安全吗？ 备份 AES-256-GCM 加密落盘，零信任存储设计下云端泄露也不泄数据；但请务必单独保管 secret.key——没有它连自己都无法解密。

十二、参考链接

官方安装文档（Compose/Caddy/K8s 模板）：https://databasus.com/installation
官方恢复验证文档：https://databasus.com/restore-verification
官方安全文档：https://databasus.com/security
GitHub 仓库：https://github.com/databasus/databasus
站内同组件选型认知篇：《Databasus v3.63.1 介绍与选型指南》
站内同类工具部署参考：《BorgBackup Docker Compose 部署指南》、《Debian 13 安装 Backupninja 1.2.2 指南》、《Ubuntu 22.04 安装 pgBackRest 2.60.0 指南》