1.1. 档案系统是一种你们或许要用到，但目前很可能还不具备的数据保护系统

1.2. 档案定义成一种单独存放于其他位置的数据副本，它是供参考用的，其中有足够的元数据（metadata，即工作数据），让用户能够通过这些元数据搜索到想要查询的内容，而无须知道这些内容以前来自何处

1.3. 备份则是一种辅助的数据副本，用来在主要的数据“正”本遭遇破坏、删除或其他某种事故时恢复数据

1.4. 大多数组织为了体现其职能所做的那些事情，都无法明确归入某个类别

1.4.1. 给该组织的某项职能提供支持的那些应用程序与工作任务，也不太能够明确地归入某个类别

1.5. 归档方案与其他方案是一样的，也就是说，你必须先搞清楚这个归档方案所要满足的需求，然后才能开始设计

1.6. 无论打算部署什么样的档案系统，该系统内所保存的数据都跟备份系统例行保存的那些备份数据有很大区别

1.6.1. 前者则是一种相当重要的历史信息，需要加以留存与保护

1.6.2. 后者用来在生产系统发生故障时将其恢复到它在某个时间点上的样子

1.7. 档案系统是极其重要的，只不过可能稍微有点枯燥

1.7.1. 其实是针对那种大家都想扔掉的数据而构建的一套体系，假如没有这套系统，那么那些数据可能真的就会删掉

2.1. 具有次要价值的数据正本

2.1.1. 不是你们的主数据

2.2. 档案数据一般没有主数据那么新，受访问的频率也没有主数据那么高，有时根本就不（像主数据那样）为创建该档案的用户所重视

2.3. 并非每份数据都需要放在显著的位置并展示给所有人看

2.4. 有些数据价值比较低，我们通常会把这样的数据制作成档案（也就是将其归档），让它们不要再占用主存储系统里的空间，这些数据通常用来提醒我们以前发生过的某个事情，而不用来做日常的参照

2.5. 原因

2.5.1. 为了满足政府机构所提出的各种法律法规方面的要求

2.5.1.1. 会计公司就需要把客户的数据记录维护一定的年限，以便在遇到审计时把这些数据当作证据出示

2.5.1.2. 政府机关与财务机构通常需要把它们与公众之间的交流记录保存许多年，以便在遇到问题或争议时参照

2.6. 问题

2.6.1. 有些数据是用旧技术制作的，那些技术会逐渐退出，于是就出现了如何保存此类数据的问题

2.6.2. 长期保留数据也会遇到一些相当突出的问题，然而除此之外，还有数据量的问题，为了应对将来有可能与客户产生的争执，你需要保存的数据量可能相当庞大

2.6.2.1. 档案库以后会越来越大，到时就连例行的每日保护都会有很大困难

2.6.2.2. 许多方案都会通过把多个副本存放到多个地点来保护档案数据

2.7. 对历史数据归档，并将其转移到廉价一些的存储环境里

2.7.1. 把档案数据保存到廉价的存储系统，并不意味着这些数据会更容易丢失

2.7.2. 需要牺牲的通常是速度，档案系统获取数据的速度通常比较慢

2.8. 档案可以用来获取信息，但它们确实很不适合用来恢复数据

2.9. 很难（或者说，基本不太可能）直接从备份里获取信息，同理，你也不太可能直接用档案做数据恢复

3.1. 档案与备份之间的区别可以简单地理解成获取与恢复之间的区别

3.1.1. 档案是用来从中获取信息的

3.1.2. 备份则是用来从中恢复数据的

3.2. 从档案系统中获取数据，跟从备份系统里恢复数据看起来区别很大

3.2.1. 用户可能是在数据已经创建了许多年之后才想要获取数据的

3.2.1.1. 用户已经记不清这份数据当初存放在哪个目录或哪个服务器里面

3.2.2. 要求搜索数据的人可能不是当初创建这份数据的人

3.2.2.1. 可能是为了应对电子取证请求而做的搜索

3.3. 恢复通常针对的是某系统在某个时间点上的某份文件

3.4. 获取与恢复不同，它通常并不要求你准确提供上述任何一项具体信息

3.4.1. 服务器的名称

3.4.2. 文件所在的目录位置

3.4.3. 文件本身的名称

