![Time Capsule](/resources/2018/mac-data-loss-time-capsule.jpg) Time Capsule

一、我的水果笔记本

2014年入了当年的新Mac,记得这貌似是难得的屏幕下面没有印制文字的版本。用了4四年到了2018年几乎也没有出现什么问题,所以每次看到设置项中的时间机器选项虽然觉得非常必要,但是也没有真正想过来一次备份。说道Mac的好处其实有很大一部分是水果全家桶的功劳,Mac也同样的有非常高的一致性,虽然这点没有iOS来的高。对于开发者来说其固态硬盘和Unix环境真的是让人很难拒绝,而我还有自己的需求那就是文字。

说真的我第一次在益田的水果店看到Mac屏幕的时候真的给我很大的冲击,虽然一开始键位并不是很舒服但是那种打字的感觉和字体渲染效果让我非常着迷。之后我的大部分文字工作都在Mac上完成,包括了很多很多内容。

二、数据损坏

七月的某一天紧张工作中,我终于遇到了传说中的机器进水事件。当时我还认为Mac本进水擦擦就好了,但是我在拿风扇吹机器的时候拿手机查了一下突然意识到问题的严重性。但是我脑海中一闪而过的是我有大量的文章还没有备份,以及常用工具链和相对繁琐的配置信息。

![startup disk](resources/2018/mac-data-loss-startup-disk.png) 启动磁盘

我赶紧请假去找地方修理,Apple Store预约要好几天,授权维修根本不修电脑,这时候万能的第三方维修出现了。诊断结果是硬盘损坏,键盘损坏。当拿到像内存一样的SSD硬盘的时候我立刻去了传说中的华强北,但是那里的数据恢复公司都说没救了。我怀着最后的希望去了益田Apple Store问有没有数据恢复的方法,那里更是直接说让我去找三星问(黑人问号.jpg)。

Apple家的东西我想大家都有所耳闻,如果你没有遇到问题那么用起来非常舒心,不需要三天两头折腾。否则你如果另外买了XX Care,也好一些。否则你想让他们帮你解决个问题,真的是太困难了。比如就是否认设备有问题,比如高额的维修费用。比如我现在的机器有轻微的漏电现象,这这种问题都是众所周知了但是Apple Store的工作人员就是那个什么“天才吧”就是在否认,我拿着电笔量给他看他都不承认。我几天前才在他们眼前买的机器,这么快就翻脸我真的很气愤。但是这么有什么办法呢,所以这四年多我去哪里都有带着沉甸甸的三相插头。

三、数据恢复

在拿到了换过硬盘的新机器后,看着全新的系统我感到我未来有很长一段时间我都要为数据恢复努力了。至少是三到四个月。

3.1 iCloud

如果有多个苹果设备的话,我想绝对会对多设备数据同步惊叹不已,而这背后离不开iCloud的支持。

这里不得不说一下方面国内做得最好的是小米公司,小米公司拥有庞大而多样的设备,依靠其mi cloud已经达到了相当好的用户体验。

3.1.1 系统应用

![iCloud空间管理](resources/2018/mac-data-loss-icloud.png) iCloud空间管理

对于系统级的配置信息在登录apple ID后都会直接同步下来,这其中主要是钥匙串。所以之前保存过的认证信息,如网站登录信息,WIFI热点等都会恢复。其次是系统级应用如备忘录、日历、提醒事项等都会在第一时间同步,而如果你在iCloud中备份了桌面等个人信息,那真的是登录就完全恢复之前的工作状态。

3.1.2 第三方应用

第三方应用也同样可以使用iCloud做数据备份,这更多的是工具类应用,比如我最常用的1Password。另外的文档类,独立游戏等都可以进行数据备份,非常的方便。不过常用的第三方应用大多是比较通用的文档类处理工具,像WPS之类的有自己的云服务直接做云端备份。而其它大部分应用做iCloud备份其实都不怎么好,毕竟其它平台并没有iCloud,那么这就只能使用私有云做备份了。

