先记住这个答案
因为集中式 VCS 依赖中央服务器存储全部历史，服务器宕机或网络断开时无法提交和查看历史；且服务器磁盘损坏若无备份会丢失全部数据。Git 的每个克隆都是完整仓库镜像，包含全部分支和历史，因此本地可离线提交、完整备份，并支持灵活的分支协作模型。
- 克隆即完整备份，含全部历史
- 本地提交无需连接中央服务器
- 服务器丢失可用任一克隆恢复
本地完整副本与增量差异的机制区别
集中式 VCS（如 SVN）的客户端只保存工作区文件的当前快照，完整的历史记录和版本数据库都在服务器。每次提交都要把差异发送到中央服务器，由服务器计算并存储新版本；离线时无法提交，也无法查看服务器上的历史版本或进行依赖服务器数据的版本比较（但本地工作副本的简单 diff 仍可进行）。
Git 的每个克隆都是仓库的完整镜像，包含所有提交对象和分支引用（包括远程跟踪分支）。git commit 在本地创建提交对象，无需网络；git log、git diff 等历史操作也完全本地化。除初始 clone 外，与远程交互主要发生在 push、pull、fetch 时。
飞机舱内代码修复场景
假设开发者乘飞机时发现一个紧急 bug，需要修改代码并建立提交以便下机后推送。若使用 SVN，在无网络环境下无法提交，只能复制文件到临时目录，易丢失且与后续提交无关联。使用 Git 时，git commit 在本地完成，提交被安全记录，下机后只需 git push。
若在飞机上创建了多个提交，且后续想整理为一个清晰的历史，可以稍后使用 git rebase -i。整个过程不需要远程仓库参与。这体现了 Git 的完整本地仓库不只是缓存，而是独立的版本库。
副本完整性依赖同步时机
克隆副本虽完整，但只是克隆时点的完整。若开发者长期不 fetch 或 pull，本地副本缺少远程的新分支和提交，不能视为最新备份。服务器故障时只能用最近同步过的克隆恢复，数据损失窗口取决于最后一次同步。
要降低风险，应定期 git fetch 并确保至少一个克隆的引用更新。恢复服务器时，需要手动设置 remote 并推送所有分支。分布式不是自动热备份，需要团队约定同步周期。
容易答错的地方
- 分布式意味着每次操作都无需网络
- 错误。只有本地操作离线可用，clone、fetch、pull、push 仍需要网络。如果从未克隆过某仓库，离线无法获取历史。
- 集中式 VCS 的本地工作区就是备份
- 工作区只是当前文件状态，没有历史版本。至少需要本地数据库才能恢复，但集中式客户端通常只有快照，删错了文件可能无法找回。
面试官还会怎么问？
Git 克隆和 SVN checkout 有何本质差异？
git clone 下载所有版本历史并创建完整仓库，svn checkout 只获取工作文件。因此 Git 可以在本地查看任何历史版本，SVN 则需访问服务器。
如果中央服务器永久损坏且没有备份，但有一个开发者的克隆，能否恢复仓库？
可以。该克隆包含全部提交和分支，只要把它重新设为远程仓库的源并 push 过去即可。但可能缺少其他开发者的尚未推送的本地提交。
分布式模式能否完全替代定期备份？
不能。分布式只是把数据分散到多个克隆，如果所有克隆都丢失或损坏（如同时删除本地目录），数据仍会永久丢失。仍需对重要远程仓库做离线备份。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。