3.4.4. 具体的日期

4.1. 并非所有的需求都能够很好地用任何一种档案系统来满足

4.2. 挑选档案系统时也很少会单从产品的技术能力来判断

4.3. 档案需求之外的一些因素也会影响你的选择过程

4.3.1. 可用的资金量、性能方面的考虑、支持某种方案所需的资源量，以及其他一些非技术的因素等

4.4. 数据所在的服务器可能不会包括在元数据里，这也是档案与备份之间的另一项重要区别

4.5. 传统的批次档案系统

4.5.1. 批次归档系统

4.5.2. 会在数据使用一段时间之后将其归档到安全的地点，让我们能够在需要满足合规需求或需要查询历史记录时参考

4.5.3. 数据归档之后，会从原来的位置删掉

4.5.4. 主要目标在于以成本较低的方式长期保存数据，让你能够在多年之后轻松地查找这些数据

4.5.5. 传统的批次归档系统在把数据归入档案时会给这批数据赋予一项或多项标识信息，并将这些信息放在元数据里随档案一起保存

4.5.5.1. 元数据以后可以帮助你获取到这份数据

4.6. 实时档案系统

4.6.1. 会把正式存储环境里创建或保存的数据复制到另一个地方，以便作为档案使用

4.6.2. 这种档案通常是为了满足合规或审计方面的需求

4.6.2.1. 可以让该组织更好地满足合规需求

4.6.3. 日志邮箱（journal mailbox，又名日记邮箱）

4.6.3.1. 同时把原始的邮件发送给本来应该接收这封邮件的人

4.6.3.2. 各种审计与管理人员都可以访问这个日志邮箱，并搜索那些需要在诉讼案件中使用的信息，或是根据资讯公开请求而必须公布的信息等

4.6.4. 通常不通过传统的电子邮件客户端访问，而是通过一种入口（或者叫作门户）来访问，使用者可以在这里指定搜索范围

4.6.5. 不能缓解正式的存储系统所承受的压力

4.7. HSM档案系统

4.7.1. 采用HSM（Hierarchical Storage Management，分级存储管理）机制来决定数据的存储地点

4.7.2. 如果数据变得陈旧，或者访问频率变得比较低，那么就应该将其移动到更为廉价的存储设备里，以节省成本

4.7.3. 云端的“冷”存储(cold storage system)

4.7.4. 让你可以将这些磁带转移到远离主站且与主站不联网的地方

4.7.4.1. 让这些数据只在确实有必要访问时才能拿出来查询，而不能随便触碰

4.7.4.2. 从保存每GB数据所耗费的成本来看，磁带也比其他一些存储系统更为廉价

4.7.5. 通常会根据数据的陈旧程度或最后一次受到访问的时间，来判断是否应该将其移动到其他存储设备里

4.7.5.1. 如果某份数据在目前的文件系统里已经待得比较久了，那么就可以将其移动到档案系统中

4.8. 只要某方案能让数据在这种高性能的正式存储设备上少占一些空间，这种方案就是值得考虑的

5.1. 是否需要档案系统

5.1.1. 些可能是在组织内部创建的，有些则是从本组织之外导入的

5.1.2. network volume，泛称网盘

5.1.3. 数据可能是相当重要的，但很少需要由人来查看，因此非常适合归入档案

5.1.4. 云服务提供商每次总是要保存好几个月的日志与监控数据，这些数据很庞大

5.1.4.1. 在与用户发生费用争议，或者调查某次意外停机事件的根源时，肯定得参考这样的数据

5.1.5. 法律要求服务提供商必须保留客户的访问日志，以便在政府机构想要查看这些数据时提供给对方

5.1.6. 把钱花到档案系统上是值得的

5.1.7. 某个组织知道它里面的一部分数据必须符合特定的法律法规，因此需要加以保护并予以保留，但是该组织完全没有意识到，这些数据实际上分布在各个用户的home目录里，或者随便放在了某个早就没人管的文件共享服务器中，并且藏在层次很深的文件夹里面

5.2. 收集需求

5.2.1. 如果你们准备部署档案系统，那么在开始部署之前，一定要先把需求收集清楚

5.2.2. 你需要考虑数据应该保存多长时间，还要考虑与此有关的各种问题

5.2.3. 数据格式问题

