企业官网建设流程全解析

一台跑了三年的服务器，某天早上业务全量 500，登上去一看数据库主表空了。运维第一反应是去控制台找快照，然后发现最近一次成功的快照是 11 天前——自动快照策略两个月前就因为地域配额满了开始失败，而失败这件事没有任何告警。

这个场景里最讽刺的地方在于：他确实"做了备份"。

问题出在他把三种不同的东西当成了一种。快照、镜像、文件级备份，解决的其实是三个不同的问题：

• 快照解决"我刚才改错了，想退回十分钟前"
• 镜像解决"我要再开一台一模一样的机器"
• 文件级备份解决"这台机器整个没了"

在服务器三种备份方式里，只配第一种是最常见的做法，也是最容易在真正出事那天被一次性击穿的做法。

下面按这个顺序讲：先分清三者差别，再逐个说清楚每种方式的能力边界和坑，最后给一份能照着配的组合。

一、先分清：快照、镜像、备份不是一回事

很多人以为这三者只是"备份的三种粒度"，其实不是——它们的数据存放在哪、生命周期跟谁绑定都不一样，这决定了它们能防什么、防不了什么。

一个很实用的判断口诀：

• 关心"机器能不能起得来" → 用镜像
• 关心"数据能不能找回来" → 用备份
• 关心"刚才那一步能不能反悔" → 用快照

至于服务器备份方法该怎么定，本质上就是先回答"我最怕的是哪种事故"，再往上配。

二、方式一：快照——最便宜的回滚点，也最容易用错

快照是三个里面成本最低、速度最快的，也是被误解最深的。

它的工作原理（各家实现基本一致）：为云盘创建的第一份快照是全量快照，备份当时盘上的所有数据块；之后创建的都是增量快照，只备份自上一份快照以来发生变化的数据块。增量快照虽然不存全量数据，但会引用前面快照中未变化的数据块——所以拿任意一份快照回滚，都能恢复出那个时间点的完整数据。

这个"引用"关系很关键，它带来两个反直觉的结果：

1. 删掉中间某一份快照，通常不会破坏其他快照的可用性（具体合并行为各家不同，见第六节）。
2. 快照链的容量不等于各份快照大小之和，也不等于盘的大小。

坑一：快照只保存已经落到盘上的数据。还在内存缓冲区里、没刷到磁盘的数据不会进快照，Linux 下/run这类内存文件系统里的东西也不会。如果打了快照就以为万事大吉，重启后才发现少了点什么，多半是这个原因。稳妥做法是打快照前先执行sync把缓冲区刷下去；数据库场景则要先把表锁成只读再打快照：

FLUSHTABLESWITHREADLOCK;-- 此时创建快照UNLOCKTABLES;

坑二：回滚是要停机的。至少在主流云平台上，云盘回滚要求实例处于已停止状态。也就是说"回滚"这个动作本身意味着一次业务中断，不是随手就能点的按钮。

坑三：换过系统盘，老的系统盘快照就废了。更换操作系统后系统盘 ID 会变，原有的系统盘快照无法再用于回滚。有些平台更直接——重装或切换操作系统后，系统盘的快照会被自动删除，数据盘快照不受影响。

坑四：删除云盘会带走它的快照。这点各家口径一致或相近。快照的生命周期是绑在源盘上的，盘没了，快照跟着没。

坑五（也是最致命的）：自动快照策略失败是静默的。开头那个故事就是这个坑。配额满、权限变更、地域限制，都可能让定时任务连着失败几十天而没有一个人知道。给快照任务配一条失败告警，比多保留 30 天快照有用得多。

三、方式二：镜像——拿来开新机器，不是拿来回滚数据

镜像常被当成"更完整的快照"，这是个误会。它的定位是模板，不是时间点。

以 ECS 为例，官方对两者区别的描述很清楚：镜像可以直接用来创建实例，快照不行；快照只能用于当前实例云盘的数据恢复。而当你用实例创建自定义镜像时，系统会为源实例的每块云盘（系统盘和数据盘各一份）创建快照，这些快照的集合构成一份自定义镜像。

这条机制解释了几条实操规则：

• 只有系统盘快照能创建自定义镜像，数据盘快照不行；共享快照也不行。想要镜像里带数据盘内容，得在创建过程中手动勾选对应的数据盘快照。
• 删快照时如果它关联着镜像，得先删镜像。反过来，删除自定义镜像时可以选择保留或删除对应的快照。
• 原实例到期释放后，由它的快照创建的自定义镜像不受影响。这条很实用——机器可以放掉，镜像留着当存档。
• 阿里云文档里明确提醒：制作镜像前要清理敏感数据，包括个人文件、密码、密钥、配置文件里的访问凭证。因为镜像是把当前机器整个打包，.bash_history里那条带着 token 的 curl 命令也会一起进去，之后每台用这个镜像开出来的机器都带着它。

所以这套系统级的备份方式适合的是：批量部署相同环境、跨可用区或跨地域还原系统、系统迁移。不适合当日常数据备份——每次都整盘打包，频率上不去，成本也不划算。

四、方式三：文件级备份——服务器备份到本地或另一台服务器

这一层是唯一能在"整台机器没了"时还活得下来的那一层，也是本地留存和跨机同步的主战场。

最常用的是 rsync。一个基础的推送：

rsync-aAXv/data/ backup@10.0.0.2:/backup/data/

-a是归档模式（保留权限、时间戳、软链接等），-A保留 ACL，-X保留扩展属性。

这里有个能毁掉备份的参数：--delete。它会让目标端跟源端保持严格一致，源端误删的文件同步之后目标端也没了——这就是"备份跟着一起被误删"的经典路径。要用可以，但请务必先跑一遍演练看清楚它会删什么：

