网站日常备份的核心做法是：程序文件、数据库、配置文件三样分开备，数据库每天一次、整站文件每周一次，并保留日备7份、周备4份、月备3份，而且要有一份放在网站服务器之外的异地存储上。至于多久备份一次，取决于你网站内容更新的快慢——每天都在更新的站点按天甚至按小时备，一个月不动一行的企业官网按周备就够。
备份这件事，几乎所有站长都承认重要，但真正落到执行上的比例并不高。行业共识认为，站点出问题后能不能在几小时内恢复，分水岭就在平时有没有一套跑得起来的备份机制。下面从备份对象、备份频率、方式选择到具体命令，一条条说清楚。
先搞清楚：网站备份到底要备什么
很多人以为备份就是把网站目录打包一份，结果真出事的时候才发现数据库没了，文章和订单全丢。完整备份至少包含四个部分。
四类必须备份的内容
- 网站程序文件：包括主题、插件、模板、用户上传的图片和附件。上传目录往往占了整站体积的大头，不能漏。
- 数据库：文章内容、用户表、订单数据、站点配置都在这里。这是最不能丢的部分，也是体积最小、最好备份的部分。
- 配置文件：Nginx 或 Apache 的站点配置、伪静态规则、PHP 的 php.ini、SSL 证书文件。恢复的时候这些最容易卡壳。
- 域名解析记录：不用定期导，但在做任何解析调整之前，把当前的 DNS 记录截图或导出保存一份，能省很多麻烦。
容易被忽略的缓存目录
打包整站时，缓存目录一定要排除。缓存文件重新生成就行，打进备份包会让体积翻几倍，还会拖慢传输速度。用 tar 打包时加 –exclude 参数，把缓存目录、日志目录排除掉，备份包体积通常能小不少。
网站备份多久一次比较合适
这个问题没有统一答案，但可以按照“能承受丢多少数据”倒推。如果你能接受丢失一天的文章，那就是每天备一次；如果一小时的新订单都不能丢，那备份频率就得往小时级走。下面这张表是不同站点类型的通用参考。
| 站点类型 | 数据库备份频率 | 整站文件备份频率 | 建议保留份数 |
|---|---|---|---|
| 企业官网、展示站 | 每周 1 次 | 每周 1 次 | 周备 4 份、月备 3 份 |
| 资讯媒体、博客 | 每天 1 次 | 每周 1 次 | 日备 7 份、周备 4 份 |
| 电商、有交易的小程序站 | 每 6 小时 1 次 | 每周 1 次 | 日备 7 份、周备 8 份 |
| 论坛、会员社区 | 每天 1 到 2 次 | 每周 1 次 | 日备 7 份、周备 4 份 |
| 长期不更新的冷站 | 每月 1 次 | 每月 1 次 | 月备 6 份 |
这里有个常被忽略的点：数据库和文件的频率不该完全一样。数据库体积小、变化快，天天备成本也不高；整站文件里图片附件多，体积大，多数内容半年内不会变，每周备一次通常够用。分开设定频率，是性价比最高的做法。
哪些时间点必须额外手动备份一次
定时任务覆盖的是“日常”，但有几类操作属于高风险，做之前务必手动打一个包：
- 升级程序版本或替换主题之前，尤其是跨大版本升级。
- 安装、卸载插件期间，插件冲突导致整站白屏的情况并不少见。
- 批量修改数据库，比如替换文章里的域名、清理冗余表。
- 更换服务器、迁移机房的前后。
- 大促、活动上线之前。
虚拟主机和云服务器的备份方式有什么区别
这个问题被问得很多。两者最大的差别在于“你能控制到哪一层”。
虚拟主机：靠插件和手动导出为主
虚拟主机一般不给 root 权限，装不了自建脚本。可行的路子有三条：一是用 CMS 自带的备份插件，设定时任务把数据库和文件导出；二是通过 FTP 或文件管理功能，定期把整站目录下载到本地；三是利用主机商提供的备份服务，这类服务通常是按天或按周做整盘备份，恢复粒度较粗。虚拟主机的备份要特别注意一点：导出的 SQL 文件千万别放在网站根目录下，否则可能被直接下载，等于把数据库公开了。
云服务器：脚本加定时任务，可控性最强
有 SSH 权限的服务器，建议自己写脚本跑定时任务。核心就两条命令。数据库导出用 mysqldump，加 –single-transaction 参数可以在不锁表的情况下拿到一致性快照，对线上业务很关键，不至于备份期间网站卡住：
mysqldump -u root -p –single-transaction –default-character-set=utf8mb4 数据库名 > /data/backup/db_$(date +%F).sql
文件打包用 tar，顺手把缓存和日志排掉：
tar -czf /data/backup/site_$(date +%F).tar.gz –exclude=cache –exclude=logs /www/wwwroot/你的站点目录
然后把备份推到异地。可以用 rsync 同步到另一台备份机，也可以用云厂商的对象存储命令行工具上传。定时任务写在 crontab 里，比如每天凌晨三点跑数据库、每周日凌晨四点跑整站文件：
0 3 * * * /bin/bash /root/backup_db.sh >> /var/log/backup.log 2>&1
脚本里最好加一步体积校验，备份文件小于某个阈值就告警，避免磁盘满了以后生成一堆空文件却没人发现。
网站备份要花钱吗，成本大概在什么量级
备份本身的软件成本基本为零，mysqldump、tar、rsync 都是系统自带。真正的成本在存储和带宽上。如果备份留在本机磁盘，成本可以忽略，但风险极高——服务器整盘挂掉的时候，备份和数据一起没了。所以至少要保持一份异地副本。
异地存储有几种选择：另一台低价服务器、对象存储、家用 NAS，或者定期下载到本地移动硬盘。对象存储按实际用量计费，对多数中小站点来说，每月的备份存储支出通常只是服务器费用的一小部分，量级上不必太纠结。业内专家指出，与其在存储成本上省钱，不如把预算花在验证恢复流程上，因为没验证过的备份，跟没有备份差别不大。
3-2-1 原则值得照搬
这是运维领域流传很广的做法：至少 3 份副本，存放在 2 种不同介质上，其中 1 份在异地。落到实际就是：服务器本地留一份近几天的、另一台机器或对象存储留一份完整的、偶尔再往本地硬盘拉一份。多一道冗余，代价不高，安心感完全不同。
备份做完不等于完事：验证这一步别省
备份文件躺在那里，谁也不知道它能不能用。建议每月抽一次，把最新的备份包解压，导入到一个测试库或者子目录里，真跑一遍。检查三件事：压缩包能不能正常解开、数据库导入有没有报错、网站首页能不能打开。整个过程十几分钟，但能在真出事的时候省掉几个小时的手忙脚乱。
另外几个细节值得顺手处理掉：备份文件权限设成 600，目录设成 700，别让其他用户读到；备份目录放在网站根目录之外；如果是多站点共用一台服务器，备份脚本里把各自的目录和库分开写清楚，不要一个包全塞进去。
说到底，网站日常备份不是一次性任务，而是个需要长期跑着的习惯。频率按内容更新速度定，异地存储必须有，恢复演练定期做，这三件事做到位，站点出问题时就不至于从零开始。
网站日常备份常见问题解答
网站备份多久一次比较合适，有没有通用标准
没有放之四海皆准的标准，判断依据是“能接受丢多少数据”。资讯类站点每天更新，数据库每天备一次是底线；电商和有交易的站点，建议做到每 6 小时一次，配合数据库的 binlog 还能把恢复点推得更细；企业官网内容变动少，每周一次足够，改动前后再手动补一次。
网站备份和服务器快照哪个好，能互相替代吗
不能替代，作用不同。快照是整盘级别的，恢复快、操作简单，适合系统盘损坏、误删系统文件这类场景，但快照通常和原服务器绑定在同一区域，且不方便只取回某一个文件。文件级备份灵活度高，可以单独还原一个插件目录或一张数据表，还能跨平台迁移。稳妥的做法是两者结合：快照负责整机回滚，备份负责精细恢复和异地留存。
虚拟主机没有命令行权限，网站日常备份怎么做
三条路可以并行。用 CMS 的备份插件设置定时导出，把文件直接推到云存储，这是最省事的；定期通过 FTP 把整站目录同步到本地，作为第二份副本；同时确认主机商自带的备份策略是几天一份、保留多久，把它当作最后一道防线而不是唯一依靠。三条路都建立在同一个前提上——备份文件不要放在网站可访问的目录里。