我的书签
添加书签
移除书签第39章 云存储
通过云存储，将个人数据备份在网络上是非常吸引人的服务，比较著名的公司或产品有Dropbox[1]、Surgarsync[2]、Live Mesh[3]、Syncplicity[4]等。这些产品的特点是能够和操作系统的shell整合，例如和Windows的资源管理器或Linux上的nautilus整合，当本地数据有改动时会自动同步到远程的“云存储”上。用户可以在多个计算机或手持设备上配置和同一个“云端”的账号同步，从而实现在多个计算机或多个手持设备上的数据同步。
39.1 现有云存储的问题
遗憾的是我并未使用过上述云存储服务，主要是支持Linux操作系统的云存储客户端比较少，或者即使有也因为网络的局限而无法访问，但是可以通过相关文档了解到其实现的机理。
仅支持对部分历史数据的备份。
Dropbox支持30天数据备份，Surgarsync每个文件仅保留5个备份（对于付费用户），对于免费用户仅保留2个备份。
数据同步对网络带宽的依赖比较高。
“云端”被多个设备共享，冲突解决比较困难。
Surgarsync会将冲突的文件自动保存为多份，造成磁盘空间超出配额。其他有的产品在遇到冲突时停止同步，让用户决定选择哪个版本。
在介绍Git的书里介绍云存储，是因为上述云存储实现和Git有关吗？不是。实际上通过上面各个云存储软件特性的介绍，有经验的Linux用户会感觉这些产品在数据同步时和Linux下的rsync、unison等数据同步工具非常类似，也许只是在服务器端增加了历史备份而已。
已经有用户尝试将云存储和Git结合使用，就是将Git库本身放在本机的云存储同步区（如Dropbox目录下），Git库被同步至云端。即用云存储作为二传手，实际上还是基于本地协议操作Git。这样实际上是会有问题的。
如果两台机器各自进行了提交，云存储同步一定会引发冲突，这种冲突是难以解决的。
云端对Git的每个文件都进行备份，包括执行git gc命令打包后丢弃掉的松散对象。这实际对于Git是不需要的，会浪费本来就有限的空间配额。
因为版本库操作触发的git gc—auto命令会周期性地整理版本库，从而导致即使Git版本库的一个小提交也可能会触发大量的云存储数据传输。
