酷居科技我习惯把一些网站项目放在 OneDrive 目录里。这样做最直接的好处是省心：换一台电脑，源码、图片和说明文档很快就能接着用，临时改过的文件也不用再手工复制。
但用了一段时间以后，我越来越确定一件事：同步很方便，却不能代替版本控制，更不能代替网站备份。
这三件事看起来都在“保存文件”，实际解决的问题完全不同。如果把它们混在一起，平时感觉不到，真正删错文件、改坏程序或服务器出问题时，就会发现手里的副本并没有想象中可靠。
OneDrive 解决的是“文件跟着我走”
OneDrive 最适合处理的是跨设备同步。电脑 A 保存一个文件，电脑 B 很快也能看到；系统重装后，常用资料可以重新下载；偶尔误改文档，还可能通过版本历史找回来。
对于图片、资料、导出的安装包和项目说明，这种体验很好。问题在于，同步工具会忠实地传播变化，包括错误的变化。
如果我误删了一批文件，这个删除动作也会同步；如果某个程序突然重写了几百个文件，OneDrive 不知道哪些修改有意义；如果两台电脑同时编辑，目录里还可能出现冲突副本。它保存的是文件状态，却不理解这次修改到底是修复了问题，还是制造了问题。
Git 记录的是“为什么变成这样”
Git 对我最有价值的地方，不只是能恢复旧文件，而是把一次修改整理成一个有意义的节点。
例如修改网站主题时，我可以留下这样的记录：
修复手机端菜单遮挡正文
调整文章页代码块样式
升级依赖并保留旧版配置过一段时间发现页面有问题，可以沿着提交记录检查是哪一次改动引入的，也可以只恢复某个文件，而不是把整个 OneDrive 目录退回到昨天。
云同步告诉我“文件什么时候发生了变化”，Git 则更接近告诉我“这一组变化是为了什么”。对于源码，这个区别非常重要。
.gitignore 管不了 OneDrive
这是一个很容易忽略的小细节。项目里的 .gitignore 只决定哪些文件不进入 Git，并不会阻止 OneDrive 同步。
像 node_modules、编译缓存、临时日志和本地构建结果，通常不应该提交到 Git；但只要它们位于 OneDrive 同步目录，OneDrive 仍可能逐个处理。文件一多，同步速度、磁盘占用和冲突概率都会变差。
小项目问题不大。遇到依赖文件很多的项目，我更愿意只保存源码、配置清单和锁定文件，需要时重新安装依赖。再大一些的项目，则直接把工作目录放在普通本地磁盘，用 Git 远程仓库同步代码，把文档和最终产物单独放进 OneDrive。
源码有了副本，网站数据仍然可能没备份
WordPress 这类网站不只有程序文件。文章、评论、用户信息和大量设置通常保存在数据库里，上传的图片又在另一个目录中。
所以，仅仅同步一份主题源码，并不能在服务器故障后恢复完整网站。真正可用的备份至少要考虑：
- 网站源码和自定义主题、插件；
- 数据库导出文件；
- 上传目录中的图片和附件；
- Web 服务器、定时任务等关键配置；
- 域名、证书和外部服务的恢复信息。
这些备份最好带日期，并保留不止一个时间点。只有一个会不断被覆盖的副本，遇到问题时很可能已经同步了损坏的数据。
我现在采用的简单分工
为了不把流程弄得太复杂，我给三种工具做了明确分工：
- OneDrive：保存项目资料、图片、说明文档和需要跨设备使用的小型项目；
- Git：管理源码修改，记录每次可解释的变更，并同步到远程仓库；
- 独立备份：定期保存数据库、上传目录和服务器关键配置。
敏感信息则单独处理。应用密码、数据库密码、私钥和访问令牌，不写进源码，也不因为 OneDrive“只有自己能看”就直接放在普通文本文件里。能用系统凭据库就用凭据库，必须保存文件时也至少先加密。
最后还要做一次恢复测试
备份最容易给人一种虚假的安全感：文件看起来都在，直到真正恢复时才发现数据库导入失败、图片目录不完整，或者根本不知道配置应该放回哪里。
我现在会偶尔找一个临时目录，重新拉取 Git 仓库，按照说明安装依赖，再确认备份文件能否正常打开。网站的重要备份也应该在不影响线上服务的环境中试着恢复一次。
只有恢复成功过的备份，才算真正可靠。
OneDrive、Git 和服务器备份并不是互相替代的三种方案。它们更像三层保护：同步让文件随手可用，版本控制让修改有迹可循，独立备份则负责在最坏的情况下把网站重新搭起来。分清各自的职责以后，日常维护反而会简单很多。
