企业官网建设流程全解析

• 文档/教程

本篇基于 90DaysOfDevOps 挑战的 Day 86，讲解如何为各类平台与环境的有状态数据建立可靠的备份体系：先理解 3-2-1 备份方法论与"高可用不是备份"等常见误区，再跟着原文档的完整实操，使用开源备份工具 Kopia 把本地文件同时备份到家用 NAS（SMB 仓库）与 Google Cloud Storage 对象存储（异地仓库），并掌握快照列表、挂载与恢复的具体命令，最终让备份真正可恢复、可验证。

为什么所有平台都需要数据保护

在 90DaysOfDevOps 挑战中我们讨论过很多不同的平台与环境（容器、Kubernetes、云、CI/CD 流水线等），它们有一个共同点：都需要某种程度的数据保护。

数据保护已经存在了很多年，但今天的数据规模与价值意味着我们不能只靠多节点、跨应用的高可用来抵御基础设施故障，还必须保证重要数据有一份副本存放在安全的位置，以应对真实的故障场景。

原文档给出了一个非常清醒的判断：

• 勒索软件与网络犯罪是巨大的威胁，原文作者甚至认为"被勒索软件攻击不是会不会发生，而是何时发生"；
• 但数据丢失最常见的原因既不是勒索软件也不是网络犯罪，而是误删（accidental deletion）——每个人都删除过不该删的东西。

即使挑战中讨论了各种技术与自动化手段，无论平台是什么，保护有状态数据（甚至复杂的状态无关配置）这一需求始终存在。

备份的定义与最简模型

信息技术领域对备份的定义是：

备份（data backup）是对计算机数据的复制，并将其存储到其他地方，以便在数据丢失事件发生后能够用于恢复原始数据。动名词形式指这个过程（back up），名词与形容词形式则是 backup。

把它拆解到最简单的形式：备份就是数据的复制粘贴到新的位置。原文用一个直观的推演说明了为什么"复制一份"还不够：

1. 把文件从 C: 盘复制到 D: 盘，可以应对 C: 盘故障或文件被错误编辑；
2. 但 C: 和 D: 盘都在这台电脑上——电脑整机损坏时，两份副本一起丢失；
3. 于是需要把副本放到系统之外，例如家里的 NAS；
4. 如果房子出事呢？可能还需要放到另一个位置的另一台系统上，比如公共云；
5. 把重要文件存放到多个位置，可以进一步降低失败风险。

同时，备份应当以自动化为前提来设计，能够融入现有工作流，而不是依赖人工操作。

3-2-1 备份方法论

原文档在此引出了经典的 3-2-1 规则（backup methodology），其核心含义是：

方法论上有两个关键决策点：

• 第一份备份应尽量靠近生产系统。原因是恢复速度：回到最前面的讨论，误删是最常见的恢复原因，靠近生产的副本能让恢复最快；但这份副本必须存放在独立于生产系统之外的合适第二介质上。
• 必须再有一份数据副本发送出去到外部/异地（offsite），即第二个位置——可以是另一间房子、另一栋建筑、另一个数据中心，或者直接是公共云。

备份责任：识破"不需要备份"的常见神话

原文档专门辟谣了几种"不需要备份"的说法，这些判断值得在架构评审时逐条对照：

神话一："一切都是无状态的"

如果一切都是无状态的，那业务本身是什么？没有数据库？没有业务文档？显然，确保数据受保护是组织内每个人的责任，但为关键应用与数据提供备份流程，最终通常会落在运维团队身上。

神话二："高可用就是我的备份"

"我们在集群里建了多个节点，不可能宕机"——这种说法在以下场景下会失效：

• 你对数据库做出的错误变更会被复制到集群的所有节点，高可用保护不了逻辑错误；
• 火灾、洪水等场景会让整个集群不可用，连同集群里的重要数据一起丢失。

把高可用与容错纳入架构是必要的，但它不能替代备份。

复制（Replication）不等于备份

如果集群跨多个地点部署，复制看起来像提供了异地副本。但第一个"误操作"依然会被同步到所有复制点——备份需求应当与应用程序复制或系统复制并列存在，而不是被其替代。

另一个极端：副本放得太多

也不是副本越多越好：把数据复制到过多位置，不仅增加成本，还会大幅扩展攻击面，提升被攻击的风险。

谁来负责备份？

