全量备份还是增量备份，网站备份怎么选

全量备份还是增量备份，网站备份怎么选——这问题我被问过不止一次，每次都得掰开讲，因为答案不是二选一。备份这活儿平时枯燥得很，等数据库被一句没加 where 的 DELETE 带走，你才知道当初选的哪种方式救得了你。我先把结论摊在前面：多数中小站点，全量打底加增量补缝最省心，纯用其中一种都有明显的坑。

增量备份省空间，省的是硬盘不是时间

增量的逻辑很简单，只记上次备份之后变化的部分。文件层面用 rsync 加 –link-dest 做硬链接快照，数据库层面靠 binlog 或者定时导出配合，一晚跑下来可能就几十兆。硬盘小、站点数据又大的时候，这个诱惑确实大。

但恢复的时候麻烦就来了：你得先有一份全量，再按顺序把增量一层层叠上去，中间少一个文件、顺序错一步，恢复出来的库就是残缺的。我见过有人把所有增量包平铺在一个目录里，文件名还是 backup_1.tar.gz 这种，过两个月连他自己都分不清哪个在前哪个在后。所以增量适合什么场景？数据天天涨、磁盘又紧、并且有脚本或者工具帮你管这条链。纯手工做增量，除非只做一两次，否则迟早乱套。

全量备份还是增量备份，网站备份怎么选先看恢复目标

判断标准不在备份环节，在恢复环节。你要问自己两个问题：出事的时候最多能丢多长时间的数据，以及想把站多快拉起来。前者对应 RPO，后者对应 RTO，听着像黑话，说白了就是“能丢多少”和“能停多久”。一天一全量，最坏丢一天；每小时一次增量，最坏丢一小时。可一小时一次的增量，恢复链条长，真出事的时候手忙脚乱，未必比一天一全量更快。

所以别一上来就纠结技术名词。先看你的站是什么性质：企业展示站，内容一周更新两三次，一天一次全量完全够；论坛、商城这种有订单和会员数据的，丢一小时的代价不小，那就得往增量或者 binlog 方向走。以自己业务的口径为准，别照抄别人的方案。

还有一层常被忽略：备份覆盖的范围。数据库只是其中一块，网站目录里的上传附件、主题模板、伪静态规则文件、nginx 配置，这些丢了照样要命。选方案的时候顺手把这些列个清单，别只盯着 mysqldump。

差别不在备份那一刻，在你要回滚到哪一天

全量备份像拍照，只能回到拍照那一刻；增量像录像，理论上能回到任意一个时间点，前提是日志没断。数据库这块尤其明显，MySQL 开了 binlog，再配一份基础全量，可以做到按时间点恢复，把误删之前那一秒的状态找回来。binlog 会占空间，保留几天还是两周得自己定，看盘说话。

文件层面就没这么优雅。用户上传的图片、附件被改坏，增量快照能翻回旧版本，但如果你用的是覆盖式同步——很多人拿 rsync 直接往备份目录里推——改坏的文件会把好的备份一起冲掉。那就不叫备份了，叫镜像，两个一起坏。

混着用最实际：全量打底、增量补缝

我自己的习惯是分层。每周固定一个时间做完整全量，网站目录打包、数据库导出，落一份完整包；工作日每天做增量，只抓变化的部分。这样恢复时最多叠五六层，链条不至于太长，空间也不至于爆。虚拟主机用户选择不多，面板自带的计划任务能设全量和增量，够用；独立服务器可以上 restic、borg 这类工具，去重加密都有，恢复也方便。

频率按数据变化的节奏定。内容站一天一次足够，交易类可以考虑更密，但别为了心安把频率拉到每十分钟一次，结果磁盘写满、备份进程把 IO 拖垮，那就是自己给自己找事。备份窗口尽量放在访问低谷，这点不用多说。

备份文件放哪儿，比备份频率更容易翻车

备份放同一台服务器上，等于没备份。机器被黑、磁盘挂掉、机房出状况，原件和备份一起走。稳妥的做法是异地留一份，对象存储现在最省事，配上生命周期规则，旧版本自动过期。前提是桶权限别开成公共读，我见过备份包裸奔在公网上，里面还连着数据库导出的 SQL，谁扫到谁下载。

还有个细节：备份文件本身要不要加密。带手机号、订单信息的库，导出之后建议加一层对称加密，密钥千万别跟备份放同一个地方，否则等于把钥匙插在锁上。

验证一次恢复，胜过每天看日志写成功

备份任务返回 0，不代表备份能用。tar 打包时磁盘满了，日志可能照样打“完成”；数据库导出时锁表失败，文件也可能只生成一半。最靠得住的验证，是定期拿一份备份在另一台机器上真恢复一遍，看看表在不在、图片能不能打开、后台能不能登录。这动作一季度做一次就够，可很多人一次都没做过。

保留策略也得写清楚：留几份全量、增量留多少天、什么时候删。不删磁盘迟早撑爆，删太勤又容易把好版本轮转掉。一般留最近几周，改版前、大促前这种节点手动留一份长期包。

几个常见的偷懒方案和坑

第一类坑是觉得有服务商自动快照就完事。快照能救系统盘崩溃，救不了误删数据和被挂马改文件这类逻辑错误，因为快照是跟着磁盘一起回去的，中间产生的新数据也一起没了。第二类是把数据库导出当成备份的全部，网站目录里的附件、插件配置没人管，恢复出来是个空壳站。第三类更常见：没有记录，谁也不知道上一次改过什么、脚本被谁动过。

收尾说句实在的：备份的验收标准只有一个，真出事时你能不能在可接受的时间里把站恢复出来。全量还是增量、怎么组合，按你的数据量、磁盘和恢复目标去定，别迷信某一种方案。实在拿不准，就先从一天一次全量跑起来，动手永远比纠结一周强。