★ FEATURED ARTICLE 1. 经期记录为什么值得从云端搬回自己家做自托管这些年被问得最多的一类需求是这个 App 能不能不进云。健身、记账、书签、RSS 都有人问过但真正让我认真坐下来研究部署方案的是经期追踪这一块。原因很简单它记录的不是行为而是身体状态而且是一份连续数年、时间戳密集、可被用于反推大量衍生信息的状态流。一旦这份数据落在某个第三方服务的数据库里你能控制的就只有要不要继续用而不是数据在哪儿、被谁看过、留存多久。自托管经期追踪这件事的核心价值说到底不是省钱也不是折腾而是把一份长期积累的个人健康记录的所有权从服务方的条款变成你自己硬盘上的文件。Ovumcy 就是这样一个可以完全跑在自己机器上的工具容器化交付数据落在本地卷里不上传、不同步、不依赖任何外部账号体系。我写这篇东西目标读者是三类人手上有 NAS 或闲置小主机、想给家人搭一套私密记录工具的人对个人数据流向比较在意、愿意花两小时配置一次换十年安心的人以及只是想看看自托管一个健康类应用到底要处理哪些边角问题的人。不需要你会写代码但需要你愿意读日志、改配置文件、想清楚备份到底放在哪。第三类问题是最容易被忽略的后面会专门用一章来讲。先说清楚一件事自托管不是万灵药。它把数据泄露的风险从一个集中的服务方转移到了你自己的运维水平上。硬盘会坏容器会挂配置会写错公网暴露会被人扫。所以这篇文章不会只告诉你三条命令跑起来就完事而是把选型、部署、访问控制、备份、排错这几段完整走一遍顺带把我在类似项目上踩过的坑提前摊开。你按这个流程走大概率两小时内能有一套能长期用、能恢复、能搬家的实例。2. 承载方式的现实取舍旧笔记本、迷你主机还是家用 NAS2.1 三种常见路径的真实差异部署前的第一个决策不是装什么系统而是跑在哪台机器上。这个决定影响后面所有环节包括备份策略、访问方式、以及你半夜被吵醒去插电源的概率。我把常见的三种路径拉出来对比一下都是我在不同场景里实际用过的。承载方式优点明显短板适合谁闲置笔记本或旧台式机零成本性能绰绰有余本地磁盘直连功耗偏高休眠/断电策略要手动关硬盘多为机械盘想先试水、不确定是否长期用的人低功耗迷你主机体积小、常年开机成本低、系统干净好重装通常只有单盘位或双盘位需要外接存储做备份已有一定运维习惯、追求长期在线的人家用 NAS存储冗余现成、快照与备份体系完善、断电恢复稳定容器权限模型较绕部分型号的套件层会额外占用端口家里已经有 NAS、想统一入口的人从实际体验讲我更推荐迷你主机或 NAS不是因为性能而是因为常年在线这件事本身就是自托管服务的一部分。经期记录类应用的使用频次很碎——可能一天打开两次也可能一周一次。如果承载设备经常处于关机状态体验会迅速崩塌最后你还是会退回手机备忘录。所以选型的第一原则不是便宜是开机率。另一个常被忽略的点是时钟。日期记录类应用对时间极其敏感一次系统时间漂移就可能导致今天被记成昨天或者跨零点录入的记录挂到错误日期上。NAS 和正规迷你主机通常自带 RTC 电池并默认开启网络时间同步旧笔记本的电池一旦没电每次断电重启时间都会回到出厂值。如果你的设备有这个问题务必先确认时间同步服务处于启用状态再动部署。2.2 磁盘、内存与长期运行的余量估算Ovumcy 这类应用的资源画像很轻单个用户、每天几十次读写、数据量以 KB 到 MB 计。给它分 512MB 到 1GB 内存、1 核 CPU 就够跑得很舒服。相比 CPU 和内存真正要想清楚的是磁盘规划因为这里牵扯到数据安全和恢复能力。我的习惯是至少分出三个逻辑区域配置区容器编排文件、环境变量文件、自定义的样式或语言包。体积小但丢了就得重配建议纳入版本管理。数据区数据库文件、上传的附件比如检查单照片如果你的版本支持。这是核心需要独立的备份链路。备份区至少一份异于数据区的物理位置。可以是同一台机器的另一块盘但更稳妥的是另一台设备或离线介质。这里有个坑值得提前说很多人把备份和数据放在同一个 RAID 阵列里然后认为我有冗余了。RAID 防的是单盘损坏不防误删、不防文件系统损坏、不防容器把卷写坏。我在一个模拟项目里就见过容器启动参数写错把挂载路径指向了空目录导致应用初始化了一个全新空库而所谓备份就在旁边同一个阵列里同步脚本还很勤快地把空库覆盖了过去。备份必须能回到过去所以要么做带版本的历史快照要么做异地副本单一镜像式同步不算备份。3. 从零把 Ovumcy 跑起来容器编排的逐段拆解3.1 目录结构与持久化卷的前置设计先建目录别急着拉镜像。目录结构定得好后面备份、迁移、排错会省一半力气。我常用的布局是这样/opt/ovumcy/ ├── compose.yaml ├── .env ├── data/ # 数据库与附件必须持久化 ├── config/ # 应用配置、自定义项 └── logs/ # 应用日志便于排查权限这块要提前处理。容器内的进程通常以非 root 用户运行如果宿主目录权限是 root:root 且 755容器写不进去表现就是启动了但一录入就报错或者重启后数据消失。稳妥做法是先确认镜像文档里声明的 UID/GID然后把data和logs的属主改成对应值。如果拿不准临时给 775 并保证所属组匹配也比直接 777 强——777 在多人使用的机器上等于把数据敞开。.env文件用来存不该写进编排文件的变量比如数据库密码、会话密钥、初始管理员账号。这个文件要单独设置权限600并且不要放进任何会自动同步到别处的目录。# .env 示例字段名按你实际镜像的环境变量调整 APP_BASE_URLhttps://records.home.lan APP_SECRET换成你自己的随机长字符串 DB_PASSWORD换成你自己的随机长字符串 TZAsia/ShanghaiTZ这一行看着不起眼实际上是整篇文章里最容易出事的一行后面第 6 章会用一整节讲它。先记住容器时区和宿主时区必须一致且都要是带地区的完整时区名不要写 UTC8 这种偏移量形式。3.2 compose 文件里每一段在解决什么问题下面这份编排是基于同类自托管应用的常见结构写的字段名请对照你实际拿到的镜像说明微调。重点不在照抄而在理解每一行的意图。services: ovumcy: image: ovumcy:latest container_name: ovumcy restart: unless-stopped ports: - 127.0.0.1:8080:8080 environment: - TZ${TZ} - APP_BASE_URL${APP_BASE_URL} - APP_SECRET${APP_SECRET} - DB_PASSWORD${DB_PASSWORD} volumes: - ./data:/app/data - ./config:/app/config - ./logs:/app/logs healthcheck: test: [CMD, wget, -qO-, http://127.0.0.1:8080/health] interval: 30s timeout: 5s retries: 3几个关键点值得单独说ports前面加127.0.0.1:是我最想强调的一行。不加这个前缀端口会绑定到所有网卡同一网络里任何人都能直接访问。加上之后只有本机能连外部访问必须经过你配置的网关层这样你才有机会加 TLS 和访问控制。这一步的成本是四个字符收益是把攻击面收窄一个数量级。restart: unless-stopped而不是always。区别在于你手动停掉容器做维护时always会在某些情况下把它拉起来unless-stopped会尊重你的手动意图。对需要偶尔停机做备份的服务来说这个语义更符合预期。卷挂载用相对路径而不是命名卷。命名卷在迁移时容易漏掉而相对路径对应的就是当前目录下的文件夹tar一下就能整体搬走。对单机单服务的场景可迁移性比抽象层次更重要。healthcheck不是必须的但强烈建议加上。它的价值在于让编排层知道进程活着和服务可用是两件事。有些故障下容器状态是 running但应用已经无法响应请求没有健康检查你就只能靠用户报错才发现。启动流程cd /opt/ovumcy docker compose pull docker compose up -d docker compose logs -f --tail100日志里出现监听端口的提示、以及数据库初始化完成的记录基本就绪。如果卡在数据库连接上先查.env里的密码有没有多空格再查数据目录权限。3.3 初始化之后先做这三件事别急着录入服务起来、浏览器能打开登录页这时候别急着开始记数据。有三件事必须先做完否则后面改动成本会高很多。第一建管理员账号并立刻改掉默认凭据。如果镜像支持首次访问引导创建账号走引导流程如果内置了默认账号登录后第一件事就是改密码并且确认密码长度和复杂度。这类应用往往没有二次验证密码就是唯一门锁。第二确认应用内时区与显示格式。进去之后找设置页看今天是哪天看历史记录的日期边界是否正确。同时确认周起始日、日期格式这些显示项这些不影响数据正确性但影响你每天的阅读体验早设定早省心。第三走一遍完整的写入—读取—导出链路。随便录一条今天的记录刷新页面确认还在然后找到导出功能导出一份完整数据。这份导出文件是你在任何灾难场景下的最后一道保险。如果导出功能不可用或者只导出一部分字段这就是一个必须在正式使用前解决的阻塞问题不要拖到积累了半年数据之后才发现。4. 让访问既方便又不敞开的四层防护4.1 本地域名与证书从点继续访问到绿色小锁自托管应用最容易妥协的一环是 HTTPS。很多人图省事直接用http://192.168.x.x:8080访问觉得反正只在家里。问题在于浏览器对非安全上下文有限制剪贴板、通知、部分 PWA 能力都不可用更重要的是明文传输意味着同一网络内的设备可以通过抓包看到你的所有记录内容。哪怕只在家里这也和数据自主掌控的初衷相悖。我的建议是配置一个本地域名比如records.home.lan然后通过前置网关统一处理 TLS。域名解析这一层如果你家里有能做本地 DNS 的设备就配置一条 A 记录指向服务主机没有的话在客户端 hosts 文件里加一行也能用只是每台设备都要改。证书有两条路方案适用条件注意事项ACME 协议自动签发需要域名可被公网验证你有可控域名服务能被验证需要处理验证方式证书有 90 天有效期必须做好自动续期本地自签证书纯内网环境不想暴露任何端口每台客户端要手动信任根证书否则浏览器仍会告警自签方案更贴合规内网的思路代价是信任根证书这一步要在每台设备上做一次而且证书有效期设长一些比如 825 天能减少维护频率。别设 10 年部分系统会拒绝过长有效期的证书。自动签发方案省心但前提是你的域名能被验证这对纯内网部署不太现实——所以大多数家用自托管场景自签加客户端信任是更务实的选择。网关侧的核心配置逻辑就三件事监听 443、把证书指向正确路径、把请求转发到127.0.0.1:8080。转发时记得带上Host头和真实客户端 IP 的转发头否则应用日志里全是网关的地址出问题查不到来源。4.2 访问控制的三层思路TLS 解决的是传输不被看不解决谁能进。对一份健康记录来说后者更重要。我一般叠三层第一层网络边界。前面已经让应用只监听回环地址这一步保证了任何访问都必须经过网关。如果你的服务跑在公网服务器上比如家里没条件常年开机那网络边界这层就得靠防火墙规则和访问来源限制来做不要把端口直接暴露出去。第二层网关层认证。在网关上加一层基础认证等于在应用登录之前先过一道门。这样即使应用本身出现未授权访问的漏洞攻击者也还要过这一关。代价是每次访问要输两次密码所以我通常会给记录类应用配上较长的会话有效期或者用浏览器记住凭据。第三层应用账号本身。强密码、定期更换、不同设备分开账号如果支持多用户。如果是给家里两个人共用一定要确认应用支持多用户隔离否则两个人的记录混在一个账号里导出和备份时都无法区分。还有一层不算防护但很有用的东西访问日志。网关的日志会记录访问时间、来源 IP、状态码。偶尔翻一下能发现异常扫描或者自己忘了关的公开路径。这个习惯救过我一次——某个测试用的静态目录忘了删日志里出现了大量外部请求才意识到问题。5. 备份、迁移与恢复把数据自主这句话兑现5.1 两条腿走路数据库与附件的分离备份经期记录类应用的数据一般分两部分结构化记录日期、症状、备注、周期长度和非结构化附件如果有拍照上传功能。两者备份策略不同。结构化数据最稳妥的方式是应用自身的导出功能 数据库文件冷备双轨。导出功能生成的是应用自己定义的格式优点是跨版本、跨实例都能导入缺点是可能不包含全部字段。数据库文件是完整的缺点是版本升级时 schema 可能变直接用旧文件覆盖新版本可能会出问题。所以两条都要有导出文件用来换环境数据库文件用来原地恢复。冷备的操作顺序很重要顺序错了备份就是废的# 1. 停掉容器保证数据库没有写入中的事务 docker compose stop ovumcy # 2. 打包数据与配置 tar -czf /backup/ovumcy-$(date %F).tar.gz -C /opt/ovumcy data config .env # 3. 启动 docker compose start ovumcy # 4. 校验压缩包完整性 tar -tzf /backup/ovumcy-$(date %F).tar.gz /dev/null echo OK直接cp一个正在被写入的数据库文件大概率拿到一个损坏或不一致的副本。有些应用支持在线备份接口或 SQLite 的在线备份命令那更好但先停再备是最不会出错的做法对一个每天只停几秒的服务来说完全可以接受。附件照片体积可能比数据库大得多按周期做增量同步更合适不一定要每次全量打包。5.2 恢复演练不演练的备份等于没有备份这句话我在不同场合说过很多次因为它太容易被忽略。很多人备份脚本跑了两年从来没验证过能不能恢复真出事的时候才发现压缩包里只有空目录。我建议的演练方式是在一台完全不同的机器上用备份文件从零拉起一套实例然后确认登录、历史记录、附件都能正常打开。这个动作一年做一次就够但一定要做。演练过程中会发现很多细节问题.env里的密钥没备份导致无法解密、数据目录属主在新机器上不匹配、旧版本数据库文件在新版本镜像上无法直接挂载。这些问题在真正需要恢复的那天才发现代价就是全部历史数据。迁移场景同理。换设备时的顺序是旧机停服 → 打包 data/config/.env → 新机建同样路径 → 解包 → 确认属主 → 起容器 → 验证。路径尽量保持一致很多配置里的绝对路径是写死的换路径会踩坑。6. 几个高频故障的完整排查链路6.1 日期错位时区配置的连锁反应症状很典型晚上 11 点多录入的记录第二天打开发现挂到了前天或者周期计算出来的天数总差一天。这类问题几乎全部源于时区。排查顺序我是这样走的看宿主时间date和timedatectl确认时区和当前时间都对。如果显示 UTC 而你在东八区宿主就是错的。看容器内时间docker compose exec ovumcy date。容器默认继承宿主时区但如果你在编排里写了TZ而宿主没同步两者就会打架。看应用设置页有些应用有自己的时区设置项会和系统时区取其一。三者必须指向同一个带地区的时区名。看数据库存储如果数据库存的是本地时间字符串时区一变历史数据就整体偏移如果存的是 UTC 时间戳显示层转换就够。这个要看应用的数据模型无法从外部改。修复上能统一到 UTC 存储 显示层转换当然最好但多数自托管应用做不到这么干净所以实践中的做法就是把宿主机、容器、应用三处的时区都设成同一个值然后不要再去动它。特别是不要用UTC8这种偏移写法夏令时和某些系统的处理会让它变成非预期的值。6.2 重启后数据消失的三种根因这个问题的表现是容器重启或者执行了一次compose down再up数据回到初始状态。按可能性排序根因一卷挂载路径写错或写成了命名卷但没保留。检查docker inspect里的挂载信息确认宿主路径和应用内部数据路径对应正确。常见错误是应用实际写在/app/database而你把卷挂到了/app/data看起来挂上了实际没有。根因二权限不足导致写入失败。应用启动时检测不到可写目录会退回到内存或临时目录。表现是当次能用重启就没。查日志里的 permission denied确认宿主机目录属主与容器内运行用户 UID 一致。根因三把compose down -v当成了compose down。那个-v会删除命名卷。用命名卷的朋友尤其要注意这个参数我在早年至少误用过两次。排查的通用套路是先看docker inspect的 Mounts 段再看容器日志里的写入路径最后去宿主机对应目录ls看有没有文件真的落下来。三步之内基本能定位。6.3 手机上用起来的摩擦点桌面端一切正常换到手机就各种别扭这是自托管应用的常见体验落差。几个能明显改善的点加到主屏幕。如果应用提供了清单文件添加到主屏幕后会以独立窗口打开没有地址栏体验接近原生。前提是 HTTPS 可用这也是前面坚持配证书的原因之一。窄屏布局。记录类表单在手机上容易横向溢出或者按钮太小。如果在设置里能调字号或紧凑模式先调调不了就在网关层做一次响应式检查确认 viewport 元信息正确。输入法遮挡。备注框在键盘弹出时被遮住需要页面本身做了视口高度适配。这个通常只能等应用修或者用横屏临时绕开。7. 长期用下去维护节奏与二次扩展的边界一套自托管服务真正的成本不在部署在维持。我的做法是给这类低频但重要的服务定一个极简的维护日历写进备忘录到期就做不做扩展思考。周期动作目的每周自动冷备打包、异地同步一份保证最多丢 7 天每月看一眼磁盘占用和日志里的错误行数提前发现写满或异常循环每季度拉一次新镜像先看变更说明再升级平衡补丁与风险每年完整恢复演练一次验证备份可用升级这件事要克制。应用更新日志里如果有数据库结构变更升级前必须先做一次冷备而且备份文件要放到另一台设备上不要放在原地。升级失败回滚的路径是旧镜像 旧数据两个都得在。二次扩展方面我个人的边界是这样的能改配置就不改代码能加外围脚本就不动容器。比如想在周期临近时收到提醒比起改应用更省事的做法是读它的导出文件用一个定时脚本判断再通过已有的通知渠道发出去。这样应用升级不会冲掉你的定制出问题也容易定位是哪一段的问题。真正会去改源码的只有一种情况某个字段的存储逻辑和你的需求存在根本冲突而这个冲突无法通过导出后二次处理绕过——这种情况我遇到过一次代价是每次升级都要重新打补丁后面就再也不想干了。最后分享一个我觉得挺有用的小习惯把.env、编排文件、以及一份恢复步骤的纯文本说明放在一个加密归档里和备份文件放在一起。半年后你多半已经忘了当时是怎么配的、哪个参数对应哪台机器。那份说明写起来只要十分钟但它决定了你在一个疲惫的深夜能不能把服务重新拉起来。一份记录了你三年身体状态的数据值得这十分钟。
阅读完成 · 觉得有帮助？