每家企业情况不同，但一定有人应当主动负责理解备份需求，同时也要理解恢复计划（recovery plan）——这两者是一体两面。

恢复才是目的：恢复的粒度

"Nobody cares till everybody cares"——备份是一个典型的例子：直到你需要恢复的那一刻，所有人才真正关心备份。因此在要求备份数据的同时，必须同步考虑如何恢复：

• 如果是文本文档这类小文件，来回复制很容易也很快；
• 但如果是 100GB 以上的数据，恢复就会花很长时间；
• 还要考虑恢复的粒度。以一台虚拟机为例：它包含整个虚拟机、操作系统、应用安装，如果还是数据库服务器还有数据库文件。如果只是往数据库里插错了一行数据，你可能根本不需要恢复整个虚拟机，而是只恢复你需要的颗粒度。

这直接影响备份工具选型：工具必须支持从整机级到文件/对象级的细粒度恢复。

备份场景：本地仓库文件 → 本地 NAS + 云端对象存储

原文档搭建的实战场景是：

• 保护本地机器（Windows）上的一些文件——具体就是这个90DaysOfDevOps 仓库目录；
• 虽然这个仓库也在推送到 GitHub（你大概率正在那里读到原文），但如果本机损坏且 GitHub 也宕机，谁来读这些内容？数据又该如何恢复到另一个服务？
• 目标：把这份重要数据同时保护到本地的 NAS 设备和云端的对象存储桶两处。

场景架构如上文第二张图所示：左侧是本机C:\micha\demo\90DaysOfDevOps目录，两个蓝色箭头分别指向右侧的本地 NAS 设备与基于云的对象存储桶（Cloud based object storage bucket）。

工具选型：Kopia

有很多工具可以实现这个目标，原文选择了Kopia——一个开源的备份工具，能力包括：

• 加密（encrypt）：仓库内容用密码加密存储；
• 去重（dedupe）：重复内容只存一份；
• 压缩（compress）：降低存储与传输开销；
• 多位置投递：快照可以同时发送到多个仓库/位置。

原文写作用的是v0.10.6版本。Kopia 提供 CLI 与 GUI 两种形态：演示用 GUI（KopiaUI-Setup-0.10.6.exe），但要知道还有 CLI 版本，适合没有图形界面的 Linux 服务器。

安装 Kopia 与选择存储类型

Windows 上的安装流程很直接：

1. 运行KopiaUI-Setup-0.10.6.exe，一路"下一步"完成安装；
2. 打开应用后，第一个界面就是选择你想用作备份仓库（repository）的存储类型。

这个"仓库"概念是 Kopia 的核心：每个仓库绑定一种后端存储（SMB、NFS、本地目录、GCS 等）和一份独立配置，后续的快照数据都写入当前配置的仓库。

配置本地 SMB 仓库（NAS 备份）

第一步是用本地 NAS 设备建立仓库，协议使用SMB（原文补充：也可以用 NFS）。GUI 流程如下：

1. 选择存储类型：选中 SMB 类型的仓库后端，指向家用 NAS 上的共享；
2. 设置密码：下一屏定义一个密码，这个密码用于加密仓库内容——注意它同时也是恢复的前提条件，密码丢失基本意味着数据不可恢复；
3. 触发即时快照（adhoc snapshot）：仓库配置完成后，可以立即发起一次快照开始写入数据。

快照配置的四个关键项

在创建快照时（以90DaysOfDevOps文件夹为例），GUI 提供了一系列控制项，这也是备份策略真正落地的地方：

选择snapshot now后，数据即开始写入仓库。到此，第一份（近端、第二介质）备份已经落地。

异地备份：把快照发送到 Google Cloud Storage

为什么需要 CLI 与多份配置文件

Kopia 的 UI 一次只能配置一个仓库。原文给出的思路是"创造性"地利用 CLI：维护多份仓库配置文件（一份指向 SMB NAS，一份指向对象存储），分别执行命令，即可让数据同时送达本地与异地两个位置。

准备 GCS 桶与认证

1. 登录 Google Cloud Platform 账号，创建一个存储桶（本例桶名为90daysofdevops）；
2. 系统已安装 Google Cloud SDK，执行以下命令完成账号认证：

gcloud auth application-default login

查看当前仓库状态

