为什么需要进行备份？ 毕竟，设备非常非常可靠，而且还有比物理服务器可靠性更好的“云”：通过正确的配置，“云”服务器可以轻松地在基础设施物理服务器发生故障时继续存在，并且从从服务用户的角度来看，服务时间会有一个微小的、几乎察觉不到的跳跃。 此外，信息重复通常需要付出“额外”的处理器时间、磁盘负载和网络流量的代价。
理想的程序运行速度快、不泄漏内存、没有漏洞、不存在。
-未知
由于程序仍然是由蛋白质开发人员编写的，并且通常没有测试过程，而且程序很少使用“最佳实践”（它们本身也是程序，因此并不完美）来交付，因此系统管理员通常必须解决听起来很简单但实际上很简单的问题。简而言之：“恢复到原来的样子”，“使基础恢复正常运行”，“缓慢工作 - 回滚”，还有我最喜欢的“我不知道是什么，但修复它”。
除了由于开发人员粗心工作或综合情况而产生的逻辑错误，以及对构建程序的小功能（包括连接和系统功能，包括操作系统、驱动程序和固件）的不完整了解或误解 -还有其他错误。 例如，大多数开发人员依赖于运行时，完全忘记了物理定律，而这些物理定律仍然无法使用程序来规避。 这包括磁盘子系统以及一般情况下任何数据存储子系统（包括 RAM 和处理器缓存！）的无限可靠性，以及处理器上的零处理时间，以及在通过网络传输和在计算机上处理期间不存在错误。处理器和网络延迟，该延迟等于 0。您不应该忽视臭名昭著的最后期限，因为如果不及时满足，将会出现比网络和磁盘操作的细微差别更严重的问题。
如何处理全面出现并影响有价值数据的问题？ 没有什么可以取代活着的开发人员，而且在不久的将来这也不是可能的事实。 另一方面，只有少数项目成功地充分证明该计划将按预期工作，并且不一定可以将证据应用于其他类似的项目。 此外，此类证据需要花费大量时间并需要特殊技能和知识，考虑到最后期限，这实际上最大限度地减少了使用它们的可能性。 此外，我们还不知道如何使用超快速、廉价且无限可靠的技术来存储、处理和传输信息。 此类技术如果存在的话，也是以概念的形式出现的，或者最常见的是仅出现在科幻小说和电影中。
好的艺术家抄袭，伟大的艺术家偷窃。
-巴勃罗毕加索。
最成功的解决方案和令人惊讶的简单事情通常发生在乍一看完全不相容的概念、技术、知识和科学领域相遇的地方。
例如，鸟类和飞机都有翅膀，但尽管功能相似 - 某些模式下的操作原理是相同的，并且以类似的方式解决技术问题：中空的骨骼、使用坚固且轻质的材料等 -结果虽然非常相似，但完全不同。 我们在技术中看到的最好的例子也很大程度上借鉴自大自然：船舶和潜艇的加压舱与环节动物直接类比； 构建 raid 阵列并检查数据完整性 - 复制 DNA 链； 以及成对的器官，不同器官的工作独立于中枢神经系统（心脏自动化）和反射 - 互联网上的自主系统。 当然，“正面”采取和应用现成的解决方案充满了问题，但谁知道呢，也许没有其他解决方案。
如果我知道你会跌倒在哪里，我就会铺上稻草！
——白俄罗斯民间谚语
这意味着备份副本对于那些想要执行以下操作的人来说至关重要：
- 能够在最短的停机时间甚至根本没有停机的情况下恢复系统的运行
- 大胆行动，因为一旦出现错误，总是有回滚的可能性
- 最大限度地减少故意数据损坏的后果
这是一个小理论
任何分类都是任意的。 大自然不分类。 我们分类是因为它对我们来说更方便。 我们还根据我们任意获取的数据进行分类。
——让·布鲁勒
无论物理存储方式如何，逻辑数据存储都可以分为两种访问该数据的方式：块和文件。 这种划分最近变得非常模糊，因为纯粹的块以及纯粹的文件逻辑存储并不存在。 然而，为了简单起见，我们假设它们存在。
块数据存储意味着存在一个物理设备，其中数据被写入某些固定部分（块）。 块是在某个地址访问的；每个块在设备内都有自己的地址。
备份通常是通过复制数据块来进行的。 为了确保数据完整性，新块的记录以及对现有块的更改在复制时都会暂停。 如果我们用普通世界来类比，最接近的东西就是一个拥有相同编号单元的壁橱。
基于逻辑设备原理的文件数据存储接近于块存储，并且往往组织在顶层。 重要的区别是存储层次结构和人类可读的名称的存在。 抽象以文件（命名数据区域）的形式分配，以及目录（存储描述和对其他文件的访问的特殊文件）。 文件可以提供附加元数据：创建时间、访问标志等。 备份通常是这样完成的：它们查找更改的文件，然后将它们复制到具有相同结构的另一个文件存储中。 数据完整性通常是通过不写入文件来实现的。 文件元数据的备份方式相同。 最接近的类比是图书馆，其中有不同书籍的部分，并且还有一个包含人类可读的书籍名称的目录。
最近，有时会描述另一种选择，原则上文件数据存储就是从该选择开始的，并且具有相同的古老功能：对象数据存储。
它与文件存储的不同之处在于它没有超过一次的嵌套（平面方案），并且文件名虽然是人类可读的，但仍然更适合机器处理。 执行备份时，对象存储通常与文件存储类似，但偶尔也有其他选择。
— 有两种类型的系统管理员，一种是不进行备份的系统管理员，另一种是已经进行备份的系统管理员。
- 其实分为三种：还有检查备份是否可以恢复的。-未知
还值得理解的是，数据备份过程本身是由程序执行的，因此它具有与任何其他程序相同的缺点。 消除（不是消除！）对人为因素以及功能的依赖 - 这些功能单独使用不会产生很强的效果，但组合在一起可以产生明显的效果 - 所谓的规则 3-2-1。 如何破译它有很多选择，但我更喜欢以下解释：必须存储 3 组相同的数据，2 组必须以不同的格式存储，1 组必须存储在地理上远程的存储中。
存储格式应该理解如下：
- 如果对物理存储方法有依赖性，我们会更改物理方法。
- 如果对逻辑存储方法有依赖，我们就改变逻辑方法。
为了达到3-2-1规则的最大效果，建议两种方式都改变存储格式。
从备份为其预期目的（恢复功能）做好准备的角度来看，“热”备份和“冷”备份之间存在区别。 热的与冷的只有一件事不同：它们可以立即使用，而冷的则需要一些额外的恢复步骤：解密、从存档中提取等。
不要将热副本和冷副本与在线副本和离线副本混淆，这意味着数据的物理隔离，实际上是备份方法分类的另一个标志。 因此，脱机副本（不直接连接到需要恢复的系统）可以是热副本，也可以是冷副本（就恢复准备情况而言）。 在线副本可以直接在需要恢复的地方使用，大多数情况下是热副本，但也有冷副本。
另外，不要忘记，创建备份副本的过程本身通常不会以创建一个备份副本结束，并且可能存在相当多的副本。 因此，有必要区分全备份，即全备份。 那些可以独立于其他备份进行恢复的副本，以及差异（增量、差异、减量等）副本 - 那些无法独立恢复并需要初步恢复一个或多个其他备份的副本。
差异增量备份是一种节省备份存储空间的尝试。 因此，只有与先前备份相比发生变化的数据才会写入备份副本。
创建差异递减备份的目的相同，但方式略有不同：创建完整备份副本，但实际上仅存储新副本与前一个副本之间的差异。
另外，值得考虑存储备份过程，它支持不存储重复项。 因此，如果您在其上写入完整备份，实际上只会写入备份之间的差异，但恢复备份的过程将类似于从完整副本恢复并且完全透明。
Quis custodiet ipsos custodes？
（谁来保护守望者自己？ - lat。）
没有备份副本是非常不愉快的，但如果看似做了备份副本，但恢复时却发现无法恢复，那就更糟糕了，因为：
- 源数据的完整性已受到损害。
- 备份存储损坏。
- 恢复速度非常慢；您无法使用已部分恢复的数据。
正确构建的备份过程必须考虑到这些评论，尤其是前两个。
可以通过多种方式保证源数据的完整性。 最常用的是：a）在块级别创建文件系统的快照，b）“冻结”文件系统的状态，c）具有版本存储的特殊块设备，d）文件的顺序记录或块。 还应用校验和来确保数据在恢复期间得到验证。
还可以使用校验和来检测存储损坏。 另一种方法是使用专用设备或文件系统，其中已记录的数据无法更改，但可以添加新数据。
为了加速恢复，数据恢复使用多个进程进行恢复——前提是不存在慢速网络或慢速磁盘系统形式的瓶颈。 为了解决数据部分恢复的情况，您可以将备份过程分解为相对较小的子任务，每个子任务都单独执行。 因此，可以在预测恢复时间的同时持续恢复性能。 这个问题通常出在组织层面（SLA）上，所以我们不会详细讨论这个问题。
香料专家并不是在每道菜中都添加香料的人，而是从不添加任何额外东西的人。
-在。 西尼亚夫斯基
系统管理员使用的软件的做法可能会有所不同，但总的原则仍然是相同的，特别是：
- 强烈建议使用现成的解决方案。
- 程序应该按可预测的方式运行，即不应该有未记录的功能或瓶颈。
- 设置每个程序应该非常简单，您不必每次都阅读手册或备忘单。
- 如果可能的话，解决方案应该是通用的，因为服务器的硬件特性可能存在很大差异。
有以下常用程序可用于从块设备进行备份：
- dd，对于系统管理老手来说很熟悉，这也包括类似的程序（例如相同的 dd_rescue）。
- 某些文件系统中内置的实用程序，用于创建文件系统的转储。
- 杂食性公用事业； 例如部分克隆。
- 自己的（通常是专有的）决定； 例如，NortonGhost 及更高版本。
对于文件系统，使用适用于块设备的方法可以部分解决备份问题，但可以使用以下方法更有效地解决该问题：
- Rsync，用于同步文件系统状态的通用程序和协议。
- 内置归档工具 (ZFS)。
- 第三方归档工具； 最受欢迎的代表是 tar。 还有其他的，例如 dar - 针对现代系统的 tar 的替代品。
值得单独提及的是在创建备份副本时确保数据一致性的软件工具。 最常用的选项是：
- 以只读模式（ReadOnly）挂载文件系统，或者冻结文件系统（freeze）——该方法的适用性有限。
- 创建文件系统或块设备（LVM、ZFS）状态的快照。
- 使用第三方工具来组织印象，即使在由于某种原因无法提供前述要点的情况下（例如 hotcopy 等程序）。
- 然而，更改时复制技术 (CopyOnWrite) 通常与所使用的文件系统（BTRFS、ZFS）相关。
因此，对于小型服务器需要提供满足以下要求的备份方案：
- 易于使用 - 操作过程中不需要特殊的额外步骤，创建和恢复副本的步骤最少。
- 通用 - 适用于大型和小型服务器； 这在增加服务器数量或扩展时很重要。
- 通过包管理器安装，或通过一两个命令（例如“下载并解压”）安装。
- 稳定 - 使用标准或长期建立的存储格式。
- 工作速度很快。
大致符合要求的申请人：
- rdiff-备份
- 快照
- 饱嗝儿
- 重复的
- 表里不一
- 让杜普
- 给
- 备份
- 静止的
- 博格备份
将使用具有以下特征的虚拟机（基于XenServer）作为测试平台：
- 4核2.5GHz，
- 16 GB 内存，
- 50 GB 混合存储（在 SSD 上缓存虚拟磁盘大小 20% 的存储系统），采用不分区的单独虚拟磁盘形式，
- 200 Mbps 互联网通道。
几乎同一台机器将用作备份接收服务器，仅配备 500 GB 硬盘。
操作系统 - Centos 7 x64：标准分区，附加分区将用作数据源。
作为初始数据，我们采用一个包含 40 GB 媒体文件和 mysql 数据库的 WordPress 网站。 由于虚拟服务器的特性差异很大，并且为了更好的再现性，这里是
使用 sysbench 的服务器测试结果。sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu 运行
sysbench 1.1.0-18a9f86（使用捆绑的 LuaJIT 2.1.0-beta3）
使用以下选项运行测试：
线程数：4
从当前时间初始化随机数生成器
质数限制：20000
正在初始化工作线程...
线程开始了！
CPU速度：
每秒事件数：836.69
速率：
事件/秒（eps）：836.6908
经过的时间：30.0039s
事件总数：25104
延迟（毫秒）：
分钟：2.38
平均：4.78
最大值：22.39
第 95 个百分位数：10.46
总计：119923.64
线程公平性：
事件（平均/标准差）：6276.0000/13.91
执行时间（平均/标准差）：29.9809/0.01
sysbench --threads=4 --time=30 --内存块大小=1K --内存范围=全局 --内存总大小=100G --内存操作=读取内存运行
sysbench 1.1.0-18a9f86（使用捆绑的 LuaJIT 2.1.0-beta3）
使用以下选项运行测试：
线程数：4
从当前时间初始化随机数生成器
使用以下选项运行内存速度测试：
块大小：1KiB
总大小：102400MiB
操作：读取
范围：全球
正在初始化工作线程...
线程开始了！
总操作数：50900446（每秒 1696677.10）
49707.47 MiB 传输（1656.91 MiB/秒）
速率：
事件/秒（eps）：1696677.1017
经过的时间：30.0001s
事件总数：50900446
延迟（毫秒）：
分钟：0.00
平均：0.00
最大值：24.01
第 95 个百分位数：0.00
总计：39106.74
线程公平性：
事件（平均/标准差）：12725111.5000/137775.15
执行时间（平均/标准差）：9.7767/0.10
sysbench --threads=4 --time=30 --内存块大小=1K --内存范围=全局 --内存总大小=100G --内存操作=写内存运行
sysbench 1.1.0-18a9f86（使用捆绑的 LuaJIT 2.1.0-beta3）
使用以下选项运行测试：
线程数：4
从当前时间初始化随机数生成器
使用以下选项运行内存速度测试：
块大小：1KiB
总大小：102400MiB
操作：写
范围：全球
正在初始化工作线程...
线程开始了！
总操作数：35910413（每秒 1197008.62）
35068.76 MiB 传输（1168.95 MiB/秒）
速率：
事件/秒（eps）：1197008.6179
经过的时间：30.0001s
事件总数：35910413
延迟（毫秒）：
分钟：0.00
平均：0.00
最大值：16.90
第 95 个百分位数：0.00
总计：43604.83
线程公平性：
事件（平均/标准差）：8977603.2500/233905.84
执行时间（平均/标准差）：10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio 运行
sysbench 1.1.0-18a9f86（使用捆绑的 LuaJIT 2.1.0-beta3）
使用以下选项运行测试：
线程数：4
从当前时间初始化随机数生成器
额外的文件打开标志：（无）
128 个文件，每个 8MiB
文件总大小 1GiB
块大小 4KiB
IO请求数：0
组合随机 IO 测试的读/写比率：1.50
启用定期 FSYNC，每 100 个请求调用 fsync()。
测试结束时调用 fsync()，启用。
使用同步I/O模式
进行随机读/写测试
正在初始化工作线程...
线程开始了！
速率：
读取：IOPS=3868.21 15.11 MiB/秒（15.84 MB/秒）
写入：IOPS=2578.83 10.07 MiB/秒（10.56 MB/秒）
同步：IOPS=8226.98
延迟（毫秒）：
分钟：0.00
平均：0.27
最大值：18.01
第 95 个百分位数：1.08
总计：238469.45
这篇笔记开始了一个大的
有关备份的系列文章
- 备份，第 1 部分：为什么需要备份，方法和技术概述
- 备份第 2 部分：审查和测试基于 rsync 的备份工具
- 备份第 3 部分：审查和测试口是心非、重复、似曾相识的重复
- 备份第 4 部分：审查和测试 zbackup、restic、borgbackup
- 备份第 5 部分：测试适用于 Linux 的 bacula 和 veeam 备份
- 备份第 6 部分：比较备份工具
- 备份第 7 部分：结论
来源： habr.com