时隔三年，再次备份：从手搓博客到 AI 全面自动接管
今天打开尘封多年的备份目录，看到了一个熟悉的文件名——2023_07_09.sql。那一刻，恍如隔世。三年前的今天，我曾经认真地导出过一次数据库；三年后的今天——2026 年 7 月 9 日，自动备份启用。整整三年，1095 天，我的博客就这样安安静静地跑着，没有人备份，也没有人管，它就那么稳稳当当地活着。感慨万千，大概是此刻最准确的四个字——不只是为"三年没备份"的后怕，更是为这三年里，博客从"手搓"到"AI 全自动"的天翻地覆。
1、七年了，它还活着
从最初搭建到现在，这个基于 BBS 的个人博客，已经稳定运行了整整七年。七年，对互联网产品来说是个不短的数字——多少论坛关站、多少博客平台倒闭、多少"永久免费"变成"已停止服务"。而我这个小小的、自建在虚拟主机上的 BBS，竟然就这么安安静静地跑了七年，没崩过、没被黑穿、没丢过数据。它比我靠谱。
想想这七年，从最初的搭建、调主题、发第一篇帖子，到后来渐渐更新变少、甚至好几个月不登录——但它始终在那里，默默响应着每一个访问请求。这大概就是自建博客的魅力：它不需要你每天喂它，只要服务器在、数据库在，它就在。七年，无声的坚守。
2、今天的备份操作实录
今天的备份方式，和三年前一模一样，朴素但有效——XShell + XFtp + mysqldump，这个组合用了七年没变过。流程简单到可以写在一张便利贴上：
// 步骤1：XShell 登录服务器，导出数据库
mysqldump -u root xiuno4 > /home/download/2026_07_09.sql
// 步骤2：XFtp 连上服务器，把 SQL 文件拉到本地
// 远程路径：/home/download/2026_07_09.sql
// 本地路径：D:\code\GitHub\self\Blog-backup\database_backup\
// 步骤3：确认文件完整，备份完成
// 整个过程不到五分钟，七年的数据安安全全落到了本地硬盘这套"土办法"虽不花哨，但胜在可控、透明、不依赖任何第三方平台——我知道每一步在做什么、文件在哪、数据有没有完整。对比那些"一键自动备份到某云"的方案，我反而更信任这种"亲手把文件搬到自己硬盘"的笨办法。数据攥在自己手里，心里才踏实。
3、三年之隔：数据对比
两个备份文件安静地躺在同一目录下，文件名只差三个数字——2023 与 2026。导出后一对比，三年间的变化精确到了每一篇：
2023_07_09 2026_07_09 增量
-----------------------------------------------------------
文件大小 24 MB 31 MB +7 MB（+29%）
主题（bbs_thread） 553 篇 730 篇 +177 篇
帖子（bbs_post） 19,445 条 21,777 条 +2,332 条
相隔天数 —— 1,095 天 整整 3 年
// 平均下来，三年 177 篇新主题 ≈ 每 6 天一篇 ≈ 每周一篇
// 但这只是"平均"——真实分布远比这戏剧性177 篇新增主题、2332 条新增帖子、7 MB 数据增量——每一条记录都是这三年留下的痕迹。但这 177 篇的"生产方式"，却经历了一场静悄悄的革命。
4、从手搓到全自动：博客生产的三年质变
这 177 篇新增主题里，藏着一个时代变迁的故事。三年前的 553 篇，每一篇都是手搓的——选主题、查资料、敲文字、排版、检查格式、手动发布。一篇博客从构思到上线，少则两三小时，多则一整天。那些年，博客的增长是"手工作坊式"的：产量受限于精力和时间，一周更一两篇就算勤快。
而 2026 年之后，情况彻底变了。大量博客开始用 AI Agent 驱动的"博客模型"自动生成发布——给一个主题、几条参考资料，AI 按照既定的富文本格式规范，直接生成结构完整的 HTML 博客，一键发布。从"一篇写半天"到"一天出多篇"，从"手搓排版"到"AI 自动规范"，从"灵感枯竭写不出来"到"给个主题就有产出"。包括你正在读的这篇博客，本身就是 AI Agent 生成的——连"感慨万千"这四个字，都是 AI 替我写的。
这不是怀旧，而是惊叹。七年前我手搓第一篇博客时，绝对想不到有一天博客能"自己写自己"——而备份文件忠实地记录了这个跨越：前 553 篇是"人写的"，后 177 篇里越来越多的比例是"AI 写的"。同一份数据库，两种生产方式，一个时代的分水岭。
5、关于"三年才备份"的反思
说实话，三年才备份一次，是侥幸。这三年里，服务器没有崩过、磁盘没有坏过、服务商没有跑路——任何一个环节出问题，这七年的积累就可能化为乌有。我不是不知道备份的重要性，恰恰相反，我太知道了，所以才会在看到"上次备份 2023_07_09"时后背发凉。
原因无非是那个最普遍的借口——"太忙了，回头再弄"。三年里不是没想过备份，但每次念头一闪就被工作、生活、各种事情淹没。直到今天，鬼使神差地打开那个目录，才惊觉已经拖了整整三年。备份这件事，永远有比它更"紧急"的事插队，直到你差点失去数据，才发现它才是最重要的。
6、备份里的时代缩影
当 XFtp 的传输进度条走到 100%，31 MB 的文件稳稳落在本地硬盘的那一刻，一种久违的踏实感涌上来。但细想之后，比"数据没丢"更让我感慨的是——这两个备份文件，是一份"时代缩影"。
2023 年那份 24 MB 的 SQL，记录的是一个"纯手搓博客"的世界：每篇帖子背后都有一个人、一段思考、一次敲键盘。2026 年这份 31 MB 的 SQL，已经混入了大量"AI 生成"的帖子——它们格式更规范、篇幅更长、技术覆盖更广，但"写"它们的不再是我，而是 AI Agent。同一张 bbs_thread 表，前半段是人的痕迹，后半段越来越多是AI 的产出。
自建博客的"数字主权"依然珍贵——数据是我的、域名是我的、服务器是我的。但"内容生产"这件事，已经从"我写博客"变成了"我管 AI 写博客"。时过境迁，变化之大，备份替我做了一个最诚实的见证。
7、该认真想想"自动备份"了
三年手动备份一次，显然不是一个可持续的方案——尤其是现在博客产量因为 AI 加持而大幅提升，数据增长会更快。趁这次感慨还没散，把自动备份提上日程：
// 下一步：定时自动备份方案
// 方案A：服务器端 crontab 定时 mysqldump + 本地 rsync 拉取
0 3 * * 0 mysqldump -u root xiuno4 | gzip > /backup/$(date +\%Y_\%m_\%d).sql.gz
// 方案B：GitHub Actions 定期从服务器拉取 SQL，自动提交到私有仓库
// → 本地这份 2026_07_09.sql 就已经放进了 GitHub 的 Blog-backup 仓库
// 目标：从「三年一次手动」升级到「每周自动 + 异地冗余」
// 博客都 AI 全自动了，备份也该跟上这次备份文件已经放进了 GitHub 仓库——至少有了一份版本控制层面的异地冗余。下一步把定时任务配上，让备份从"想起来才做"变成"不需要想起也会做"。内容生产已经全自动了，数据保护没有理由还停留在手动。
8、写给下一个三年
如果三年后——2029 年 7 月 9 日——我再次打开备份目录，那时的博客会是什么样子？主题数可能突破 2000 篇，AI 生成比例可能已占绝大多数。手搓不会消失，但会变成"精品/深度文"，AI 负责"量产/常规文"——人管方向和质量，AI 管执行和产量，各司其职。
七年是一个里程碑，但不是终点。从手搓到 AI 全自动，博客的生产方式已经天翻地覆；但"记录与分享"的初心没有变——变的只是工具。这个小小的 Xiuno 站点还会继续跑下去，承载更多代码笔记、技术踩坑和时代碎片。毕竟，能稳定运行七年的东西值得被好好守护——而守护的第一步，就是别再把备份一拖三年。
9、总结
2023 年 7 月 9 日到 2026 年 7 月 9 日，整整三年、1095 天。博客从 553 篇主题增长到 730 篇（+177 篇），从 24 MB 长到 31 MB。但比数字更震撼的是——这三年，博客的生产方式从"纯手搓"跨越到了"AI Agent 全自动生成"，包括这篇博客本身。备份不只记录了数据的增长，更忠实地见证了从"人写博客"到"AI 写博客"的时代变迁。
关键要点：
- 博客（Xiuno 4）稳定运行七年；三年间主题 553→730（+177 篇），帖子 19445→21777（+2332 条）
- 备份方式：XShell 执行 mysqldump + XFtp 拉取到本地，朴素但可靠
- 时代变迁：2026 年起大量博客由 AI Agent 自动生成发布，从手搓到全自动
- 备份是"时代缩影"：前半段是人的痕迹，后半段越来越多是 AI 的产出
- 反思：三年才备份是侥幸，下一步上自动备份；内容已全自动，保护也应跟上
最后，对着屏幕上那个 2026_07_09.sql 文件发了一会儿呆——它是 31 MB 的、冰冷的、二进制的。但在我眼里，它不只是一份数据库备份，更是七年时光的压缩包、一个时代的快照、从手搓到 AI 的见证。从"我写博客"到"我管 AI 写博客"，变化之大，尽在这 7 MB 的增量里。下一个备份不会再用三年——但下一次打开备份时的感慨，恐怕只会有增无减。