用 Kopia CLI 查看加入 SMB 仓库后的当前状态（命令中同时指定了配置文件路径，因为使用的是 KopiaUI 自带的 kopia.exe）：

"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository status

创建 GCS 仓库

原文的长期方案是：分别创建smb.config与object.config两份配置文件，各自执行命令，把数据副本发到两个位置。演示中直接替换仓库配置，执行：

"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository create gcs --bucket 90daysofdevops

这里gcs指定仓库后端为 Google Cloud Storage，--bucket 90daysofdevops对应之前创建的桶名。

再次运行repository status命令，即可看到 GCS 仓库配置已生效。

创建快照并写入 GCS

接下来创建快照并把数据发送到新仓库：

"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config kopia snapshot create "C:\Users\micha\demo\90DaysOfDevOps"

执行成功后可以看到输出中的关键信息（见上文第三张图的命令行部分）：哈希与去重统计（如3224 hashed ... 0 cached ... estimated 401.8 MB）、Created snapshot with root kdbd9dff738996cfe7bcf99b45314e193 and ID 8a43295c1d07823d38f72e62972dbd6b in 2m49s——快照的root ID会作为后续恢复时的句柄。

此时在 GCS 控制台可以看到桶里已经出现 Kopia 写入的文件：kopia.blobcfg、kopia.maintenance、kopia.repository以及若干内容对象，MIME 类型均为application/x-kopia——从这些对象结构可以看出仓库元数据与数据块是分开的，这正是去重/增量存储的体现。

3-2-1 要求达成

至此，重要数据满足了原文的完整要求：

• 生产副本：本地磁盘上的原始数据；
• 第二介质副本：本地 NAS 上的 SMB 仓库；
• 异地副本：Google Cloud Storage 上的对象存储桶。

三份副本、两种介质（本地磁盘/NAS + 云对象存储）、其中一份 offsite——3-2-1 方法论在这个场景里完整闭环。

恢复：列出、挂载、还原到新位置

恢复（Restore）是备份体系里同样重要的一半，Kopia 支持恢复到原位置或全新位置：

列出快照

"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config snapshot list

该命令列出当前配置的仓库（GCS）中已有的全部快照，便于挑选要恢复的版本。

挂载快照

可以把 GCS 中的快照直接挂载成本地盘符，像访问普通目录一样浏览备份内容：

"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config mount all Z:

执行后 GCS 上的所有快照即挂载到Z:盘，这对应了前文讨论的"细粒度恢复"：不需要整体还原，先浏览、再只取需要的部分。

直接恢复快照

也可以按快照 ID 直接执行恢复：

kopia snapshot restore kdbd9dff738996cfe7bcf99b45314e193

其中kdbd9dff738996cfe7bcf99b45314e193正是创建快照时输出的 root ID。

关于命令过长的说明

原文特别指出：上面这些命令很长，是因为演示复用了 KopiaUI 捆绑的kopia.exe完整路径。实际操作中，可以单独下载 kopia.exe 并加入 PATH，之后直接以kopia命令调用即可，这也是把备份流程集成进 CI/CD 或定时任务时更干净的方式。

小结与延伸阅读

本篇的核心脉络可以概括为三条：

1. 认知层：备份的本质是"把数据复制到新位置"，高可用与复制都不能替代备份；误删是最常见丢失原因，恢复速度与恢复粒度决定了备份策略的设计；
2. 方法论层：3-2-1（3 份副本 / 2 种介质 / 1 份异地）给出了可操作的最低标准，同时要避免副本过多带来的成本与攻击面膨胀；
3. 实操层：Kopia 通过"仓库 + 快照 + 多配置文件"模型，一套工具同时完成加密、去重、压缩与多目标投递，配合repository status、repository create gcs、snapshot create、snapshot list、mount、snapshot restore等 CLI 命令，整个备份-恢复链路可以完全自动化。

后续 90DaysOfDevOps 挑战的下一讲（Day 87：Hands-On Backup & Recovery）会把数据保护推进到 Kubernetes 平台，使用 minikube 的volumesnapshots与csi-hostpath-driver附加组件、Kasten K10 等方案保护集群工作负载，见 Day 87 中文文档。相关主题的延伸阅读方向还包括：Kubernetes 备份与恢复（Velero 等）、数据库备份范式、灾难恢复（DR）与备份的区别等；英文原版对照文档见 2022 英文 Day 86。

• 文档/教程