![Bear](resources/2018/mac-data-loss-bear.png) 订阅类付费应用

另外一些比较特殊的收费的或根本不提供同步的应用,就需要专门做处理了。比如像bear这种比较优秀的笔记类应用如果没有付费订阅是无法使用多平台同步功能,还有比如Quiver这类对代码非常友好的笔记类应用本身都不支持同步功能。

此外还有大量的配置信息如各类IDE的样式风格配置,工具软件特殊配置等等。这些分散在各处常用的或者设置之后就完全遗忘的信息,都需要专门的归类与备份保存。这时候就需要一些云服务做长久存储,而非使用U盘或移动硬盘这种不可靠的额外硬件。

3.2 第三方云服务

这里的云服务更多的是指提供类似于网盘功能的多端同步服务,这些服务有大名鼎鼎的Dropbox,耳熟能详的OneDrive以及常用的百度云。这里找了一份它们之间的对比。

![云服务](resources/2018/mac-data-loss-cloud-service.png) 常用云服务对比(网盘)

其实我想大部分没有特殊要求的朋友都会使用百度云,尤其是日常各类乱七八糟的东西都往上放。对我来说百度云上的东西过于繁杂,而且都不是需要多端同步的东西。基本是放些大文件,更多的还是收集网络上共享的各种资源。

OneDrive作为微软的云服务,如果使用过著名的笔记应用OneNote我想都会对它在国内的同步速度感到无语。OneDrive对Office有比较好的支持其它的比较一般,而且个人对微软的东西没多少好感,总觉得巨大笨重。

![坚果云](resources/2018/mac-data-loss-nut-service.jpg) 坚果云

其实我很早之前就对坚果云很在意,通过这种事件我终于下定决心将各种角落的配置信息做一次云端备份了。对于个人用户来说坚果云的免费版也已经完全够用了,将来如果有特殊要求再进行付费升级也是可以的。

四、知识管理

说道数据丢失我不得不多一下个人知识管理。

我们如何系统的记住某一系列的知识内容?我们如何对某个领域的知识进行长期的积累?我们又是如何对某项只是进行定期学习?

答案就是建立起个人的知识体系,做好个人的知识管理。

关于知识管理的好处以及如何执行有太多的资料和说明了,但是如果真的要做还是要找到适合自己的方法。

![印象笔记](resources/2018/mac-data-loss-evernote.jpg) 印象笔记

对于我来说我的知识收集和整理的核心都放在了印象笔记里。

其实我非常喜欢OneNote的文档组织方式和结构,同时对于它强大的功能印象非常的深刻。在windows平台还算可以,但是在Mac平台它却如同Office for Mac一样体现出了一样的臃肿感。再加上莫名的文档同步出错,以及在国内免费用户糟糕的同步体验。我只能选择相对比较轻量又稳定的印象笔记。

由于印象笔记自己的同步机制,这次对于我总结的核心知识并没有过多的影响。那种新电脑登录之后熟悉的资料自动同步出来时的喜悦心情,我现在还记忆犹新。

知识收集

知识收集是这次数据丢失损失非常惨重的地方。

我们每时每刻会遇到各种各样的知识和信息,特别是移动互联网时代的信息爆炸式的增加。我们每天接触到的信息是处于严重过载的,这时我们并没有获得知识的喜悦反而是陷入深深的焦虑。

![思维导图](resources/2018/mac-data-loss-mindnode.png) 思维导图

无论是稍后阅读还是保存的各类网页剪切,要做的都是专门的花时间进行重新阅读归纳,最终融入个人的自己知识体系中。对于我来说是最终保存在印象笔记中。

对于相对比较繁杂一时看不清楚或者需要跟高的抽象才能理解的知识,这时候就需要归纳和总结的神器思维导图了。思维导图作为动态个结构化大纲,比起平面和线性的文档更能激发我么的思维和加深印象。随着思维导图分支的逐渐细化,我么的知识大树也日渐完善。很多时候对于新知识的快速入门,一张丰富的带注释的思维导图其实就足够了。

