网站目录每天都有变化：文章附件增加，配置调整，上传文件被覆盖。定期打一个压缩包容易开始，但文件越来越多以后，重复归档、存储增长和查找旧版本都会变成工作。
Kopia 可以为目录创建加密、去重的快照，并设置保留与调度策略。它的 Web 界面适合查看任务和恢复文件。放在 VPS 上时，最需要理解的是容器到底看得到什么、仓库放在哪里，以及快照中的数据是否一致。
这篇从一个网站的文件目录开始。数据库另行导出，备份仓库最终放到独立故障范围；先做小规模恢复，再安排自动快照。
快照来源与备份仓库是两个位置
来源目录是正在使用的文件，仓库保存备份数据。两者都放在 VPS 同一块盘上时，可以找回部分误改文件，却无法应对整块磁盘或整台机器丢失。
初次试用使用本地仓库，便于理解数据路径。走通以后，再依据存储说明选择对象存储、SFTP 或其他受支持后端，核对凭据和网络条件。不要一边创建正式仓库，一边猜端点和桶权限。
仓库密码与 Web 管理密码也不同。前者参与仓库解密，后者控制谁能进入界面。丢失仓库密码不能靠重置网页登录找回，保存它的位置应独立于被备份的 VPS。
保留策略决定历史快照数量，不等于严格保证仓库体积。数据变化量、大文件替换和维护任务都会影响占用。先观察一段时间，再调整小时、日、周等保留层级。
给容器明确的可见范围
VPS 已有 Docker 与 Compose。建立配置、缓存、日志、试用仓库和恢复目录：
mkdir -p ~/kopia/{config,cache,logs,repository,restore}
cd ~/kopia
假设网站需要备份的文件位于 /srv/example-files。下面配置只给 Kopia 读取该目录的权限，不挂载整个系统，也不允许它操作 Docker 控制接口。
services:
kopia:
image: kopia/kopia:latest
hostname: vps-backup
ports:
- "127.0.0.1:51515:51515"
environment:
KOPIA_PASSWORD: ${KOPIA_PASSWORD:?set repository password}
USER: backup
command:
- server
- start
- --insecure
- --address=0.0.0.0:51515
- --server-username=operator
- --server-password=${KOPIA_UI_PASSWORD:?set web password}
volumes:
- ./config:/app/config
- ./cache:/app/cache
- ./logs:/app/logs
- /srv/example-files:/data:ro
- ./repository:/repository
- ./restore:/restore
restart: unless-stopped
这是根据官方容器安装示例缩减的私人界面配置。--insecure 表示容器服务采用 HTTP，宿主机只映射回环端口，远程访问通过 SSH 加密隧道；不能将此配置直接改成公网监听。没有照搬示例中关闭 CSRF 校验的选项。
创建受限 .env 文件，分别填入两份独立随机密码，可用 openssl rand -hex 32 生成。示例值占位符不能保留，密码不能与仓库源码一起提交。
chmod 600 .env
docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 kopia
ssh -L 15151:127.0.0.1:51515 user@your-server
浏览器打开本机 http://127.0.0.1:15151，使用配置中的 Web 账号登录。若需要通过域名开放界面，重新设计 TLS、认证与代理路径，按照服务端模式说明核对，不能把普通 HTTP 网站的代理模板直接认作完整 Kopia 方案。
先创建试用仓库，再选来源目录
在界面中创建文件系统仓库时，路径使用容器里的 /repository，不是宿主机上的 ~/kopia/repository。选择快照来源时则是 /data。这两个路径分别对应 Compose 的挂载右侧。
创建仓库后，先备份几份测试文件，记住快照时间与内容。在来源里修改一份、删除一份，再创建第二次快照，确认第一份快照仍能查看旧内容。用这个过程理解时间点与保留策略，之后再接正式数据。
固定 hostname 与 USER 让来源身份更稳定。容器重建后随机主机名变化，可能使快照与策略看起来属于不同来源。迁移时核对来源标识，而不是只看到同一个文件夹名字就认为策略自动继承。
如果源目录里出现配置和缓存等不需要的数据，按真实用途设置忽略规则，并查看实际快照清单。忽略规则是过滤，不应凭感觉把整个上传目录排除。先确认文件能重新生成，再决定不备份。
数据库必须先得到一致内容
文件快照不会自动让正在写入的数据库变成可恢复的备份。PostgreSQL、MySQL 和 SQLite 各有一致性要求。网站数据库先用适当工具生成逻辑备份，或者使用经过验证的一致备份方式，再把产物纳入 Kopia 的来源目录。
若数据库导出到 /srv/example-files/database-dumps，导出脚本应在命令成功和产物校验后，才把临时文件改成正式文件。不要让 Kopia 在导出进行一半时保存一个带正式名字的半成品。
同一应用的数据库和附件有关联时，还要安排一致窗口。恢复到昨天的数据库，却配今天删除过的附件，记录可能指向不存在的文件。小规模站点可以在短维护窗口暂停写入后生成对应产物，大规模环境按自己的恢复目标设计流程。
备份进程返回成功，只能说明它完成了当前来源的快照。是否导出了数据库、是否覆盖了重要文件、是否选对挂载范围，都需要维护者确认。
自动调度之前，先把恢复做出来
在 Web 界面选取一个快照，恢复到 /restore 下的独立目录，不能直接覆盖 /data。示例来源以只读方式挂载，也有助于避免错误恢复修改正在使用的文件。
恢复出来后，打开文字配置与图片，核对文件大小和内容。如果是数据库导出，导入到独立数据库，确认应用能读取关键记录。只在面板看到“恢复完成”，不足以证明业务可用。
随后在没有原容器配置的隔离环境连接仓库，使用受控保存的仓库密码，重复恢复测试。这样能发现只备份了仓库，却把必要凭据留在原 VPS 的情况。
恢复过程同时记录文件权限。内容完整但所属账户错误，应用上线后可能无法读取或更新。不要遇到权限失败就把整个目录设成任意用户可写，按应用账户和目录用途恢复。
保留策略与仓库维护分开看
开始时保留少量测试快照，确认策略作用后再扩展。小时级快照适合找回当天的改动，日与周级历史适合发现较早的问题；数量取决于自己的数据变化和恢复要求，没有所有站点通用的数字。
到期快照处理、仓库维护和存储实际释放不是同一时刻。若删除快照后空间没有立即减少，先查看维护状态与文档，不要直接手工删除仓库中的对象。去重仓库中的内容可能被多个快照引用，按文件名猜测哪些对象“旧了”很危险。
缓存目录增长时也要分清缓存与仓库。缓存可影响运行性能，仓库则是正式备份。整理服务器目录时，把这些用途写清楚，避免清理脚本把两者都当临时数据。
通知与检查至少覆盖快照失败、长时间没有新快照和仓库容量异常。定时任务存在，不等于每次能访问远端存储。一次手工成功之后，还应等下一次自动任务完成再验收。
备份任务显示成功，但目录里少了东西
首先核对快照来源是在容器中的哪条路径。宿主机新增了一个挂载盘，而 Compose 没有同步添加对应挂载，Kopia 就可能看不到那部分文件。备份工具不会替你发现宿主机上所有数据位置，应在变更存储后重新检查来源范围。
其次查看忽略规则和快照实际清单。某个文件名被模式排除、目录不可读，或者扫描时文件正在变化，都需要从任务结果和日志理解。不要用整个目录的总大小简单推断所有文件都已进入快照，去重与压缩会让仓库体积不同。
恢复时找不到预期文件，应核对快照时间与来源身份。网站刚上传的附件，可能晚于最近一次快照；改了容器主机名，也可能把历史记录分在另一来源下。将文件操作时间与快照时间对照，比重跑很多次更有用。
如果远端仓库连接失败，分别确认网络、认证、端点和访问范围。新凭据可列出桶，但没有写入权限，或没有维护所需权限，仍可能在不同阶段失败。按选用后端要求配置最小可用范围，并实际运行快照、维护与恢复验证。
来源中包含私人配置时，恢复目录和缓存同样按敏感材料管理。仓库存的是加密数据，不代表恢复到磁盘后的内容也保持加密状态。测试完成后，按已有文件管理流程处理恢复副本，不要将它留在公开网站目录。
将试用仓库换到独立存储
准备正式使用时，先在新后端创建或连接仓库，配置受限存储凭据，执行快照与隔离恢复。切换后确认自动策略使用的是新仓库，旧任务不要继续静默写到 VPS 本地。
传输时间受新增数据量和链路影响。首次完整备份耗时较长，并不能直接推断后续快照也会相同；但大量不断重写的大文件，也可能使日常上传持续增长。观察实际来源与仓库记录，不凭“增量”两个字估算成本。
升级前记录镜像版本、仓库配置与当前备份状态，阅读相关兼容性说明。配置目录包含连接信息，应按敏感材料管理；仓库密码保存在独立受控位置。真正需要恢复时，能拿到仓库和密码、找到合适快照、还原到独立位置并验证内容，这才是一条完整的备份链路。