关于海量小文件（亿级）备份软件的实现和开发步骤

我们有个用户是档案行业的，服务器中存储了大约千万级的档案图片（电子档案扫描件），之前做一次备份工作是很费劲的。档案行业一般都是半公益单位，属于清水衙门也没什么钱。对于动辄十几二十万的各种备份系统而言，小单位确实买不起。

这篇文章就是站在专业角度为你剖析备份系统的实现原理，和重要的技术理论，你不花钱一样可以实现专业级别的备份服务：

由于windows的文件管理机制，你备份文件无非就是三个操作：1、查看文件夹属性 2、复制文件 3、粘贴文件

无论你是否查看文件属性，windows复制文件之前，系统都会默认扫描一遍准备复制的源文件路径，这时候如果你是海量文件的话，这一步系统就会出现假死现象。据观察用户目前的情况仅仅点击一次复制、粘贴，系统光准备时间都要个把小时，然后才会慢慢悠悠的走进度。

这时候又有一个问题出现，由于都是2-3M的小文件，Windows每粘贴完成一个文件后，都要进行一些后台操作（对文件属性的更新或遍历更新源文件队列的任务，等等），总之每个文件复制完都会有一个小卡顿。这种卡顿貌似没啥问题，但是如果千万级文件复制这个卡顿就会严重影响效率。

基于以上原因：靠Windows系统自带的复制粘贴文件实现海量文件的备份，基本就是个死胡同。100Tb的文件备份一遍，大约的个把月时间。还不能中断，万一断了就重来，因为你不知道从哪儿断的，更不知道哪些文件复制了或者没复制。

一般而言只要能发现问题就有对应的解决办法：

1、复制粘贴文件时不让windows在遍历文件夹列表：

这个问题显而易见，“遍历”这个动作会严重影响系统性能，是导致卡死的重要原因。按照正常逻辑——

A、Windows复制文件后，会把需要复制的文件列表记录在某个地方（或许是内存中、或许是某个临时文件里）

B、粘贴完成一个文件就从上述“某个地方”抹去一条记录。

所以这个机制非常消耗性能，如果每次复制几千个或者上万个文件，以目前的计算机算力而言，一般不会有什么压力。于是我们就跟着这个思路开发软件——

软件先代操作系统做一次遍历动作：把准备复制的源路径的所有文件（文件夹结构）写入数据库，每条文件一行记录。这个操作虽然耗时，但安全稳定，一次把所有文件夹结构读入后即可开始后面的操作。

正如上面所说：文件虽然海量，但文件夹数量必定小于文件数，据我们观察用户有千万级的文件，但各级分类的文件夹也就不到1万个。所以我们开发的这个备份软件，第一个环节就是读取这1万个文件夹的结构，记录进数据库。

接下来工作就比较清晰了：

1、读取数据库的路径记录，让程序开始逐条复制。之所以逐条复制就是为了限制资源使用情况，让系统工作的更加从容，如果一次开启多个线程复制，那就又会卡顿。

2、每复制完一条记录，程序回调一次结果，在程序界面上走个进度。同时在数据库给这条记录打个标记。后期即便不小心软件断掉了，也可以从打标记的位置开始走进度，而不需要从头复制粘贴（在Windows里没有断点功能）。

开发思想：

程序能“从容”工作很重要，之前windows的复制机制之所以效率很低，原因上面已经说过。加上内存中如果稍微有点错误，导致复制任务中断就要重新开始。我们开发这个备份软件的中心思想就是让程序“从容”的工作，占用最小的系统资源，免去它遍历和更新文件属性的环节，让它以最优的状态“慢慢”工作，事实证明这种效率是最高的。

我观察了市面上不少备份工具，它们都把重心放到了如何提高复制效率、如何榨干系统资源上，这个思路对于民用场景还勉强，对于海量文件的专业领域就不灵了。还是那句话：1亿文件忽然给它塞进去，它这个软件非死即残。

数据库我采用的是Access，因为免部署。sqlite虽然也是文件型数据库，但还要安装runtime所以放弃。其实最重要的原因是数据表结构简单，就一张表里面两个字段：一个路径字段、一个状态字段（默认0，完成1），所以access完全满足要求，查了一下资料，这种简单的表结构1亿条记录还是可以完美驾驭的。当然了sqlite官方宣称能到14Tb那就更海量了，但是我目前用不到，就以轻便为第一要务吧。

实际生产环节测试：

经过了15个小时左右的持续工作，大约完成了80万个文件的备份，网卡占用率持续平稳在30%左右，总体设计复合预期（即“从容”的进行任务），既不会占用太多系统资源，也充分保障了任务效率。尤其值得一提的是：双网卡一路进行备份一路进行对外服务，这种搭配最为合理。

这是我以上述思路为某档案中心做的一个小备份工具，经测试很稳定，丝毫不亚于几十万元的专业灾备系统的效率。