网站备份：本地打包还是云端同步

备份最难受的时刻不是没做，是做完了恢复不出来。每次有人问我网站备份本地打包还是云端同步，我第一句都不是问预算多少，而是问：真出事那天，你打算多久把站点重新拉起来。这个答案不一样，选法就完全不一样。跟风买了对象存储、或者抱着一堆 tar.gz 睡大觉，两边都有白花钱的可能。

网站备份本地打包还是云端同步，先定恢复目标

恢复目标说白了就两件事：能容忍丢多少数据，能容忍停多久。日志型的内容站，丢半天数据也就那样；接过单的商城，丢两小时订单就是事故。停一小时和停一天，对做外贸的站完全是两个概念。先把这两个数写下来，再谈方案，不然选什么都是拍脑袋。

我自己习惯分两档：核心站点走云端版本化，再加一份异地本地副本；纯展示的小站，本地打包加偶尔一次云上冷备，够用。别一上来就追求完美方案，很多人是方案没落地，数据先裸奔了半年。

本地打包的好处太直接了：脚本一跑，目录一压，速度受内网带宽限制，基本不花钱。坏处也同样直接——备份和原站在同一个机房，断电、水淹、勒索病毒横向加密，一次全带走。我见过最离谱的做法，备份文件就放在网站根目录下面，被人顺着扫目录直接下载走。

还有一类是硬盘级备份，把整个数据盘做快照。这个对系统崩了很有用，但你要单独恢复一个被误删的文章或者一张表，就得整盘挂回去慢慢翻。粒度太粗，日常不好使。

打包脚本里我会排除缓存、日志和 session 目录，不排的话压缩包体积翻好几倍，恢复时还容易把旧缓存带回去。命名带上日期，找起来不抓瞎。

同步和备份不是一回事，这点很多人混着用。同步是这边删了那边跟着删；备份是要在源数据没了以后还能拿回来。见过用云盘同步工具做备份的，员工误删了上传目录，十分钟后云端那份也空了，版本保留刚好过期。

真要用云端，至少确认三件事：版本保留多久、删除后能不能找回、出网流量和请求怎么计费。这三条各家口径不一样，以服务商官方页面说明为准，别听销售一句话就签。另外密钥权限要拆开，能给只读就别给读写。

对象存储那边要注意生命周期规则，有些默认几个月就转归档或者删掉，你以为是永久，结果早就凉了。规则建完手动查一次生效情况，别等出事才发现。

还有一种折中做法：脚本先在本机打包，再推到对象存储，本地留最近两份、云端留长周期。这样带宽和成本都压得住，恢复时先拿本地那份，坏了再去云上翻。

网站目录备份得再勤，数据库拉垮一样白搭。MySQL 用 mysqldump 导出时加上 –single-transaction，InnoDB 能拿到相对一致的点；字符集参数别省，不然导回去满屏问号。直接在线拷贝 .ibd 文件这种操作，除非你很清楚自己在干什么，否则别碰。

WordPress 这类程序还要多看一眼 wp-config.php 和上传目录，插件配置、表单数据常常散在数据库里。备份脚本写完先在一台临时机器上跑一遍完整恢复，比什么都强。

压缩包能不能解开、数据库能不能导入、图片链接有没有 404，这些只有真恢复一次才知道。我一般建议每季度挑一个备份，恢复到临时目录或者临时库，跑一遍首页和后台登录。花不了多少时间，但能提前发现脚本早就不工作了——很多人的定时任务失败半年没人看。

云端便宜的是存储，贵的是出网流量和恢复时的下载时间。一个几十 G 的站，全量拉回来可能比停机还难熬。所以增量、按时间点合并这些策略要提前设计。本地那份则要算硬盘和人力，别指望谁都能记得每月手动拷一次。

回到那个问题：网站备份本地打包还是云端同步。我的做法是两条腿走路，云端存版本、本地存速度，中间用定期演练把它们串起来。真要给个偷懒版：内容站本地打包加一份云上冷备；有交易和客户资料的，云端版本化加一份异地本地副本，再加季度恢复演练。备份的价值只在恢复那天体现，平时它什么都证明不了。