个人知识的收集很大一部分直接从微信存入我的印象笔记,其他来学习计划临时添加的知识点,各类连带知识,以及多个不同层次总结的内容。这些东西又是会临时记录在系统的备忘录提醒事项,有的结构化的保存在bear中,有的经过多次不成熟的中间终结存在Quiver中,很多使用MindNode没有画完的思维导图。这些东西随着硬盘的损坏都没有了,这些都是宝贵的无法评估的内容,更是无法回忆起的内容。也许在将来某一天在遇到某个难题的时候会突然想起,我似乎在什么时候记在TODO列表中等待整理,其中包括非常珍贵的原始资料,但是都回不来了。

五、个人网站

![Hexo](resources/2018/mac-data-loss-hexo.png) Markdown与Hexo

个人网站是自己多少年积累的内容,虽然在经过几次网站迁移的时候做了备份,但是那也是几年前的事情了。这之后的文章原文随着这次数据丢失也没有了,更加关键的这其中有好几篇影视评论和技术文章的草稿。原文可以根据在线信息反转回来,但是草稿的丢失真的是给我非常沉重的打击。

影视评论是参考了很多网络上主流的观点结合自己的切身体会慢慢的写出来的,再加上图片资源选择,这都是无法重现的。并且纯文字是非常消耗时间的,有时候进入不了状态心里的想法怎么都无法形成文字,无论多少时间都没用。

技术文章的最大问题是要进行至少自己就能想到的充分论证,需要查询大量资料最后写代码看结果是否正确等等。这里更多的是充分的逻辑思考以及枯燥的代码验证。

Html to Markdown

如果想继续写博客的话就需要将线上文章还原成Markdown,进而在下次文章发布的时候重新进行渲染。

这里需要介绍两个非常好友的Node工具CheerioTurndown

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
function processFile(dir, fileName){
var filePath = path.join(dir, fileName)
var source = fs.readFileSync(filePath, 'utf8').toString()
var $ = cheerio.load(source, { decodeEntities: false })
var title = $("h1[class=article-title]").text().trim();
var time = $("time").text();
var tagsList = $("a[class=article-category-link]")
var categories = [];
$(tagsList).each(function(){
categories.push($(this).text())
})

var body = $("div[class=article-entry]").html()

if(body == "" || body == null){
return
}

var content = "title: " + title + "\ndate: " + time + "\ncategories"

categories.forEach((value) => {
content += "\n- " + value
});

content += "\n\n---\n\n"

var markdown = toMarkdown(body)
content += markdown.replace('<a id="more"></a>', '<!-- more -->')

fs.open(path.join(distDir, fileName.replace(".html", ".md")), "w",function(err, fd){
var buf = new Buffer(content)
fs.write(fd, buf, 0, buf.length, 0, function(err, written, buffer){})
})
}

这里做的就是尽可能的调整Cheeriocss选择器,以及Turndown对Markdown的尽量还原。虽然无法做到完全的恢复,最后还需要手动进行格式调整,但是这节省下来的时间也是巨大的。想当初第一次从wordpress迁移到hexo时那辛酸的转Markdown经历依然历历在目…

其实以上代码并没有通用性,因为Hexo页面渲染是由主题控制的。不同的主题渲染出来的样式可能完全不同,html标签结构也可能完全不同,css选择器自然也不同。真是辛苦…

六、微信小程序:

我之前刚写完《微信小程序从入门到重新入门》就遇到硬盘挂掉,直接导致我小程序源码包括客户端和服务端源码没了。不过实际上只要有API接口和数据返回格式,那么还原出客户端源码和服务端源码也并不是什么困难的事情。

