利用树莓派和Amazon Drive备份照片

写在前面

Amazon Drive $59.99/年，无限空间，是非常适合文件备份的，特别是照片和视频，随着拍照设备的普及，加上拍照创作欲望的不可阻拦，又受限于本地存储的容量，不得不忍痛割爱，定期选删，再选删。

云存储服务中，应该选择既安全又开放的，即使付费的也是值得的，相比较照片丢失时需要承受的痛苦，你可以想象一下。

不要使用那些以免费或容量做噱头的服务，这么一提，也许你应该还能想起起那些陆续宣布关闭服务的号称永不收费的云盘，还有某云盘，会悄悄的塞些莫名其妙的文件到你的存储空间，比悄悄的删你文件还吓人。

云盘，被定义了很多次，但本质上是本地磁盘的云端扩展，是私人存储，只是在远端而已，想象一下，你的私人存储，可以随意被人浏览甚至修改（随意=非授权），爽么？

为什么要选择Amazon Drive？

最开始选择有三个，Google Drive、iCloud、Amazon Drive，三者价格其实相差不是很大，唯一区别是只有Amazon提供了无限空间，详细功能参数等不做赘述，有兴趣的朋友可以自行比较。

iCloud必须要同步，一直没搞明白如何删除本地的而保留iCloud中照片，如果有朋友知道请指点。因此iCloud被用来同步除了照片之外的应该同步的资料和文档了。 Google Drive要翻墙，就麻烦了许多，但是很多重要文件还是存放在Google，特别是早年间（不用梯子的时代），一直留存的文件都在Google上，嗯，企业邮箱就是G家的，用满了好几个邮箱，不停的开账号设别名。

新启用的Amazon Drive，被我定位照片视频备份，速度不快，但求稳定，事实也确实靠谱，既开放又安全。

这里说的Amazon Drive指的是 [.com]而不是 [.cn]的服务，请大家注意。[.cn]的只提供5G免费空间，没有其他选项，也不提供付费服务（至少在发文时是这样）。

写到这里，看起来更像是软的不能再软的文，口水的厉害。

那么现在开始，讲讲这个复杂却又不长的故事。

事件起因

2011年家里有NAS（Thecus N2200），一般用来存储备份的文件、收藏的电影、生活中拍的照片等，爱人称其为神器，又能备份还能存照片，访问还挺方便，就是慢了些。她花了大量时间和精力在神器上，按事件、时间、人物等把照片整理的井井有条，还区分出哪些是打印成纸质的照片；回顾浏览时也能方便快捷，不至于混乱。可见她在此花费了不少心血来的。

此后几年间，神器一直服务良好，缓慢且稳定，24小时运行，偶有罢工重启就好。因此不再费心折腾，无数次的血泪经验告诉我，手欠折腾的代价是高昂的，能用且用着就好。

直到2016年秋天，神器不能访问了，重启无效，意识到，坏菜了，没有做好备份工作，修不好就完蛋了。

这神器先是单块2T硬盘直接使用，后来加入一块1T盘做JBOD，事情就出在JBOD上。两块硬盘挂到Linux系统中，发现无法挂载JBOD设备，应该是分区表损坏了。

花了一周多的时间研究JBOD原理、研究数据恢复技巧、跟朋友们各种方式的沟通讨论、能找到的所有的数据恢复和磁盘工具的尝试等等等等，最后，未果，数据还是恢复不了，感觉非常的糟糕。

这时候，后悔、懊恼各种不已。为什么就没有多备一份，为什么没有上传到云，现在什么云都有的，为什么就安逸了呢？

求爷爷告奶奶，拜天拜地都没用，神器上其他文件都可以不要，最重要的就是老婆大人辛辛苦苦按事件、时间、人物等整理的照片，还区分出哪些是打印成纸质的照片，这要是找不回来，岂不辜负了她的心血。

说到这儿，大家应该明白为什么写在前面的那段废话了吧。

维修过程

维修的过程其实就是等待的过程，毕竟不能自己动手了，花钱消灾，等待就好。

打个广告，[雷超科技]，专业数据恢复，创始人就叫雷超，拥有多项数据恢复专利，很多数据恢复公司使用的硬件卡和工具软件都出自他们。

