备份哪些东西#

• src/content/posts：文章源文件，最重要。

• dist：当前线上可访问的构建产物，方便快速回滚。

• Nginx 站点配置：一旦配置写错，网站可能直接打不开。

• 脚本和环境文件：例如构建脚本、部署脚本、包管理器配置。

备份命名要能看懂#

备份目录最好包含时间和原因，不要只叫 backup1。等问题发生时，能从目录名判断哪一个可以恢复。

1
mkdir -p /root/codex-backups/blog_web_app
2
cp -a src/content/posts /root/codex-backups/blog_web_app/posts-$(date +%Y%m%d%H%M%S)
3
cp -a dist /www/wwwroot/blog_app/blog_web_app/dist.prev.$(date +%Y%m%d%H%M%S)

什么时候必须备份#

单篇文章小修可以依赖 Git；但批量改几十篇文章、上传覆盖服务器目录、替换线上 dist、修改反向代理规则前，都应该做显式备份。

恢复也要提前想好#

备份不是只复制一份文件，还要知道怎么恢复。比如 dist 回滚时，要确认文件属主、路径和 Nginx 指向不变；文章回滚时，要重新构建搜索索引。

实战复盘#

我会用《修改博客前的备份习惯》建立一个可复用的维护标准：先说明为什么要做，再写具体检查项，最后给出发布后的确认方式。读者照着做时，不需要再猜下一步。

博客类文章最容易变成泛泛而谈，所以每篇都应该留下明确对象，例如 frontmatter、Pagefind、Nginx、Sitemap、分类卡片。对象越明确，文章越容易被搜索和复用。

如果以后发现文章只有原则没有操作，就应该补一个最小命令或检查清单。维护博客本身也是工程工作，要能验证、能回滚、能复盘。

最小验收样例#

验收《修改博客前的备份习惯》时，我会选一篇真实文章或一个真实页面作为样例，而不是只看源码。先确认页面能打开，再确认列表、分类、归档、搜索这些入口都能找到它。

如果文章讲的是站点维护，还要记录修改前后差异：改了哪个文件、构建产物是否更新、线上 HTTP 状态码是多少。这样后面出问题时，可以直接回到这次验收记录。

小结#

备份的价值在于让修改可逆。只要改动影响线上可访问内容，就值得先留一条清晰的回退路径。