数据库灾备【免费下载链接】databasusPostgreSQL backup tool with Point-In-Time-Recovery and restore verification项目地址https://gitcode.com/gh_mirrors/po/databasus点击查看免费下载本文基于 Databasus 仓库中已归档的 OpenSpec 变更 2026-09-05-harden-docker-storage-compatibility完整拆解这次加固 Docker 存储兼容性工作的任务清单如何用一套 Bash 测试装置在真实容器内验证 bind mount、named volume、CIFS、NFS root squash 等挂载场景如何用镜像元数据声明服务账号身份以及如何用独立的 GitHub Actions 作业把该矩阵纳入发布流水线。读完本文你将掌握容器边界文件系统测试的设计方法用例矩阵怎么划分、负向用例如何断言、资源如何清理以及为什么生产代码只允许被可复现的缺陷驱动修改。背景为什么需要真实容器的存储测试Databasus 的 Docker 镜像同时运行 Databasus 应用与嵌入式 PostgreSQL 17两者共用/databasus-data数据根目录且以非 root 的系统账号运行见 Dockerfile 与 docker/start.sh。挂载的存储卷与镜像内部文件系统的行为往往不同数值属主UID/GID、NFS 的 root squash、CIFS 的用户映射、文件系统边界差异都是宿主侧的问题。同一变更下的 proposal.md 开宗明义Docker storage permission changes can work on one mount type and fail on another.也就是说一个权限改动可能在 bind mount 上通过、却在 CIFS 或 NFS 上失败。项目的解法是在镜像发布之前用同一套真实容器用例矩阵bind mount、Docker volume、CIFS、NFS、拆分挂载、数值属主在本地和 GitHub Actions 中各跑一遍。设计文档 design.md 进一步明确了测试边界——The test boundary is the shipped container被测对象就是交付出去的容器本身因此不需要为测试新增任何应用级诊断命令或第二套文件发布抽象。任务一把实现边界压到最小tasks.md 的第一组任务就立下约束后端本地存储模型与 PostgreSQL 凭据代码一行不改生产镜像里不新增诊断命令或仅供测试用的二进制生产入口脚本保持内联在 Dockerfile 中不引入外部 entrypoint 脚本、属主迁移状态机或跨版本升级夹具。这两条约束在仓库中都能得到印证Dockerfile 末尾直接COPY --chmod0755 docker/start.sh /app/start.sh并ENTRYPOINT [/app/start.sh]入口即单一脚本无额外启动器现有的两个启动防护/postgresus-data旧镜像名 Postgresus 的遗留数据目录与WAL_V1已废弃的 Agent 备份模式保持不变对应 docker/start.sh 的reject_legacy_postgresus_volume和 docker/start.sh 的reject_legacy_wal_configuration测试装置里也各有一个对应用例守护它们见下文。验证方式是零 diff检查git diff --exit-code -- backend必须通过且镜像内不出现新的诊断二进制。这确立了整次变更的基调测试先行生产改动只有在容器用例复现了缺陷后才被允许。任务二一个统一的文件系统测试装置任务 2.x 要求新增两个 Make 目标并让装置满足以下工程细节。当前仓库的 Makefile 仍然保留着这两个目标.PHONY: build-docker-storage-test-image test-filesystems DATABASUS_STORAGE_TEST_IMAGE ? databasus-storage-test:local build-docker-storage-test-image: docker build --tag $(DATABASUS_STORAGE_TEST_IMAGE) . test-filesystems: if [ -z $(DATABASUS_IMAGE) ]; then \ $(MAKE) build-docker-storage-test-image; \ fi DATABASUS_IMAGE$${DATABASUS_IMAGE:-$(DATABASUS_STORAGE_TEST_IMAGE)} \ CASE$(CASE) \ bash e2e/docker-storage/run.sh其语义是make build-docker-storage-test-image用根目录 Dockerfile 构建一个本地候选镜像databasus-storage-test:localmake test-filesystems在未指定DATABASUS_IMAGE时先自动构建随后把它连同CASE用例选择器传给 e2e/docker-storage/run.sh装置对每次运行生成唯一run_id所有 Docker 资源容器、卷、网络都打上com.databasus.storage-testrun_id标签通过trap cleanup EXIT在成功或失败路径上都能按标签精确清理见 run.sh 的harness_label与cleanup函数。用例的探测方式遵循 tasks.md 中 2.2 的描述直接用docker exec --user以被测账号进入容器对挂载路径执行创建唯一文件、写入、读取、删除四步操作全程不调用后端存储代码。以databasus和postgres当时的双账号模型两个身份分别探测。当前 run.sh 的run_case分发表仍然能看到这套正/负用例 网络前置检查的组织方式build-only | default-ids | custom-ids | maximum-ids | automatic-ids | empty-pgdata-ids | partial-ids | invalid-ids | bind-root | named-volume | split-mounts | metadata-changes-denied | read-only | wrong-owner | unwritable-data-root | network-prerequisites | cifs | nfs-root-squash | upgrades | legacy-directory-guard用例保持串行执行原因是 CIFS 与 NFS 夹具共享宿主机的挂载能力mount.cifs/mount.nfs且清理必须保持确定性design.md 决策 1。失败路径的断言同样精确assert_storage_permission_failurerun.sh不仅要求容器以非零码退出还要求日志中出现Databasus cannot write to ... as UID ... and GID ...、Required operation:、Set PUID and PGID or fix the mounted directory permissions:等可操作的错误信息并且确认失败后没有启动 PostgreSQL 或 Databasus 应用、没有残留探测文件。这正是负向用例也要可验证的落地方式。任务三用镜像元数据声明服务账号身份任务 3.1 是这次变更中最有特色的部分在 Docker 镜像元数据中声明四个身份变量——DATABASUS_PUID65532、DATABASUS_PGID65552之前的默认布局按 tasks.md 原文DATABASUS_PUID65532、DATABASUS_PGID65532、POSTGRES_PUID999、POSTGRES_PGID999并验证镜像环境与运行中容器的环境实际生效的账号 ID默认不做账号重映射no-remap显式覆盖仍然可用。其中默认不做重映射的验证手段很硬核default-ids用例会故意在groupmod和usermod上制造失败挂载失败命令因此如果启动脚本冗余地执行默认重映射容器会直接停摆用例随即失败。换言之默认路径不触碰账号工具是用故障注入证明的而不是靠代码审查。任务 3.2 则约束这些变量的文档边界它们不出现在.env.example、默认 Compose 配置、Helm values、Helm README、根 README 和安装页中只允许出现在全部六个 Advanced Configuration 文档页英文 五个本地化版本。仓库检索证据显示这四个变量名当时只出现在Dockerfile、文件系统装置、OpenSpec 文档与六个 Advanced Configuration 页中。值得注意的演进这一身份模型后来被进一步简化为单一运行时账号——当前 docker/start.sh 只接受一对PUID/PGID取值范围14294967294见validate_linux_idDatabasus 与嵌入式 PostgreSQL 共用名为databasus的非 root 账号当前镜像默认999:999见 Dockerfile 中groupmod/usermod将postgres账号改为 UID/GID 999 并改名databasus。英文文档页 website/app/(en)/advanced-config/page.tsx/advanced-config/page.tsx#L401-L443) 明确写道The previous four service-specific identity variables were deliberately removed。本文所述四个变量是 2026-09-05 变更时点的设计阅读当前代码时请注意这一演进。任务四文件系统与权限矩阵这是整个变更的主体。任务 4.x 要求矩阵覆盖健康用例 拒绝用例 真实网络文件系统 问题清单审计四个层面且只修复被这些用例复现的 Dockerfile 或内联入口缺陷4.5不改动后端本地存储行为。健康用例三种本地存储布局bind-root把宿主目录以正确属主绑定挂载为整个/databasus-data数据根named-volume使用 Docker 命名卷作为数据根split-mounts应用文件、临时文件、备份、PostgreSQL 数据分别来自不同挂载点。当前 run.sh 的实现很有代表性数据根用命名卷、temp用--tmpfsuid999,gid999,mode0700、backups与pgdata各用独立命名卷并断言 temp 与 backups 的设备号不同从而真正验证了跨文件系统的写路径spec 中对应LocalStorage.SaveFile的跨文件系统成功场景。拒绝用例只读与不可访问路径read-only把数据根以readonly绑定挂载断言容器以非零码退出inaccessible-path当前装置中对应wrong-owner/unwritable-data-root构造属主不匹配且丢弃CHOWN/FOWNER/DAC_OVERRIDE能力的场景断言 Databasus 账号遭遇预期权限拒绝并且日志给出精确的Required operation:描述如save a file through local storage.、create, read, and remove a required file.。这两类用例验证的是 docker/start.sh 中report_storage_error输出的可操作错误格式给出路径、生效的 UID/GID、所需操作以及文档链接https://databasus.com/advanced-config/#docker-storage-permissions。真实 CIFS 与 root-squashed NFS 用例任务 4.3 要求真实的网络文件系统而非 mock前置检查run_network_prerequisitesrun.sh确认宿主机装有mount.cifs与mount.nfs并按digest 钉住拉取两个服务端夹具镜像dockurr/sambasha256:dbd8ebd...、itsthenetwork/nfs-server-alpinesha256:7fa99ae...保证用例可复现cifsrun.sh起 Samba 服务容器再用docker volume create --driver local --opt typecifs创建 CIFS 卷挂载为/databasus-data/backups挂载参数强制uid0,gid999,file_mode0660,dir_mode0770。用例断言挂载点呈现实为 root 属主 组 999 模式 770然后以databasus身份写一个文件并验证其模式被强制为 660——即启动时跳过 root UID、通过组 999 写回这一设计在真实 CIFS 上成立nfs-root-squashrun.sh起 NFS 服务容器并显式把no_root_squash改回root_squashsed -i s/no_root_squash/root_squash/ /etc/exports先用特权容器尝试chown 1:1验证 root squash 确实生效容器 root 的属主修改被拒绝再以 NFS 卷作为数据根启动 Databasuspgdata用本地命名卷、pgsocket与temp用 tmpfs。关键点启动流程不能依赖 chown/chmod 成功——normalize_data_permissions全部是2/dev/null || true的尽力而为start.sh只要所选账号能完成所有必需操作即可启动。用例随后把容器销毁重启两次验证幂等。问题清单审计每个 issue 都必须入矩阵或有精确排除理由任务 4.4 要求审计所有与 Docker 文件系统和权限相关的开放与已关闭issue并把每一份容器边界报告映射到一个用例无法映射的必须记录精确的排除理由。当时的清单记录在e2e/docker-storage/run.sh的注释清单中映射了 #45、#64、#141、#224、#274、#478、#738、#751、#763 九个问题排除项及理由#96、#199需要任意容器用户同时启动两个服务与单一非 root 账号模型冲突无法在容器边界复现#401、#431涉及应用层的传输行为备份发布策略而非容器权限由 design.md 明确列为 Non-Goalthis change does not alter or duplicate that code。这个映射或排除map or exclude with a precise reason的做法值得借鉴它把散落的 issue 债务转化成了可执行的测试矩阵加一份有据可查的例外清单避免了测了一堆却说不清为什么。只修复被复现的入口缺陷任务 4.5 的证据列出了矩阵实际驱动出的入口修正全部集中在 Dockerfile/内联入口层面声明四个身份变量、默认跳过重映射、对预属主挂载做浅层尽力而为的属主准备只修复已知的 root 级应用文件而不是遍历整棵挂载树、把进程TMPDIR固定在/tmp——对应 docker/start.sh 的export TMPDIR/tmp。后端文件零改动。任务五CI 独立作业与最终验证任务 5.1 要求新增一个独立的test-filesystemsGitHub Actions 作业约束非常具体该作业自己构建并docker load一个 amd64 候选镜像push: false不发布、不跨作业传输镜像每个 Action 都钉到完整 commit SHA并附版本注释顶层权限保持permissions: contents: read且作业内不提升push: false发布与开发镜像的推送路径都必须needs该作业用 Actionlint 与直接权限/依赖检查验证 workflow。当前仓库的 .github/workflows/ci-release.yml 保留了这条依赖链test-filesystems:作业定义在第 350 行run: make test-filesystems在第 379 行而两处发布路径的needs列表第 517 行、第 771 行均包含test-filesystems——也就是说文件系统矩阵不通过任何镜像都不会被推送。作业内部还会安装 CIFS/NFS 客户端cifs-utils、nfs-common以满足网络用例的前置条件。任务 5.2 是收尾验证运行定向用例与完整矩阵DATABASUS_IMAGEdatabasus-storage-test:local make test-filesystems跑通 Dockerfile、shell、Compose、Helm、workflow、website、OpenSpec 全部校验确认运行后零残留的带标签 Docker 资源与 2.1 的清理要求闭环并获得评审人PASS。从源码结构看当前装置比变更时点还多了automatic-ids从挂载属主自动推导身份、empty-pgdata-ids、partial-ids只覆盖一半变量、invalid-ids空值、0、非数字、4294967295越界、超大数均须以ERROR: PUID must be a non-zero decimal Linux ID退出、upgradesv3.54.0 → 当前镜像的数据可用性升级与legacy-directory-guard等用例属于同一设计在后续变更中的自然生长。配套规格docker-storage-compatibility该变更沉淀出的能力规格位于 openspec/specs/docker-storage-compatibility/spec.md把实现约束升级为可引用的行为要求核心条款包括单一可配置运行时身份容器内所有捆绑服务共用一个非 root 账号自动选 ID 的优先级为现有 PostgreSQL 数据属主 → 备份/数据根挂载属主 → 兜底 999且绝不自动选择 root 属主启动期存储验证必须走必需操作本身chown/chmod失败不应阻止启动只要所选账号能完成全部必需操作但任何必需操作失败必须在 PostgreSQL 与应用启动前终止容器并输出含路径、操作、UID/GID 与文档链接的英文错误升级可用性v3.54.0v3.56.0生成的持久化数据在镜像更新后必须保持可用元数据库、密钥、日志、备份、可续传的嵌套 WAL 队列、PostgreSQL 集群兼容数据防护检测到旧/postgresus-data数据或WAL_V1备份配置时必须拒绝启动——这两个 guard 至今仍在 docker/start.sh 的main流程首尾位置并有对应用例持续守护单一入口make test-filesystems本地与 CI 跑同一套用例每个用例自清理其容器、卷、网络、挂载与临时文件。小结这次变更的方法论可以浓缩为四条可复用的原则测试边界即交付边界——直接启动真实镜像、用docker exec --user探测不为测试加诊断后门backend 目录保持零 diff矩阵 健康布局 拒绝布局 真实网络文件系统 问题清单映射每个 issue 要么有对应用例要么有书面排除理由生产改动由复现驱动——只有read-only、wrong-owner、cifs、nfs-root-squash这类用例暴露的缺陷才允许进入 entrypoint/Dockerfile修复也保持浅层与尽力而为TMPDIR固定、浅层属主准备CI 作业自包含——自己构建、自己load、不发布候选镜像并以needs成为镜像发布的硬前置配合标签化资源清理保证零残留。如果你想继续深入建议从 e2e/docker-storage/run.sh 的用例实现、docker/start.sh 的启动验证流程configure_runtime_identity→prepare_and_verify_storage→ PostgreSQL 引导以及 openspec/specs/docker-storage-compatibility/spec.md 的规格条目按序阅读三者恰好对应本文怎么测、为什么这样启动、承诺了什么行为三个层面。赞分享数据库灾备【免费下载链接】databasusPostgreSQL backup tool with Point-In-Time-Recovery and restore verification项目地址https://gitcode.com/gh_mirrors/po/databasus点击查看免费下载相关推荐Databasus Docker 存储兼容性加固用真实容器测试矩阵守住挂载点边界Databasus Docker 存储兼容性加固用真实容器测试矩阵守住挂载点边界 Databasus 把应用、内嵌 PostgreSQL 和备份数据全部放在同数据库灾备Databasus为 Docker 存储兼容性建立真实容器测试矩阵Databasus为 Docker 存储兼容性建立真实容器测试矩阵 本文基于 Databasus 仓库中已归档的变更提案 proposal.md https:数据库灾备Databasus Docker 存储兼容性规范详解用真实容器文件系统测试覆盖每一种挂载布局Databasus Docker 存储兼容性规范详解用真实容器文件系统测试覆盖每一种挂载布局 本文围绕 Databasus 仓库中归档的 OpenSpec 需数据库灾备上一篇终极AirConnect音频编码指南MP3、AAC、FLAC如何选择最适合你的设备下一篇PDF对比神器diff-pdf让文档差异一目了然创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Databasus Docker 存储兼容性加固：一套在真实容器边界验证挂载、属主与权限的端到端测试矩阵
数据库灾备【免费下载链接】databasusPostgreSQL backup tool with Point-In-Time-Recovery and restore verification项目地址https://gitcode.com/gh_mirrors/po/databasus点击查看免费下载本文基于 Databasus 仓库中已归档的 OpenSpec 变更 2026-09-05-harden-docker-storage-compatibility完整拆解这次加固 Docker 存储兼容性工作的任务清单如何用一套 Bash 测试装置在真实容器内验证 bind mount、named volume、CIFS、NFS root squash 等挂载场景如何用镜像元数据声明服务账号身份以及如何用独立的 GitHub Actions 作业把该矩阵纳入发布流水线。读完本文你将掌握容器边界文件系统测试的设计方法用例矩阵怎么划分、负向用例如何断言、资源如何清理以及为什么生产代码只允许被可复现的缺陷驱动修改。背景为什么需要真实容器的存储测试Databasus 的 Docker 镜像同时运行 Databasus 应用与嵌入式 PostgreSQL 17两者共用/databasus-data数据根目录且以非 root 的系统账号运行见 Dockerfile 与 docker/start.sh。挂载的存储卷与镜像内部文件系统的行为往往不同数值属主UID/GID、NFS 的 root squash、CIFS 的用户映射、文件系统边界差异都是宿主侧的问题。同一变更下的 proposal.md 开宗明义Docker storage permission changes can work on one mount type and fail on another.也就是说一个权限改动可能在 bind mount 上通过、却在 CIFS 或 NFS 上失败。项目的解法是在镜像发布之前用同一套真实容器用例矩阵bind mount、Docker volume、CIFS、NFS、拆分挂载、数值属主在本地和 GitHub Actions 中各跑一遍。设计文档 design.md 进一步明确了测试边界——The test boundary is the shipped container被测对象就是交付出去的容器本身因此不需要为测试新增任何应用级诊断命令或第二套文件发布抽象。任务一把实现边界压到最小tasks.md 的第一组任务就立下约束后端本地存储模型与 PostgreSQL 凭据代码一行不改生产镜像里不新增诊断命令或仅供测试用的二进制生产入口脚本保持内联在 Dockerfile 中不引入外部 entrypoint 脚本、属主迁移状态机或跨版本升级夹具。这两条约束在仓库中都能得到印证Dockerfile 末尾直接COPY --chmod0755 docker/start.sh /app/start.sh并ENTRYPOINT [/app/start.sh]入口即单一脚本无额外启动器现有的两个启动防护/postgresus-data旧镜像名 Postgresus 的遗留数据目录与WAL_V1已废弃的 Agent 备份模式保持不变对应 docker/start.sh 的reject_legacy_postgresus_volume和 docker/start.sh 的reject_legacy_wal_configuration测试装置里也各有一个对应用例守护它们见下文。验证方式是零 diff检查git diff --exit-code -- backend必须通过且镜像内不出现新的诊断二进制。这确立了整次变更的基调测试先行生产改动只有在容器用例复现了缺陷后才被允许。任务二一个统一的文件系统测试装置任务 2.x 要求新增两个 Make 目标并让装置满足以下工程细节。当前仓库的 Makefile 仍然保留着这两个目标.PHONY: build-docker-storage-test-image test-filesystems DATABASUS_STORAGE_TEST_IMAGE ? databasus-storage-test:local build-docker-storage-test-image: docker build --tag $(DATABASUS_STORAGE_TEST_IMAGE) . test-filesystems: if [ -z $(DATABASUS_IMAGE) ]; then \ $(MAKE) build-docker-storage-test-image; \ fi DATABASUS_IMAGE$${DATABASUS_IMAGE:-$(DATABASUS_STORAGE_TEST_IMAGE)} \ CASE$(CASE) \ bash e2e/docker-storage/run.sh其语义是make build-docker-storage-test-image用根目录 Dockerfile 构建一个本地候选镜像databasus-storage-test:localmake test-filesystems在未指定DATABASUS_IMAGE时先自动构建随后把它连同CASE用例选择器传给 e2e/docker-storage/run.sh装置对每次运行生成唯一run_id所有 Docker 资源容器、卷、网络都打上com.databasus.storage-testrun_id标签通过trap cleanup EXIT在成功或失败路径上都能按标签精确清理见 run.sh 的harness_label与cleanup函数。用例的探测方式遵循 tasks.md 中 2.2 的描述直接用docker exec --user以被测账号进入容器对挂载路径执行创建唯一文件、写入、读取、删除四步操作全程不调用后端存储代码。以databasus和postgres当时的双账号模型两个身份分别探测。当前 run.sh 的run_case分发表仍然能看到这套正/负用例 网络前置检查的组织方式build-only | default-ids | custom-ids | maximum-ids | automatic-ids | empty-pgdata-ids | partial-ids | invalid-ids | bind-root | named-volume | split-mounts | metadata-changes-denied | read-only | wrong-owner | unwritable-data-root | network-prerequisites | cifs | nfs-root-squash | upgrades | legacy-directory-guard用例保持串行执行原因是 CIFS 与 NFS 夹具共享宿主机的挂载能力mount.cifs/mount.nfs且清理必须保持确定性design.md 决策 1。失败路径的断言同样精确assert_storage_permission_failurerun.sh不仅要求容器以非零码退出还要求日志中出现Databasus cannot write to ... as UID ... and GID ...、Required operation:、Set PUID and PGID or fix the mounted directory permissions:等可操作的错误信息并且确认失败后没有启动 PostgreSQL 或 Databasus 应用、没有残留探测文件。这正是负向用例也要可验证的落地方式。任务三用镜像元数据声明服务账号身份任务 3.1 是这次变更中最有特色的部分在 Docker 镜像元数据中声明四个身份变量——DATABASUS_PUID65532、DATABASUS_PGID65552之前的默认布局按 tasks.md 原文DATABASUS_PUID65532、DATABASUS_PGID65532、POSTGRES_PUID999、POSTGRES_PGID999并验证镜像环境与运行中容器的环境实际生效的账号 ID默认不做账号重映射no-remap显式覆盖仍然可用。其中默认不做重映射的验证手段很硬核default-ids用例会故意在groupmod和usermod上制造失败挂载失败命令因此如果启动脚本冗余地执行默认重映射容器会直接停摆用例随即失败。换言之默认路径不触碰账号工具是用故障注入证明的而不是靠代码审查。任务 3.2 则约束这些变量的文档边界它们不出现在.env.example、默认 Compose 配置、Helm values、Helm README、根 README 和安装页中只允许出现在全部六个 Advanced Configuration 文档页英文 五个本地化版本。仓库检索证据显示这四个变量名当时只出现在Dockerfile、文件系统装置、OpenSpec 文档与六个 Advanced Configuration 页中。值得注意的演进这一身份模型后来被进一步简化为单一运行时账号——当前 docker/start.sh 只接受一对PUID/PGID取值范围14294967294见validate_linux_idDatabasus 与嵌入式 PostgreSQL 共用名为databasus的非 root 账号当前镜像默认999:999见 Dockerfile 中groupmod/usermod将postgres账号改为 UID/GID 999 并改名databasus。英文文档页 website/app/(en)/advanced-config/page.tsx/advanced-config/page.tsx#L401-L443) 明确写道The previous four service-specific identity variables were deliberately removed。本文所述四个变量是 2026-09-05 变更时点的设计阅读当前代码时请注意这一演进。任务四文件系统与权限矩阵这是整个变更的主体。任务 4.x 要求矩阵覆盖健康用例 拒绝用例 真实网络文件系统 问题清单审计四个层面且只修复被这些用例复现的 Dockerfile 或内联入口缺陷4.5不改动后端本地存储行为。健康用例三种本地存储布局bind-root把宿主目录以正确属主绑定挂载为整个/databasus-data数据根named-volume使用 Docker 命名卷作为数据根split-mounts应用文件、临时文件、备份、PostgreSQL 数据分别来自不同挂载点。当前 run.sh 的实现很有代表性数据根用命名卷、temp用--tmpfsuid999,gid999,mode0700、backups与pgdata各用独立命名卷并断言 temp 与 backups 的设备号不同从而真正验证了跨文件系统的写路径spec 中对应LocalStorage.SaveFile的跨文件系统成功场景。拒绝用例只读与不可访问路径read-only把数据根以readonly绑定挂载断言容器以非零码退出inaccessible-path当前装置中对应wrong-owner/unwritable-data-root构造属主不匹配且丢弃CHOWN/FOWNER/DAC_OVERRIDE能力的场景断言 Databasus 账号遭遇预期权限拒绝并且日志给出精确的Required operation:描述如save a file through local storage.、create, read, and remove a required file.。这两类用例验证的是 docker/start.sh 中report_storage_error输出的可操作错误格式给出路径、生效的 UID/GID、所需操作以及文档链接https://databasus.com/advanced-config/#docker-storage-permissions。真实 CIFS 与 root-squashed NFS 用例任务 4.3 要求真实的网络文件系统而非 mock前置检查run_network_prerequisitesrun.sh确认宿主机装有mount.cifs与mount.nfs并按digest 钉住拉取两个服务端夹具镜像dockurr/sambasha256:dbd8ebd...、itsthenetwork/nfs-server-alpinesha256:7fa99ae...保证用例可复现cifsrun.sh起 Samba 服务容器再用docker volume create --driver local --opt typecifs创建 CIFS 卷挂载为/databasus-data/backups挂载参数强制uid0,gid999,file_mode0660,dir_mode0770。用例断言挂载点呈现实为 root 属主 组 999 模式 770然后以databasus身份写一个文件并验证其模式被强制为 660——即启动时跳过 root UID、通过组 999 写回这一设计在真实 CIFS 上成立nfs-root-squashrun.sh起 NFS 服务容器并显式把no_root_squash改回root_squashsed -i s/no_root_squash/root_squash/ /etc/exports先用特权容器尝试chown 1:1验证 root squash 确实生效容器 root 的属主修改被拒绝再以 NFS 卷作为数据根启动 Databasuspgdata用本地命名卷、pgsocket与temp用 tmpfs。关键点启动流程不能依赖 chown/chmod 成功——normalize_data_permissions全部是2/dev/null || true的尽力而为start.sh只要所选账号能完成所有必需操作即可启动。用例随后把容器销毁重启两次验证幂等。问题清单审计每个 issue 都必须入矩阵或有精确排除理由任务 4.4 要求审计所有与 Docker 文件系统和权限相关的开放与已关闭issue并把每一份容器边界报告映射到一个用例无法映射的必须记录精确的排除理由。当时的清单记录在e2e/docker-storage/run.sh的注释清单中映射了 #45、#64、#141、#224、#274、#478、#738、#751、#763 九个问题排除项及理由#96、#199需要任意容器用户同时启动两个服务与单一非 root 账号模型冲突无法在容器边界复现#401、#431涉及应用层的传输行为备份发布策略而非容器权限由 design.md 明确列为 Non-Goalthis change does not alter or duplicate that code。这个映射或排除map or exclude with a precise reason的做法值得借鉴它把散落的 issue 债务转化成了可执行的测试矩阵加一份有据可查的例外清单避免了测了一堆却说不清为什么。只修复被复现的入口缺陷任务 4.5 的证据列出了矩阵实际驱动出的入口修正全部集中在 Dockerfile/内联入口层面声明四个身份变量、默认跳过重映射、对预属主挂载做浅层尽力而为的属主准备只修复已知的 root 级应用文件而不是遍历整棵挂载树、把进程TMPDIR固定在/tmp——对应 docker/start.sh 的export TMPDIR/tmp。后端文件零改动。任务五CI 独立作业与最终验证任务 5.1 要求新增一个独立的test-filesystemsGitHub Actions 作业约束非常具体该作业自己构建并docker load一个 amd64 候选镜像push: false不发布、不跨作业传输镜像每个 Action 都钉到完整 commit SHA并附版本注释顶层权限保持permissions: contents: read且作业内不提升push: false发布与开发镜像的推送路径都必须needs该作业用 Actionlint 与直接权限/依赖检查验证 workflow。当前仓库的 .github/workflows/ci-release.yml 保留了这条依赖链test-filesystems:作业定义在第 350 行run: make test-filesystems在第 379 行而两处发布路径的needs列表第 517 行、第 771 行均包含test-filesystems——也就是说文件系统矩阵不通过任何镜像都不会被推送。作业内部还会安装 CIFS/NFS 客户端cifs-utils、nfs-common以满足网络用例的前置条件。任务 5.2 是收尾验证运行定向用例与完整矩阵DATABASUS_IMAGEdatabasus-storage-test:local make test-filesystems跑通 Dockerfile、shell、Compose、Helm、workflow、website、OpenSpec 全部校验确认运行后零残留的带标签 Docker 资源与 2.1 的清理要求闭环并获得评审人PASS。从源码结构看当前装置比变更时点还多了automatic-ids从挂载属主自动推导身份、empty-pgdata-ids、partial-ids只覆盖一半变量、invalid-ids空值、0、非数字、4294967295越界、超大数均须以ERROR: PUID must be a non-zero decimal Linux ID退出、upgradesv3.54.0 → 当前镜像的数据可用性升级与legacy-directory-guard等用例属于同一设计在后续变更中的自然生长。配套规格docker-storage-compatibility该变更沉淀出的能力规格位于 openspec/specs/docker-storage-compatibility/spec.md把实现约束升级为可引用的行为要求核心条款包括单一可配置运行时身份容器内所有捆绑服务共用一个非 root 账号自动选 ID 的优先级为现有 PostgreSQL 数据属主 → 备份/数据根挂载属主 → 兜底 999且绝不自动选择 root 属主启动期存储验证必须走必需操作本身chown/chmod失败不应阻止启动只要所选账号能完成全部必需操作但任何必需操作失败必须在 PostgreSQL 与应用启动前终止容器并输出含路径、操作、UID/GID 与文档链接的英文错误升级可用性v3.54.0v3.56.0生成的持久化数据在镜像更新后必须保持可用元数据库、密钥、日志、备份、可续传的嵌套 WAL 队列、PostgreSQL 集群兼容数据防护检测到旧/postgresus-data数据或WAL_V1备份配置时必须拒绝启动——这两个 guard 至今仍在 docker/start.sh 的main流程首尾位置并有对应用例持续守护单一入口make test-filesystems本地与 CI 跑同一套用例每个用例自清理其容器、卷、网络、挂载与临时文件。小结这次变更的方法论可以浓缩为四条可复用的原则测试边界即交付边界——直接启动真实镜像、用docker exec --user探测不为测试加诊断后门backend 目录保持零 diff矩阵 健康布局 拒绝布局 真实网络文件系统 问题清单映射每个 issue 要么有对应用例要么有书面排除理由生产改动由复现驱动——只有read-only、wrong-owner、cifs、nfs-root-squash这类用例暴露的缺陷才允许进入 entrypoint/Dockerfile修复也保持浅层与尽力而为TMPDIR固定、浅层属主准备CI 作业自包含——自己构建、自己load、不发布候选镜像并以needs成为镜像发布的硬前置配合标签化资源清理保证零残留。如果你想继续深入建议从 e2e/docker-storage/run.sh 的用例实现、docker/start.sh 的启动验证流程configure_runtime_identity→prepare_and_verify_storage→ PostgreSQL 引导以及 openspec/specs/docker-storage-compatibility/spec.md 的规格条目按序阅读三者恰好对应本文怎么测、为什么这样启动、承诺了什么行为三个层面。赞分享数据库灾备【免费下载链接】databasusPostgreSQL backup tool with Point-In-Time-Recovery and restore verification项目地址https://gitcode.com/gh_mirrors/po/databasus点击查看免费下载相关推荐Databasus Docker 存储兼容性加固用真实容器测试矩阵守住挂载点边界Databasus Docker 存储兼容性加固用真实容器测试矩阵守住挂载点边界 Databasus 把应用、内嵌 PostgreSQL 和备份数据全部放在同数据库灾备Databasus为 Docker 存储兼容性建立真实容器测试矩阵Databasus为 Docker 存储兼容性建立真实容器测试矩阵 本文基于 Databasus 仓库中已归档的变更提案 proposal.md https:数据库灾备Databasus Docker 存储兼容性规范详解用真实容器文件系统测试覆盖每一种挂载布局Databasus Docker 存储兼容性规范详解用真实容器文件系统测试覆盖每一种挂载布局 本文围绕 Databasus 仓库中归档的 OpenSpec 需数据库灾备上一篇终极AirConnect音频编码指南MP3、AAC、FLAC如何选择最适合你的设备下一篇PDF对比神器diff-pdf让文档差异一目了然创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考