博客搭建记录（二）：导航整理、双域名 HTTPS 与备份

第一篇整理了 Halo 的基础部署、应用端口、外部访问地址和 Swap。接下来，我继续调整阅读入口，统一两个域名的访问方式，并为博客建立了每日备份和电脑副本。

这篇文章按“读者如何找到内容、域名如何访问、数据如何保存”的顺序展开，也记录目前已经验证和仍待验证的部分。

一、用分类组织文章，让顶部菜单保持简洁

博客最初只有“服务器部署记录”一个分类。准备写 Hive 等大数据学习内容后，我新增了“大数据处理技术”分类。

如果每增加一个主题，就在顶部增加一个导航项，菜单会越来越拥挤。因此，我将分类入口集中到“文章”下面，形成这样的阅读路径：

文章 → 分类总览 → 某个分类 → 该分类下的文章

现在点击顶部“文章”，会进入分类总览；菜单中的子项也可以直接进入具体分类。这里需要区分两个概念：

• 文章分类决定文章如何归组。
• 菜单的父子关系决定导航如何展示，不会自动改变文章所属分类。

在 Halo 中，先创建分类，并为文章选择对应分类；再到主菜单中添加分类入口，将它们的上级菜单设为“文章”。最后将“文章”的链接指向分类总览，而不是按时间列出所有文章的归档页。

已有分类改名时，可以保留原来的固定链接，避免旧链接失效。新的分类别名则尽量使用简短、含义明确的英文，方便后续维护。

二、让首页有明确的阅读入口

我使用的主题是 Serenity-Grace 2.1.12。在首页设置中，我开启了近期笔记，关闭了暂时没有内容的随想碎片，并取消欢迎页，让读者进入网站后能够直接看到内容。

首页的快捷导航原本与顶部菜单重复，全部关闭后又显得空。我最后将这块区域改为“学习与实践”，希望它承担按主题浏览技术笔记的作用。

整理首页时，我更关注每一块内容的用途：最新文章用于展示更新，分类入口用于按主题查找，关于页用于了解作者。还没有内容的区域可以先收起，等需要时再启用。

三、让带 www 和不带 www 的域名都能正确访问

为了统一访问入口，我选择带 www 的地址作为主域名，同时处理不带 www 的地址。下面使用示例域名说明：

地址	预期行为
https://www.example.com	直接打开网站
https://example.com	跳转到 HTTPS 主域名
两个域名的 HTTP 地址	最终进入 HTTPS 主域名

example.com 仅用于演示，需要替换为自己的域名，并确保两个域名的解析都指向正确的服务器。

这次在 1Panel 中的操作顺序是：

1. 在网站域名设置中添加不带 www 的域名。
2. 申请一张同时覆盖两个域名的 Let's Encrypt 证书。本次使用 HTTP 验证，并开启自动续签。
3. 将证书应用到网站，启用 HTTP 到 HTTPS 的跳转。
4. 创建 301 重定向，来源仅选择不带 www 的域名，目标填写 HTTPS 主域名，并开启“保留 URI 参数”。

新增网站域名，并不代表原证书会自动覆盖它。即使请求最终要跳转，浏览器访问来源域名的 HTTPS 地址时，仍需要先完成 TLS 连接，因此来源域名也应有有效证书。

重定向规则的名称只是方便管理的标识。在我使用的面板版本中，它有字符与长度限制，按界面要求填写即可。更重要的是来源域名要选对，避免把主域名也重定向到自身。

验证时，我除了检查首页，还测试了带文章路径和查询参数的地址，例如：

https://example.com/archives/sample-post?source=test

预期是跳转到主域名下的同一路径，并保留查询参数。实际检查中，两个域名的 HTTPS 正常，路径与参数保留，也没有出现循环跳转。自动续签已经配置，后续仍需要检查执行记录。

四、为应用和网站分别设置每日备份

在 1Panel 中，我创建了两项计划任务，备份目标均为服务器磁盘。执行时间按服务器的北京时间时区计算。

备份对象	执行时间	保留份数
Halo 应用	每天 03:00	14 份
网站	每天 03:15	14 份

这里的“每天 03:00”表示每天凌晨三点，不是每隔三小时执行一次。“保留 14 份”表示保留近期备份，超过数量后按任务的保留策略清理较早的副本。

我将两项任务错开，并分别手动执行，检查日志是否成功。然后查看压缩包内容，确认这次部署中两类备份的范围：

• 应用备份包含数据库导出和应用数据目录，其中可以找到上传附件、主题和插件等文件。
• 网站备份包含网站配置、重定向规则和证书文件。由于使用的是一键部署网站，本次网站备份还包含应用备份，与单独的应用备份有部分重叠。

这说明选择备份类型后，还应该检查一次实际内容。不同部署方式的备份范围可能不同，不能仅凭“应用”或“网站”的名称判断能恢复哪些数据。

怎样估算磁盘是否足够

本次两份压缩包各约 58 MiB。按当前大小，各保留 14 份，合计约 1.6 GiB。当时服务器可用空间约 55 GiB，现阶段有足够余量。

读者可以用下面的方法估算自己的情况：

预计备份占用 ≈ 各类单份备份大小 × 各自保留份数，再将结果相加

这只是现有体积下的估算，还应为备份生成时的临时文件、数据库增长和上传附件留出空间。随着内容增加，单份备份也会变大，需要定期查看磁盘余量。

五、将最新备份下载到固定的电脑文件夹

服务器上的备份与网站仍位于同一台机器，因此我又保存了电脑副本。这样在服务器无法使用时，至少还保留了一份下载过的数据。

