接收到的数据进行存储、分析等处理，并将处理结果反馈给终端设备。
[0038]需要说明的是，本申请实施例所提供的基于增量信息系统的终端信息备份方法可以由终端设备101、102执行，用于基于增量信息系统的终端信息备份装置也可以设置于终端设备101、102中。在一些实施例中，如果网络103通畅，镜像信息可以上传至云端，如果网络103不通畅，镜像信息可以存储在终端设备101、102中，当检测到网络传输通畅时，将存储在终端设备101、102中的镜像信息上传至云服务器104。
[0039]应该理解，图1中的终端设备101、102，网络103和云服务器104的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
[0040]以下结合图2a和图2b描述基于增量信息系统的终端信息备份方法。
[0041]图2a示出了根据本申请实施例的基于增量信息系统的终端信息备份方法的示例性流程图200。
[0042]如图2a所示，基于增量信息系统的终端信息备份方法200可以包括以下备份步骤:
[0043]步骤201，存储本地信息中的原始镜像信息。
[0044]在这里，本地信息是指终端中的操作系统、应用以及其它文件等。
[0045]本地信息中的原始镜像信息是指终端中信息版本管理中只读的原始镜像信息，例如安卓(Android)或泰泽(Tizen)的某个发行版，作为本地的基本元系统，后期的修改都会保存在这个基本元系统以上。
[0046]步骤202，使用标签标记预设周期内的本地信息中的增量信息。
[0047]其中，预设周期可以由用户根据自身需要来设置，也可以由终端的提供商根据大数据中增量信息的相关数据进行设置。本地信息中的增量信息是指终端中基于只读的原始镜像所增加的修改信息。例如，在这里我们可以设定5分-10分钟自动做一个增量信息的镜像，做完后这个增量信息的镜像也设定为只读，继续往上累加用户操作造成的变更信息。
[0048]在这里，用于标记增量信息的标签可以指示增量信息的增长版本，例如第一个预设周期内的增量信息可以标记为V1.0，第二个预设周期内的增量信息可以标记为V2.0，第三个预设周期内的增量信息可以标记为V3.0等。
[0049]步骤203，生成增量信息的镜像信息。
[0050]在这里，生成预设周期内使用标签标记的增量信息的一个完全相同的副本。
[0051]步骤204，将镜像信息上传至云端。
[0052]通过将镜像信息上传至云端，可以实现镜像信息在云端服务器的备份，例如将镜像信息上传至用户在云端的账户对应的存储位置。其中，在云端存储的增量信息，可以按照元数据的方式存储，以进一步提高备份效率。
[0053]进一步地，为了保证对于本地信息的增量信息的备份，可以在终端上设置本地存储位置，以便在将镜像信息上传至云端时，若网络传输不通畅，无法直接将镜像信息上传至云端时，可以将镜像信息先存储至上述的本地存储位置，之后待网络传输通畅时，再将存储的镜像信息上传至云端。同时，为了减少增量信息占用终端的存储空间，仅在无网络时将镜像信息存储至上述的本地存储位置，需要对网络传输进行监测，以根据网络传输的状态采取不同的传输方式。上述的在本地设置存储位置进行备份，也可以由用户根据实际需要进行设置。
[0054]请参考图2b，图2b示出了应用本申请的基于增量信息系统的终端信息备份方法的一种文件系统的示意图。
[0055]如图2b所示，图2b中示例性的示出了可堆叠联合文件系统AUFS (AnotherUn1nFS)的结构图。
[0056]在这里，可堆叠联合文件系统将多个目录整合成单一的目录，简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。可堆叠联合文件系统只是Iinux内核的一个补丁集，并没有被合并到Iinux内核中。可堆叠联合文件系统支持为每一个成员目录设定“只读”，“读写”和“可写”权限，可堆叠联合文件系统里有一个类似分层的概念，对只读权限的分支可以在逻辑上进行修改(增量地，不影响只读部分的)，允许将一个只读的分支和一个可写的分支联合在一起，可以直接引导为可用Linux系统的⑶正是基于此可以允许在操作系统镜像不变的基础上允许用户在其上进行一些写操作。
[0057]可以通过以下步骤将可堆叠联合文件系统编译进Linux内核:首先，下载可堆叠联合文件系统源码；其次，选择对应的内核版本；然后，打上可堆叠联合文件系统补丁 ；之后，拷贝部分头文件到内核源码树下；最后，重新编译内核。通过以上步骤的操作，可堆叠联合文件系统就会编入新的内核中，而不是作为模块加载。新内核自动支持可堆叠联合文件系统功能。
[0058]示例性的，如图2b所示，在本申请的一个具体的实施例中，底层的引导文件系统(bootfs)的上层是泰泽操作系统(Tizen OS)，本申请实施例中存储的原始镜像(baseimage)也位于这一层，在原始镜像的基础上，客户对文件系统进行修改的增量信息按照时间段可以分别存储为修改1、修改2及修改N，对于每一版修改版本，当生成该修改版本的镜像信息时，该镜像信息也将被设定为只读。
[0059]与一个具体的终端文件系统相对应，原始镜像可以位于终端的可信任层中，其中，可信任层包括HW信任区、引导加载器、Linux内核和安卓操作系统，具体地，用于生成原始镜像的泰泽操作系统可以代替安卓操作系统的位置，而引导文件系统可以以引导加载器的方式实现。
[0060]本领域技术人员应当理解，除可堆叠联合文件系统支持这种实现方式，从逻辑设备到物理设备的映射框架机制(Device Mapper)、B_tree文件系统(Btrfs)、动态文件系统(Dynamic File System，缩写为ZFS)等增量文件系统也都支持这种实现方式，在此不再赘述。
[0061]以下结合图3a和图3b描述基于增量信息系统的终端信息备份方法中的一种修复方法。
[0062]图3a示出了根据本申请实施例的基于增量信息系统的终端信息备份方法中的一种修复方法的示意性流程图300。
[0063]该基于增量信息系统的终端信息备份方法的一种修复方法300，在步骤201至步骤204的基础上，还可以包括以下步骤:
[0064]步骤301，检测本地信息是否仅包括原始镜像信息。
[0065]在对本地信息进行检测时，可以通过对于标签的检测确定本地信息所包括的信息是否仅包括原始镜像信息。
[0066]步骤302，响应于检测到本地信息仅包括原始镜像信息，从云端下载镜像信息。
[0067]在对本地信息进行检测之后，如检测的结果为本地信息仅包括原始镜像信息，则可以从云端下载镜像信息。
[0068]在从云端下载镜像信息时，可以根据用户账户(例如手机账户或邮箱账户等)确定用户所上传的镜像信息。
[0069]步骤303，合并本地信息与下载的镜像信息。
[0070]在将云端的镜像信息下载到本地之后，可以将本地信息与下载的镜像信息合并，以修复文件系统。
[0071]在文件系统损坏进行刷机或更换新终端时，可以使用本申请实施例中的该修复方法，轻松修复刷机或更换新终端之前的文件系统。
[0072]进一步参考图3b，图3b示出了用户在更换新终端时应用该修复方法的应用场景的示例图。
[0073]在图3b中，用户使用原终端时，应用本申请实施例的基于增量信息系统的终端信息备份方法，将本地信息的镜像信息上传至云端对应用户账号的存储位置，当用户更换终端时，用户可以在新终端中安装原始镜像信息，再根据用户账号从云端下载镜像信息，之后在新终端中对原始镜像信息和下载的镜像信息进行合并，从而实现用户在使用新终端的文件系统时，感受与原终端的文件系统基本一致，满足了用户对终端中文件系统的个性化需求。
[0074]以下结合图4描述基于增量信息系统的终端信息备份方法中的另一种修复方法。
[0075]图4