这里推荐使用wxappUnpacker将微信打包后的wxapk文件还原成源码。这里贴一下简单用法。

  • node wuConfig.js <files...> 将 app-config.json 中的内容拆分到各个文件对应的 .json 和 app.json , 并通过搜索 app-config.json 所在文件夹下的所有文件尝试将 iconData 还原为 iconPath 。
  • node wuJs.js <files...> 将 app-service.js (或小游戏中的 game.js ) 拆分成一系列原先独立的 javascript 文件,并使用 Uglify-ES 美化,从而尽可能还原编译前的情况。
  • node wuWxml.js [-m] <files...> 将编译/混合到 page-frame.html ( 或 app-wxss.js ) 中的 wxml 和 wxs 文件还原为独立的、未编译的文件。如果加上-m指令,就会阻止block块自动省略,可能帮助解决一些相关过程的 bug 。
  • node wuWxss.js <dirs...> 通过获取文件夹下的 page-frame.html ( 或 app-wxss.js ) 和其他 html 文件的内容,还原出编译前 wxss 文件的内容。
    node wuWxapkg.js [-d] <files…> 将 wxapkg 文件解包,并将包中上述命令中所提的被编译/混合的文件自动地恢复原状。如果加上-d指令,就会保留编译/混合后所生成的新文件,否则会自动删去这些文件。同时,前面命令中的指令也可直接加在这一命令上。

微信小程序打包后的文件可在已root的android手机或者模拟器里获得,地址为/data/data/com.tencent.mm/MicroMsg/{User}/appbrand/pkg。值得注意的是文件夹里可能有两个文件,其中一个几M的文件是小程序的库文件,如果无法恢复源码请换一个文件再试。

小程序代码托管

![TGIT](resources/2018/mac-data-loss-tgit.png) TGIT

在我重新写完小程序前端后端代码后发现微信小程序开发者工具上多了个代码托管功能,于是为了不重蹈覆辙我赶紧把整个项目传到这个TGIT上去。这其实就是一个使用git的代码托管平台,并且只是原生的git客户端。

然后好景不长某天突然爆出腾讯云存储损坏导致某创业公司数据全部丢失的事情… 然后我向TGIT推送代码更新的时候提示我源码库不存在… 那段时间听不少运维的朋友说腾讯云多次发通知说广州网络故障,说是光纤被挖断…

在接下来一段时间号称远不宕机的AWS由于操作错误宕机了,紧接着Google Cloud由于迷之BUG也出现全球故障。几天前微软Azure也因为雷击导致全球云服务宕机…

看了那么多也体会了那么多,我唯一的选择只有将小程序源码托管在开源中国的gitee/码云上。

七、可恢复数据

![Account](resources/2018/mac-data-loss-google-account.png) Google Account

这次数据丢失引起的问题也基本告一段落,当然除了网站的文章操作。从这次事件中我深切的体会到数据备份和系统备份的重要性,也真实的体会到iCloud和谷歌账号这种有庞大用户体系的云服务带来的便利性。你能想象一个全新的系统在安装了Chrome后登录。然后地址栏给你提示你常用的网站地址,每个被标记记住密码的网站都仿佛你才没离开多久的样子,这种感觉真的太好了。

当然还有像印象笔记这类自带云服务的工具,很多时候真的是帮了大忙了。

八、系统备份

在等待Mac维修的时间里我在想,如果我之前运行了Mac自带的时间机器进行过备份那该有多好。

但是现实并不是这样,首先水果的东西集成了不管好不好用首先很贵的传统。与Time Machine相对的Time Capsule性价比非常低,第三方我首先想到了小米路由器。在开启了小米路由器的时间机器在Mac上进行备份,但是无论多少次都我发备份,而查了资料发现小米路由器即便可以备份也不支持恢复…

所以唯一的选择就是… 移动硬盘。

九、最后

水果家设备的备份其实是一项比较深的学问,如果不差钱那直接上Time Capsule也没什么好说的。但是Time Capsule怎么看都是性价比极低,说不好听的就是个路由器加个硬盘而已。所以要么直接买一个与Time Machine兼容比较好的移动硬盘,否则就只能上NAS类工具了。