最初用浏览器下载时，我选择了“打开”，文件进入临时下载目录，难以查找。Edge 的下载选项中，“打开”会先保存到临时位置，“保存”使用默认下载目录，“另存为”允许指定位置。设置默认下载目录，并不会改变“打开”的处理方式。相关行为可参考Microsoft Edge 团队的说明。

我的需求是将两类最新备份保存到同一个容易找到的文件夹，因此制作了一个专用下载入口。它使用已有的 SSH 连接完成以下流程：

1. 查找应用备份和网站备份各自最新的成功记录。
2. 将两份文件下载到预先设置的电脑备份文件夹。
3. 核对下载文件的大小和 SHA-256 校验值。
4. 校验通过后保留为完整副本；已经存在且一致的文件跳过下载。
5. 完成后打开备份文件夹，方便查看结果。

文件夹的位置可以根据自己的使用习惯选择。重要的是长期固定、容易找到，而不是依赖浏览器生成的临时路径。

这两个环节的执行方式不同：

环节	当前执行方式
服务器生成备份	每天自动执行
更新电脑副本	每周日 20:00 自动执行，也可以随时手动下载

电脑定时任务使用当前用户的登录会话：每周日 20:00 下载两类最新成功备份；如果错过执行时间，下次登录后会检查并补跑。因此，电脑关机或用户未登录时，不能期待它按时下载，实际完成时间以运行记录为准。

电脑保留规则与服务器分别管理：每类保留最近 14 份已校验副本，并保留最近 12 个日历月中每个月最新的一份；两组结果取并集，重复文件不会额外复制。只清理下载工具登记且 SHA-256 校验通过的备份，用户另存的文件和手动保护的副本不进入自动删除范围。两份最新文件全部下载、校验成功后才执行清理，失败时保留旧副本。

按每份约 58 MiB 估算，两类电脑副本最多约 50 份、约 2.9 GiB，但附件增长后体积也会增加。已设置提醒：电脑备份目录超过 10 GiB、服务器剩余磁盘不足 10 GiB，或者相关日志超过 3 GiB 时，提示检查容量；这些阈值不会触发提前删除未到期日志。没有购买或接入云存储。

六、检查主题的显示与阅读顺序

内容和菜单整理完成后，我在实际浏览中发现了几个主题问题：空分类没有显示数字 0，分类详情页顶部却显示了固定的文章数量；两篇系列文章的“上一篇 / 下一篇”也与发布时间顺序相反。

空分类的两处计数问题已向主题项目提交反馈。本地已为缺失计数补上 0，并将分类详情页的固定数字替换为实际文章总数；上游是否采用仍以项目后续更新为准。

对于文章导航，我检查了 Halo 提供的相邻文章数据：previous 指向发布时间更早的文章，next 指向更晚的文章。当前主题的标签与这两个方向对应相反，因此先做了本地调整，并验证：

• 第一篇的“下一篇”指向第二篇。
• 第二篇的“上一篇”指向第一篇。

这里的顺序依据发布时间，不是标题中的序号。如果系列文章需要独立于发布时间的阅读顺序，仍应在正文中提供明确的前后篇链接。

本地主题修改需要留存备份，更新主题前也应检查是否会被覆盖。这次导航调整已经生效，是否向上游提交还在考虑中。

七、在隔离环境中验证恢复

2026 年 10 月 1 日，我使用当晚生成的应用备份进行了实际恢复测试。测试使用独立的临时数据库和 Halo 容器，通过内部网络隔离，不覆盖线上数据库，也不开放测试网站给外部访问。

验证过程包括：解包并检查路径安全，将数据库导入临时 MySQL，恢复应用数据目录，按与线上一致的数据库类型启动 Halo，再从测试容器内部请求页面。结果如下：

• 数据库导入成功，临时 Halo 正常启动。
• 两篇博客文章页面均返回 HTTP 200，标题正确。
• 分类页面能显示“服务器部署记录”和“大数据处理技术”。
• 主题目录和 24 个附件文件恢复到测试环境。
• 网站备份包含证书、证书私钥和主域名跳转规则；在独立 OpenResty 容器中执行配置检查，结果通过。
• 测试结束后，临时容器和内部网络已经移除，恢复报告另行保存。

这次测试确认了当前备份能够恢复数据库、应用数据和公开页面，并确认网站配置语法可用。它没有模拟整台服务器重装、DNS 切换或证书重新签发；发生故障时仍需按实际环境调整端口、内部数据库地址和域名。

除应用、网站备份外，我还单独保存了服务器配置和电脑下载工具的恢复资料。配置包可能包含密码、数据库内容和证书私钥，需要按敏感备份保管，不能上传到公开仓库或作为文章附件发布。更换 SSH 密钥后，下载入口也需要同步更新。

八、日志保存和维护检查

网站访问与错误日志、系统及安全日志已经设置按日归档。关闭后的日志进行压缩，最近一份轮转日志延后一个周期压缩；系统 journal 另外按日导出压缩副本。归档至少保留六个自然月，仅在归档日期及文件修改日期都早于保留边界、且没有保留标记时自动清理。

这个期限针对相关日志，与服务器保留 14 份备份、电脑保留近期及月度副本是不同的规则。新规则只能从已有记录开始积累，启用前已经丢失的历史日志无法补回。容量提醒用于发现增长异常，不会为了控制体积提前删除未到期日志。

日志维护与备份执行记录都应持续检查；手动运行成功不代表以后每次自动执行都一定成功，首次按时间触发和后续结果仍以实际运行记录为准。

写在最后

这次收尾工作主要解决了三件事：读者能够按主题找到文章，域名访问有统一入口，博客数据有持续生成的备份和电脑副本。

后续维护会继续检查备份执行记录、证书续签结果和磁盘余量，并在重要升级后重新做恢复演练。对个人博客来说，一套能够长期执行、也知道如何验证的流程，比只完成一次配置更有价值。