rsync-aAXv--delete--dry-run /data/ backup@10.0.0.2:/backup/data/

确认输出里没有意外，再去掉--dry-run真正执行。

更稳的做法是不让新备份覆盖旧备份，按日期分目录，未变化的文件用硬链接复用：

rsync-aAX--link-dest=/backup/data/$(date-dyesterday +%F)\/data/ /backup/data/$(date+%F)/

这样每个日期目录看起来都是一份全量快照，实际只多占变化部分的存储空间，rm掉任意一天也不会影响其他天。这条正好对应"服务器自动备份到另一台服务器"的需求——目标机上留的是一串可回溯的历史版本，而不是一份被反复覆盖的最新副本。

数据库要单独处理，靠文件拷贝是不行的（拷出来的 InnoDB 文件大概率不一致）：

mysqldump-uroot-p--single-transaction--routines--triggers\mydb>/backup/mydb_$(date+%F).sql

几个参数不能省：

• --single-transaction：对 InnoDB 开一致性读事务，导出期间不锁表，业务照常写入。
• --routines --triggers：这两个必须显式写，否则存储过程和触发器不会进备份文件，恢复时才会发现少了东西。
• 备份期间不要跑 DDL。ALTER TABLE这类操作可能让 dump 直接报错中断。
• 注意--single-transaction只对 InnoDB 有效，如果库里还有 MyISAM 表，那部分仍会被锁。
• 想做时间点恢复，再加--master-data=2把 binlog 位点写进文件头部。

最后说保留策略。只留最近 7 天是不够的——勒索软件和误操作往往不是当天发现的。业界通行的3-2-1 原则是：至少3 份副本（1 份生产 + 2 份备份）、存放在2 种不同介质上、其中至少1 份在异地。

顺带回答一个高频问题："服务器备份软件哪个好用？"这个问题本身就问偏了。先确定你要防的是误删、是硬件故障、还是整地域故障，场景清楚了，该用 rsync、该用数据库导出、该上带版本管理的备份工具，选择会自己浮出来。

五、物理服务器备份：Windows Server 服务器备份怎么做

物理机没有虚拟化层帮忙，拿不到云盘那种块级快照，能用的手段要换个思路。

Windows Server 自带 Windows Server Backup，命令行是wbadmin：

wbadmin start backup -backupTarget:E: -include:C:,D: -allCritical -systemState -quiet

几条必须知道的规则：

• -allCritical会把所有关键卷（包含操作系统状态的那些卷）打进备份，只有加了它才能做裸机恢复。而且它必须和-backupTarget一起用，单独用会直接失败。
• 备份目标卷不能是被备份的卷之一。把 C: 备份到 C: 是不行的，得挂一块独立的盘或指向远程共享。
• 存到远程共享文件夹时，同一台机器再备份一次会覆盖上一份。微软文档对此有明确警告：如果备份中途失败，你可能落得旧的被覆盖、新的又不可用的两头空局面。规避办法是在共享目录下按日期建子目录。
• 默认是-vssCopy，不更新文件历史记录，不会打乱其他备份软件的增量链。别随手加-vssFull，那会更新历史并可能截断日志。

Linux 侧的物理机和云服务器内，思路一致：文件级同步 + 数据库导出 + 定时任务，且异地必须有一份。定时任务建议用 systemd timer 而不是 crontab——前者可以声明对数据库服务的依赖，重启后不会在数据库还没起来时就开始 dump。

六、各家云平台：快照和备份到底差在哪

同样是叫"快照"，各家实现细节差得挺远，尤其是存哪儿和删盘之后还在不在这两件事。选平台或者做跨平台方案时，这张表值得对着看。

有三条结论是可以直接用的：

1. 快照和备份不是一回事，别互相替代。备份数据与源盘分开存储，源盘损坏甚至被删除后仍能恢复；快照快、便宜、适合回滚，但它跟源盘绑得更紧。
2. 只要"防删盘/防地域故障"是需求，就得上独立备份服务，光靠快照策略覆盖不了这个场景。
3. 跨地域复制是灾难恢复的分水岭。快照解决误操作，跨地域副本解决站点级故障，两者不能省掉一个。

相关官方文档：阿里云镜像概述（含镜像与快照的完整区别表）、腾讯云快照原理、华为云备份、快照、镜像有什么区别。

七、一份能照着配的备份组合

前面把三种方式拆开讲，这一节把它们拼回去。服务器三种备份方式不是三选一，而是按频率和责任分层，各管各的。

先明确两个指标，不谈这两个数字谈备份都是空的：

• RPO（恢复点目标）：能容忍丢多久的数据。每天一次全量，RPO 就是 24 小时。
• RTO（恢复时间目标）：能容忍多久恢复服务。

有了这两个数，配置就定了。一份中小规模业务的常见组合：

最后一条最容易被跳过，但它决定前面四条的生死：恢复演练。

没验证过能恢复的备份，等于没有备份。至少每季度做一次完整的恢复测试——用快照创建一块新盘挂到测试机上看看数据对不对，把 dump 出来的 SQL 真的导进一个空库跑一遍。这步做了，前面所有配置才算数。

回到开头那台服务器。他缺的不是备份工具，是分类：把"改错了能反悔"和"机器没了能重建"当成了一件事，于是只配了自动快照。服务器三种备份方式里，快照是回滚点，镜像是模板，文件级备份是最后一道防线——分清楚各自防什么，比把任何一种做到极致都重要。

各平台的机制、配额与计费会随时间调整，具体以各家官网当期公示的文档为准。