1.1. 两个完全不同的操作
1.1.1. 要实现的是两个完全不同的目标
1.1.2. 备份(backup)
1.1.3. 档案(archive)
1.2. 有些产品既能制作备份，又能制作档案
1.3. 某些产品或服务明明是专门用来制作备份的，但有人却偏偏想顺便用它来制作档案
1.3.1. 明明是在做其中的一项操作，却偏偏把它叫成另一个名字，那就不太对了
1.4. 把制作备份的软件当成制作档案的软件来使用，不仅会增加成本，还会让组织面临更大的风险
1.5. 不要总以为把备份数据保存许多年是一个很了不起的设计思路，除非你能保证这个备份系统可以顺利地将多年以前的备份获取到，并且能够很好地从中恢复数据
1.6. 不要把那种带有档案制作功能的SaaS式产品误认为备份产品，因为那些产品制作出来的是档案，而不是真正的备份
1.7. 档案是为了便于你从中搜索并获取信息，而不是让你用它们来恢复数据的
1.8. 备份与档案是数据保护工作的最后防线
2. 什么是备份2.1. backup实际上就是该文件的一份copy（副本），这份copy一般就放在原文件的旁边
2.1.1. 只是一个copy，而不是真正的备份
2.1.2. 做法违背了3-2-1原则
2.2. virtual snapshot（虚拟快照）
2.2.1. 一种虚拟的copy，必须依赖原文件才能体现出它的意义
2.2.2. 不是真正的备份
2.2.3. convenience copy（便捷复制或方便复制），
2.2.4. 对文件系统或存储系统所做的virtual snapshot（虚拟快照）不是copy，因为它们并不包含原数据里的内容
2.2.4.1. 只是在许多地方引用了原数据而已
2.2.5. NAS的快照、XFS的快照、Windows的VSS（Volume Shadow Copy Service，卷影复制服务）快照，以及VMware或Hyper-V这样的虚拟机管理程序所做的快照，都属于virtual snapshot，它们本身并不能算作copy
2.3. 备份是对数据所做的一份copy，它与原数据分开存放，并且能够把这份数据恢复到早前的状态，之所以恢复，通常是因为原数据受某种原因影响而遭到删除或破坏
2.4. 备份必须是一份copy
2.4.1. copy是对原数据所做的逐字节重制，它的内容与原数据相同
2.4.2. 对文件所做的copy，还应该包含所有的metadata（元数据/后设数据），尤其是与安全及权限有关的配置数据
2.4.3. 必须依赖原数据而存在的“copy”，都不是真正的copy，它们只能算作虚拟的copy(virtual copy)
2.4.4. 通过把快照重制到另一个系统上而形成的copy，要比普通的copy更好
2.4.4.1. 这样的copy里面，每个磁盘中的数据都是从同一个时刻抓取的，就算重制这份copy所花的时间很长，也能保证这一点，而不像普通的copy，难以保证这些磁盘中的数据会不会在制作copy的过程中有所变化
2.4.5. 通过快照来制作备份是相当棒的
2.4.5.1. 依赖原数据而存在的快照，不是一份合格的copy，你必须把它重制（也就是复制）到其他地方，才能让它成为一份真正的copy
2.4.6. 在IT领域，有一些snapshot（快照）确实是copy
2.4.6.1. AWS Elastic Block
Store(EBS)的snapshot
2.4.6.2. image copy（镜像复制）
2.4.6.2.1. 它们是在逐字节地复制原数据，相当于对原数据做了一个镜像
2.5. 备份必须与原数据分开存放
2.5.1. 如果你把copy保存在了跟原数据相同的文件系统、计算机或数据库里面，那么你做的仅是便捷复制，而不是真正的备份
2.5.1.1. 起不到对原数据做备份的作用，它只是出现在原数据旁边，方便你随时取用而已
2.5.2. 做备份时一定要把数据保存在远离原数据的地方
2.6. 备份必须能够用来恢复数据
2.6.1. archive（档案）也是一种copy，而且也是跟原数据分开存放的，但archive并不能算作备份
2.6.1.1. archive不是用来恢复数据的，它们是用来获取数据的，这跟恢复数据不是一回事
2.6.2. 只有那种能够在原数据受损时用来恢复原数据的copy，才是备份
2.7. 什么是恢复restore
2.7.1. 一种通过备份让数据回到早前状态的操作
2.7.2. 获取(retrieve)操作针对的是档案
2.7.2.1. 从档案中执行获取操作，所得到的是某个比较大的时间段内的许多数据
2.7.3. 恢复通常是为了让服务器或文件系统的状态回到距离当前较近的某个点
2.7.4. 恢复数据时，我们通常总是会使用最近制作的那个备份
2.7.5. 最为重要的一点，在于你必须知道自己想把这个有问题的东西恢复到它在哪一时刻的样子
2.7.6. 找到你在数据受损之前的某个时刻所制作的备份，并通过该备份来恢复某一服务器、VM或应用程序里某一区域（例如某个数据库、某个文件系统、某个目录、某个bucket）中的一条或多条数据
2.8. 3-2-1原则
2.8.1. 至少对数据做3个版本的备份
2.8.1.1. 除原数据之外还有3个版本
2.8.1.2. 3是下限，而不是上限
2.8.2. 把备份放在2个不同的介质中
2.8.2.1. 不要把所有的备份都保存到同一介质中
2.8.2.2. 原数据与你给该数据所做的备份肯定不能保存到同一介质上
2.8.2.3. 必须把备份放在跟原数据不同的磁盘上，或者存放到与你要保护的这台计算机不同的另一台计算机上
2.8.2.4. 不要把备份存放在距离受保护的计算机很近的地方
2.8.3. 将其中1份放在远处
2.8.3.1. 让其中一份数据离场
2.8.3.2. on-site（在场/在线/上线）与off-side（离场/离线/下线）这样的二分法
2.8.3.3. 把其中一份副本放到距离受保护数据相当远的某个安全地点
2.8.3.4. 可以让备份远离原数据，以便在数据遭遇灾难时，拿这些备份磁带来恢复
2.8.3.5. 用来做灾难恢复的这份副本，一定要放在远离各种灾难的地方
2.8.3.6. 要把这些备份放在一个跟你要保护的应用程序不同的地方
2.8.3.7. 最好能在另一个区里单独创建一个账号，让这个账号专门用来保存备份数据，并把其他区里的那些账号所制作的备份全都汇给这个账号
3. 什么是档案3.1. 把备份从某种比较昂贵的介质移动到费用较低的介质上，以便长期保存，这不能称为archiving a backup（“给备份做档案”或“给备份归档”）
3.1.1. 只不过是把备份移动到了一种便于长期保存的介质上
3.2. 旧的备份不会自动变成档案
3.3. 如果要档案，那必须去制作档案
3.4. 档案是存放在另一个地方的数据副本，是一种用来做参考的副本，其中存储着必要的metadata，让我们不用指出来源，就能找到所需的数据
3.5. 档案也必须是一份完整的副本，无须依赖原数据即可独立存在
3.6. 为了不同的目标而保存档案与备份的，我们获取档案与备份的理由不同，档案与备份的保存方式及获取方式也不同
3.7. 档案是为了参考而制作的
3.7.1. 档案并不是用来把服务器或文件恢复到原来的模样
3.7.2. 通常是用来查找数据的，至于为什么要从档案里找数据，其原因可能跟当初创建数据的原因不同
3.7.3. 电子邮件档案(email archive)通常用来做电子取证（e-discovery，也称电子搜索）
3.7.3.1. 这种档案的保存方式也不便于你通过它来恢复整个电子邮件数据库
3.7.4. 针对电子邮件与其他数据制作档案，而不是在制作备份
3.7.5. 如果有一种机制能够对这些数据制作真正的备份，那么你对备份的查询方式，应该跟你对这些档案的查询方式不同
3.8. 档案里有附加的metadata
3.8.1. 附加的metadata本身就包含在了你所归档的东西里面
3.8.2. 档案并不要求你在查询时提供原服务器或原数据库的名字，否则它就不是真正的档案了
3.8.3. 在制作档案之后主动添加metadata
3.8.4. metadata是为了便于你从档案中获取数据而设的，并不是为了让你用这份档案来恢复数据
3.8.5. 为恢复数据而制作的东西叫作备份，其中无须包含这些metadata，因为它的主要目标是便于恢复，而不是便于查询
3.9. 获取跟恢复有很大区别
3.9.1. 获取数据（或者说，调取档案）时，系统会根据档案的内容以及该档案所附加的metadata，把彼此有关的一组信息汇聚起来，返回给用户
3.9.2. 获取数据的时候，你寻找的通常是信息，而并不是服务器或文件
3.9.3. 感兴趣的是文件里面的内容，而不是文件本身
4. 保护备份数据与档案数据4.1. 备份与档案都很重要
4.1.1. 无论你是创建备份、创建档案，还是既做备份又做档案，你都希望它能够保持原样，而不要遭到摧毁、破坏或篡改
4.2. 加密
4.2.1. 想要防止有人恶意访问你的备份数据，最好的措施就是加密
4.2.2. 加密并不能防止坏人删除或偷窃你的备份数据，但就算他们拿到了备份，也读不懂其中的内容
4.2.3. 防止有人通过窃取备份来敲诈
4.3. 设置屏障
4.3.1. “air gap”指的是位于受保护系统与保护它的那个系统之间的一道屏障
4.3.2. 屏障便能够防止这次灾难或攻击把你的数据保护机制破坏掉，让你可以通过该机制来恢复受损的系统
4.3.3. 最好的办法就是让受保护系统与保护它的系统，在地理位置上离得远一些，并且对它们之间的通信渠道施加控制
4.3.3.1. 两个系统之间的通信渠道，控制得越严格越好
4.3.4. 攻击不单影响主系统，而且会把备份系统也一并感染，导致我们没办法通过备份系统来恢复主系统
4.3.4.1. 如果备份数据放在装有Windows系统的备份服务器上，而且能够通过该系统中的某个目录直接得到访问，那么勒索病毒在感染主系统之后，就有可能经由这个目录破坏你的备份数据
4.3.5. 物理屏障
4.3.5.1. 以前我们用的都是物理屏障
4.3.5.2. 不仅能让主系统与备份数据之间相隔很远，而且能让我们施加多层防护，以记录这些磁带的交接情况，从而确保它们不会由不该接触磁带的人拿到
4.3.5.3. 在磁带没有受损的前提下，只有一种常见的场合需要使用离场磁带，那就是我们对DR（灾难恢复）计划执行全面测试的时候
4.3.5.4. 对保管方的保管服务做渗透测试(penetration test)
4.3.6. 虚拟屏障
4.3.6.1. 虚拟屏障(virtual
air gap)
4.3.6.2. 现在，我们备份数据时可能根本就不会使用磁带
4.3.6.2.1. 攻击面要比原来大得多，而且攻击者从一个系统跳到另一个系统的概率，也比原来高得多
4.3.6.3. 禁用或限制使用RDP（远程桌面协议）
4.3.6.3.1. RDP是通过勒索病毒发动攻击的人很喜欢使用的一种渠道
4.3.6.3.2. 应该禁用RDP，或对其加以限制，在备份系统上尤其要这样做
4.3.6.3.3. 日常工作中应该不会频繁地用到RDP，因此，在连接备份服务器的远程桌面时多一些步骤，并不会造成太大的不便
4.3.6.4. 使用不同的操作系统
4.3.6.4.1. 尽量给备份服务器安装一个跟主服务器不同的操作系统
4.3.6.5. 把存放备份数据的地方跟其他东西隔开
4.3.6.5.1. 不要让目标去重设备的磁盘成为备份服务器所使用的操作系统里的一个盘或一个挂载点，以免有人通过这个盘或这个挂载点随意访问设备中的备份数据
4.3.6.6. 使用对象存储系统
4.3.6.6.1. 如果备份系统能够把数据写入对象式的存储系统，而不是常规的文件系统，那就应该开启这项功能
4.3.6.6.2. 采用对象存储协议来保存备份数据，可以分散这些数据，以避开常见的网络攻击
4.3.6.6.3. 采用基于对象的存储系统来保存备份数据，也要比通过NFS或SMB更加安全
4.3.6.7. 使用不可变的存储机制
4.3.6.7.1. 不可变存储(immutable
storage)，也就是说，你可以规定，凡是写入该系统的数据，都会存留一定时间，在这段时间内，即便你本人也无法删除该数据
> 4.3.6.7.2. 备份系统要是能把数据写入这种存储系统，那就应该这样做> 4.3.6.7.3. 在对象存储系统里创建一个数据桶(bucket)，并把不可变功能打开
4.3.6.8. 使用磁带保存备份数据
4.3.6.8.1. 把数据放在磁带里面，并让它远离你的数据中心，要比其他屏蔽方式都更为稳妥
4.3.6.9. 使用（特制的）备份服务
4.3.6.9.1. 要找的备份服务，应该是那种让备份数据几乎无法通过网络访问到的备份服务
4.4. 不可变性
4.4.1. 必须确保备份与档案数据不会遭到无意或恶意的擦除与破坏
4.4.2. immutability，也叫不变性
4.4.3. 某物具有不可变性（或者说，某物不可变），指的就是任何人（包括有特权的人）或任何东西都无法修改该物
4.4.4. 保留期(retention period)当然可以修改，然而新的保留期针对的只是修改之后存入的数据，它不会影响修改之前所存入的备份与档案数据
4.4.5. 没有什么东西能做到绝对不可变
4.4.5.1. 写入任何一种存储介质的数据，都有可能遭到摧毁。单次写入多次读取（Write-Once-Read-Many,WORM；单写多读）式的磁带与光盘，仍然抵不住火烧
4.4.6. 必须施加多种管控措施以确保不可变性
4.4.6.1. 以前似乎只有一种不可变的存储介质，就是光盘，但现在基本上没人用了
4.4.6.2. 云端存储解决了很多与如何防止有人亲身接触存储系统相关的问题，同时它又支持传统的存储方式所具备的各种特性
4.4.7. 不可变并不意味着不会遭到破坏
4.4.7.1. 不可变的系统让我们能够确信某个对象从来都没有发生变化
4.4.7.2. 系统依然无法防止有人亲身接触该系统，而且也无法避开其他损害
4.4.7.2.1. 磁带可能让火烧掉，即便这是一盘单读多写式的磁带，也防不住火，它还是会让火烧掉
4.4.8. 许多号称不可变的机制其实并非真正的不可变
4.4.8.1. 如果备份管理员能够在创建完备份数据之后，缩减该备份的保留时间，那么这实际上就不是真正的不可变
4.4.8.2. 备份管理员能否删除已经做好的备份（或者能否让还没有到期的备份提前过期）
4.4.8.2.1. 如果可以，那么这样制作出来的备份，其实并非真正的不可变
