林健的BLOG

　　受 @Sisyphusliu 师兄的启发，我最近决定试用 Amazon S3 来做个人数据同步与备份。初步计算发现这很可能比之前使用 VPS 或 Web 主机的方案要节约成本。我对三款面向 Amazon S3 的开源文件同步工具进行了对比，将其中部分细节说明如下，供有相同需求的朋友参考。
　　这三款工具分别是 jets3t、s3cmd 和 s3sync.rb。其主要特性和附加功能这里不再赘述，它们的官方主页都有详细说明。软件的稳定性还有待长时间使用的考验，但从网上没有发现用户反映太大的问题。我在这里强调它们存储文件元信息的差别，以及由此可能引发的问题。

　　由于 S3 基于 Key-Object 存储方式，与树型文件系统不同，因此如何将树型结构组织的文件及其元信息存储在 S3 中就是一个问题。这三款工具都将文件的全路径作为 Key，并把文件的元信息保存在 Object 的自定义属性中。
　　这样有什么后果呢？首先看目录。稍稍想想就会发现，像“a/b/c”这样的 Key 无法直接判定“c”是一个目录还是一个文件。s3cmd 的处理最简单，它的任何一个 Object 都是文件，不把目录作为 Object 保存。这样消除了歧义，但导致了目录的元信息无从保留，同时也无法保存空目录。而 jets3t 和 s3sync.rb 会保存目录的 Object，并通过元信息中的 Content-Type 来区别文件与目录。这样就保留了目录元信息，也允许空目录存在，但这影响了工具之间的互操作性。下载另一个工具上传的文件时，工具彼此不认识对方的目录 Object，就会将它们保存成普通文件，从而造成同名的目录无法创建。
　　再来看看文件的元信息。s3cmd 保存的 s3cmd-attrs 属性是一个包含了 uid、gid、uname、gname、mtime、atime、ctime 等信息的字符串，因此它保留了最完整的文件元信息。jets3t 只保存文件修改时间，无从得知属主与权限，不适合保存可执行程序的目录；s3sync.rb 只保存属主与权限，而且是数字 id 而非名字，在新系统中恢复数据时可能出现映射错误。
　　我个人倾向于选择 s3cmd。其一，文件修改时间和权限对于个人程序、文档来说是比较重要的信息。当然这不是技术问题，修改 jets3t 和 s3sync.rb 肯定也能做到。其二，不使用自定义的目录 Object 就允许一定程度的互操作，例如使用 jets3t 和 s3sync.rb 可以直接下载 s3cmd 上传的文件与目录结构（元信息丢失）。而 s3cmd 设计造成的目录元信息缺失、空目录消失等问题，对一般应用和文档来说不太重要、相对容易恢复。当然也可以使用额外的机制来记录目录元信息，但考虑 KISS 原则，s3cmd 目前的设计还是有道理的。要想同时解决元信息与目录问题，容易想到的办法是将目录打包或压缩再上传，这比较适于长周期的文件归档备份场景，但对于细粒度、短周期的日常数据同步场景并不适合。
　　至于云存储的信任问题，在现阶段我也只能选择折衷。一方面不要将鸡蛋放在一个篮子里，重要数据还是需要异地备份的。另一方面可以使用这些同步工具自带的安全机制，或自己稍加封装实现数据加密。
　　最后提醒大家，务必看看 Joel 的备份观。

　　使用 web 主机而非 VPS 的站长，站点的备份或同步常常是一个问题。很多站点只能使用 ftp 做单向备份，基于较弱的元信息来判定文件是否需要重新下载，缺乏校验、压缩、增量传输等高级特性。有的服务商在 web 控制面板中提供备份功能，或允许上传简单的 cron 脚本，但这些途径通常只适合备份整站或指定目录，而不方便以增量方式传输更新过的内容。Linux 下成熟的镜像同步工具是 rsync，如果你的 web 主机允许 ssh 登录，则可以考虑使用 rsync 或其它类似工具。
　　网上有很多说法认为 web 主机不允许跑 daemon、不允许开自定义端口，故而无法使用 rsync。其实不然，rsync 可以仅通过 ssh 连接而不需要开放额外的端口，服务端也可以借助 sshd 来启动而不需要作为 daemon 运行。我们需要的只是 ssh 登录以及运行自己上传的程序的权限。我使用的 Godaddy Economy Plan Hosting (Linux) 即属于这种情况。
　　Godaddy 的 web 主机不提供 rsync 程序，我们可以从本地上传一个。需要注意上传的 rsync 二进制文件应该与你的 web 主机的平台一致，连接 libc、libpopt 等库的版本一致。对于使用 x86 版 CentOS 5.2 的 Godaddy 主机，我也直接在相同版本的 CentOS 中提取了一个 rsync 上传。这时，在客户端使用“-e”参数指定连接方式为 ssh，用“--rsync-path”参数指定服务端 rsync 所在的位置，即可借助 ssh 连接传输数据了。

　　如果客户端为 Windows，则可以使用 Win32 下移植的 cwRsync，这个工具基于 cygwin 库但不需要安装整个 cygwin 环境，它同时包含了 Win32 版的 OpenSSH 客户端。上述命令无须修改即可在 Windows 下运行。
　　rsync 解决了文件的单向的备份或镜像功能，但如果需要双向同步，更适合的工具是 unison。unison 使用 OCaml 语言开发，基于 rsync 算法对两端文件进行比较，将它们更新到一致的状态（最新的、不冲突的版本）。unison 可借助 socket、ssh 等连接方式，并支持多种操作系统。与 rsync 类似，我们需要向 web 主机上传一个 unison 二进制文件。官方只提供了最新版的源代码，需要自行下载到本地编译（事先安装 OCaml 编译器及 etags 工具）。服务端部署之后，客户端配置文件（[config_name].prf）为：

　　在客户端执行 ./unison [config_name] 即可完成双向同步。注意 unison 要求服务端和客户端的主次版本号一致。
　　如果客户端为 Windows，同样可以使用来自 cwRsync 的 ssh 命令。如果嫌这个 ssh 外加 cygwin 库的体积太大（~5M），另一种替代的方案是使用 Putty 提供的 Plink 工具。这是一个小巧的 Win32 ssh 客户端（276K），由于运行参数与 OpenSSH 不同，因此需要写一个批处理文件（ssh.bat）来封装：

　　并在 unicon 配置文件中指定 ssh 命令：

　　此时运行 unicon，即可使用 Plink 进行 ssh 连接。
　　无论使用 OpenSSH 的 ssh 还是 Putty 的 Plink，都可以借助公钥认证方式避免密码的输入。这样有利于定时备份和同步的自动化执行。具体方法不再赘述。