在Gitlab和Instapaper连续遭到灾难性数据损失之后，作为一个有硬盘的人，如果还不未雨绸缪，显然大有“平时袖手谈心性，临危一死报君王”的东林风范。可惜有事发生时，东林君子们还可以改换门庭，硬盘里的货可就跟我永别了。

数据类型

首先分析一下硬盘里的数据类型，不同类型的数据，需要的处理方式也不同：

照片

我还没见过全家根本没人照相的家庭，虽然卡片相机已经基本被淘汰，然而即便没个单反，也有微单，最起码手机里还有大量照片。基本不会重名，也没有版本控制问题，直接全部拷贝到备份目录即可。

视频

视频分两种：A.电影电视综艺动画等从网上下载的；B.自己拍摄的。

A类就算是珍贵的4k高清也好，我的意见是完全不用备份，第一重复观看可能性低（好吧比如《勇闯夺命岛》这种我看上一百遍也不会腻的片子就留着好了）

其次随着科技的发展，我硬盘里《勇闯夺命岛》的版本，经历了vcd->dvd->720p->1080p->蓝光5.1声道等诸版本。当然只要片子的母带不是太古老，2k/4k/8k分辨率的高清版迟早会出现，而网络带宽现在也已经到了100M，已经足够应付4K视频的码率：

Netflix是15Mbps码率H265编码。
Youtube是18Mbps码率VP9编码。
Comcast试播的服务是18M~22M码率H265。
预计国内网站会使用5Mbps的H265来播放4k内容
--From知乎

对于A类视频，网上直接看片好了。

B类没什么好说的，和照片一样备份。只有一点需要提一下：很多视频采集设备出于节省成本，使用了低压缩比的编码格式，导致了视频体积非常臃肿（给视频编码时没有使用需要专门dsp芯片或者高性能cpu）。举个例子，分别使用松下GM1默认avc/H264/HEVC这三种编码，生成的质量相近的视频文件，大小比是4/2/1。

作为存了一大把视频的拍娃党，备份前用5M码率的HEVC压缩一下，硬盘能减负不少。

应用程序和设置

应用程序本身是没有备份价值的，如果系统挂了，重新安装即可。但是设置就不一样了，比如我windows上的必需品终端软件SecurtCRT，几十个host和对应设置都存在系统的文档目录，如果重新安装，需要全部重设，一天时间就过去了。

使用ssd做系统盘的各位我建议直接使用操作系统的备份工具做个系统盘镜像，不到200G的内容毫无压力。万一系统挂了，随时直接恢复。

文档

最重要的可能就是文档，当然这块的解决方案也最多。如果不牵涉机密的文档，使用网盘如Dropbox等等就完全解决了，如果只用windows的化，系统自带的OneDrive也很好使。

至于机密文档——谁让你把机密文档拷回家的？还不赶紧删了！

游戏

正版用户只用steam和origin，所有游戏存档和虚拟资产都存在服务器上，除非游戏公司的服务出问题，存储不用操心。就算服务出问题，还会有补偿呢！

代码

上面说的那些数据，基本家家都有，代码不是。但专业程序员的代码恰恰是最不需要担心备份的——在普遍使用git管理代码的今天，就算哪天硬盘挂了，还可以轻松从服务器上或者同事的电脑里恢复回来，分布式版本控制工具不是说着玩的——前提是代码要及时提交......

一句话总结：分布式版本控制——文件系统的未来。

反向验证

Gitlab出事的重要原因是备份毫无用处，无法恢复之前的文件。原因很多，比如备份选项：无条件使用源覆盖目标，即便源已经被清空了，备份行为也会将备份清空。

Instapaper出事，是因为RDS在出事前很稳定，从来没演练过恢复数据这一操作。一出事，只好拉上亚马逊的工程师来解决问题，花了一个礼拜。

所以对于企业来说，反向的备份恢复验证也是必不可少的。办法也很多，比如一拍脑门，最糙快猛的方法就是找台没用的机器，定时从备份里取最新版，放在本地做恢复操作。写个脚本验证一下是否恢复正常：比如看看数据库的某个表是否存在、某个照片目录文件数是否大于1000等等，如果不正常，立即发邮件或者发短信报警。

耗散模型

数据作为低熵实体，符合自然规律的过程是耗散。比如我丢失的第一笔数据，是存在5寸1.2M软盘上花了一个礼拜制作的多媒体课件。软盘会随时因为温度、适度、压力、灰尘而宣告不治这一特性谁用过谁知道，所以当出现了更靠谱的光盘后，我不惜工本把所有数据都刻在了几十张光盘上。然而几年后发现，还是装在金属壳子里的硬盘最为靠谱......

“刻在石头上。”
——《三体》