磁盘送去后，先扫描，看看是否可以数据找回，如果可以找回，再谈价格，不能找回，自然就不要钱了。数据找回后，如果不拷贝带走，也不要钱丼。想想还是挺良心的，最终，那些年存下的照片，在一周的等待里，找回来了。

备份策略

前车之鉴，后事之师，何况是自己亲自踩过的坑。

照片是找回来了，以后如何避免这样的灾难呢？备份的策略如何制定？让人焦虑。

在这里我又犯了工具论的错误。

认为重点在于提高神器稳定性以降低灾难概率，外加网络备份即可，并由此陷入了NAS选型的辛苦工作中。甚至考虑是不是要用树莓派+DAS设备，在家里搭建存粹的存储阵列，不知怎么想的当时。

后来，英明神武的领导发话了：“那些复杂的我搞不懂，按照我理解，简单的就是最好，同时备份到三五个硬盘，总不能它们一起坏掉吧。”

在我们家就这点好，什么问题都可以发表意见和讨论，很快我就友好的接受了领导的指示，并且稍做了些扩展，更稳妥一些，那就是Amazon Drive。

好吧，现在来看看我们有些什么：

• 250G 2.5吋 SATA硬盘 x1
• 2T 3.5吋 SATA硬盘 x2
• 1T 3.5吋 SATA硬盘 x1
• Thecus N2200（空盘） x1
• 树莓派一代 Model B x1
• Amazon Drive

设想是这样的：

1. 由一个大容量、高速度的可靠移动硬盘做原始盘，称之为A，用于汇总所有照片和视频，老婆大人整理工作可以在A上完成，列表中的硬盘没有符合本条件的，需要另外配置，这也是本次架构迭代唯一一项费用支持。
2. 250G小盘做冷备份，称之为B，每次A有更新，同步到B。
3. 1T盘做冷备份，称之为C，每次A有更新，同步到C。
4. N2200将装载两块2T硬盘，组成RAID1整列，作为本地在线备份，称之为神器，每次A有更新，同步到神器。
5. B、C、神器的内容，都由A直接同步，同源避免多节传递的误差。
6. Amazon Drive作为远程在线备份，称之为ACD，由于上传云端速度较慢，把A一直挂在电脑上或者树莓派上不适合往ACD同步，因此树莓派承担神器到ACD同步的控制器，实现无人值守。

这样，我们就有了A、B、C、神器、ACD五个备份点，这样算是比较安全的了。

综合比较之后，为A配置的是LaCie RuggedMini 1T，要经常操作，所以Rugged系列比较好，考虑每年增加照片量不到100G，1T的容量也足够支撑些年头了，到那时再扩展或重新考虑备份策略也是OK的，没有一劳永逸的架构，大家不总这样说么？当然了，B有可能是最先被装满的，也许过些时候应该为B更换大容量磁盘，现在先让它们工作起来再说。

备份的执行

流程是这样的：

1. A被更新后，把A挂载到rMBP
2. 挂载B，rsync A -> B
3. 卸载B
4. 挂载C，rsync A -> C
5. 卸载C
6. NFS挂载神器，rsync A -> 神器
7. 卸载神器
8. ssh登入树莓派，启用tmux， 执行rclone sync 神器 -> ACD
9. 该干嘛干嘛去吧，过几个小时再来看看结果就好

两块磁盘之间同步目录文件，用rsync非常合适而且速度合快，不管A里面是修改、增加、删除，都会同步过去，比拷贝/粘贴好用多了。

另外，[rclone]是开源的云端同步项目，支持：

• Google Drive
• Amazon S3
• Openstack Swift / Rackspace cloud files / Memset Memstore
• Dropbox
• Google Cloud Storage
• Amazon Drive
• Microsoft One Drive
• Hubic
• Backblaze B2
• Yandex Disk
• The local filesystem

还有，树莓派的系统Raspbian，很久以来按照官网操作安装完后无法ssh登入。

直到前几天，无意中点开了release notes，发现了这句话：

'' * SSH disabled by default; can be enabled by creating a file with name "ssh" in boot partition

至此，故事讲完了。

备份工作就这么进行着，每次备份，人工操作需要花些时间，大都是执行命令和拔插挂载硬盘而已，谨慎的进行就好。