5.2.3.1. 一定要考虑到数据是如何存放的，以及将来在需要查询数据时应该如何获取

5.2.3.2. 如果这些数据都是纯文本的日志文件，那么将来需要用到它们时，很可能会将其交给某种系统去读取

5.2.3.3. 数据让软件保存成了某款应用程序专用的格式

5.2.3.4. 如果你的数据是拿这些软件创造的，那么如何保证在今后50年中依然能够访问到呢？

5.2.4. 存储介质

5.2.4.1. 把档案数据存放在什么样的介质上，也是一个很重要的问题

5.2.4.2. 肯定不想把历史数据的副本，保存在那种比数据本身还会提前遭到淘汰的存储系统里

5.2.4.3. 拿不准某个存储系统能不能把数据存放50年，那一定要选一款能让数据多保存一些时间，并且确保数据不会变更的档案系统

5.2.5. 是否一定要使用便于迁移数据的档案系统

5.2.5.1. 某些以往由基于硬件的档案平台所提供的功能（例如加密、确保数据不可变），现在必须内置到软件里面，而且必须定期维护

5.2.5.2. 理想的情况应该是：有这样一种软件形式的归档方案，它能够保护数据并方便地迁移这些数据，同时又能让用户（在硬件平台支持的前提下）开启相关选项，以利用硬件平台的某些功能（例如加密与数据去重）

5.3. 需要考虑的其他问题

5.3.1. 数据将来是需要由人来阅读，还是只需要让以后的应用程序能够读取就行？

5.3.2. 地图数据，将来只需要发送给某个地理信息系统，让它把这些数据与以后的数据进行对比，或者让它分析两者之间的差异，那么你只要能够将这些原始数据从当前系统里导出为某种自由的格式就行，将来应该会有软件能够读取这种格式

5.4. 档案系统与备份系统是应该分开，还是应该整合？

5.4.1. 数据所占据的空间越来越大

5.4.2. 法律法规方面的要求

5.4.3. 某个组织可能不会仅因为这些因素而决定对数据归档，但它们在决策过程中确实都是相当值得考虑的大问题

5.4.4. 良好的数据保护与存留系统，当然应该确保档案数据能够安全地得以存储，但这并不意味着你一定要从备份系统里操控档案系统

5.4.5. 备份数据与档案数据的职能在许多方面都不一样，因此我们有理由考虑将这两种系统分开，并指派不同的团队来分别维护

5.4.5.1. 备份团队肯定要参与跟如何存储生产数据（也就是在正式工作环境中使用的数据）有关的一些事务

5.4.5.2. 负责管理档案系统的那个团队，则有可能只需要记录一些信息并处理与合规有关的问题，这些工作甚至可以与该组织的技术工作完全分开

5.4.6. 该系统在给数据归档时能不能把元数据（也就是与数据本身有关的一些工作数据）也准确地纳入档案，对于那些为了合规而制作的档案来说，这一点尤其重要

5.4.6.1. 给数据归档时，要注意把这些元数据也维护起来，让它们跟数据本身一起进入档案

5.4.6.2. 元数据通常用来帮我们了解与数据本身有关的一些情况

5.4.6.2.1. 存储在照片文件里的元数据就可以提供一些信息，让我们知道这张照片是在哪里拍摄的，是用什么型号的相机拍摄的，等等

5.4.6.3. 档案系统可能还必须确保数据不可变，也就是说，数据一旦存入档案平台，就无法修改

5.4.6.3.1. 数据要呈交给法院，法院需要确认该数据未遭篡改，从而可以当作证据使用

5.4.6.3.2. 如果档案系统能够确保数据不可变更，那么就可以提供一定程度的安全保障，从而避开某些有可能令数据受损的情况

5.4.7. 如果有待归档的数据由某款应用程序保存成了一种供用户查看的格式，那么档案系统一定要提供一个具备查看功能的应用程序前端，让用户在档案系统里也能查看该数据

5.4.8. 你想要部署的档案系统是什么类型，可能会影响到该系统是应该与数据保护系统及正式的存储环境相集成，还是应该与之分离

5.5. 把所有数据都保存在同一个地方，通常是很不明智的

5.5.1. 3-2-1原则所要强调的意思，该原则不仅适用于备份，也适用于档案