为什么需要进行备份？ 毕竟，设备非常非常可靠，此外，在可靠性方面还存在比物理服务器更好的“云”：如果配置正确，则“云”服务器将很容易在基础架构物理服务器的故障中幸免，并且从服务用户的角度来看，时间上会有很小的变化，几乎看不到服务。 另外，信息的重复通常需要支付“额外的”处理器时间，磁盘负载，网络流量。
理想的程序运行速度快，不流经RAM，没有孔且不存在。
—未知
由于这些程序仍然是由蛋白质开发人员编写的，并且通常缺少测试过程，而且使用“最佳实践”（它们本身也是程序，因此是不完善的）的使用，极少提供程序，因此系统管理员通常不得不解决听起来很糟糕的问题。简短而简洁地说：“恢复原状”，“使基地恢复正常运行”，“工作缓慢-我们正在回撤”，还有我最喜欢的“我不知道，但要解决”。
除了由于开发人员的粗心工作或各种情况而导致的逻辑错误，以及对构建程序的小功能（包括绑定程序和系统功能，包括操作系统，驱动程序和固件）的不完全了解或误解之外，还存在其他错误。 例如，大多数开发人员都依赖运行时，而完全忘记了在程序的帮助下仍然无法绕过的物理定律。 这包括磁盘子系统和所有数据存储子系统（包括RAM和处理器缓存！）的无限可靠性，处理器上的处理时间为零，并且在网络上传输以及在处理器上进行处理时没有错误，并且网络延迟为0。不要忽略臭名昭著的截止日期，因为如果您没有时间，那将会比网络和磁盘的细微问题更干净。
但是，在全面增长中出现并悬而未决有价值数据的问题又如何呢？ 没有什么可以替代实时开发人员，也不是在不久的将来将有可能的事实。 另一方面，要完全证明该程序将按预期工作，到目前为止，只有少数几个项目成功了，并且根本不可能将证据应用到其他类似的项目上。 同样，这样的证据会花费很多时间，并且需要特殊的技能和知识，并且考虑到截止日期，这实际上最小化了其应用的可能性。 此外，我们仍然不知道如何使用超快速，廉价和无限可靠的技术来存储，处理和传输信息。 此类技术（如果存在）将以概念的形式出现，或者（通常）仅在科幻小说和电影中出现。
优秀的艺术家复制，伟大的艺术家偷。
-毕加索（Pablo Picasso）。
最成功的解决方案和令人惊讶的简单事情通常发生在乍一看绝对不兼容的概念，技术，知识，科学领域的地方。
例如，鸟类和飞机都有机翼，但尽管功能相似-在某些模式下的操作原理是相同的，并且技术问题的解决方式也相似：空心骨头，使用坚固轻质的材料等-结果完全不同，尽管非常相似。 我们在技术中观察到的最好的样本也大多是从自然界中借来的：船舶和潜艇中的密闭隔间–与类人动物直接相似； 建立突袭阵列并检查数据完整性-DNA链的重复； 以及成对的器官，各个器官的工作与中枢神经系统（自动心脏功能）和反射的独立性都是Internet上的自治系统。 当然，“直接”采用和应用现成的解决方案充满了问题，但是谁知道呢，也许没有其他解决方案了。
如果我知道你会跌倒在哪里，我会吸管！
白俄罗斯谚语
因此，备份对于需要的人至关重要：
- 为了能够在最少的停机时间甚至没有停机的情况下恢复其系统的运行
- 随时采取行动，因为如果发生错误，总是有回滚的可能性
- 最大限度地减少故意数据损坏的影响
这是一些理论任何分类都是任意的。 自然不会分类。 我们进行分类，因为它对我们更方便。 并且我们根据数据进行分类，我们也可以任意选择。
扬·布鲁勒（Jan Bruler）
不管物理存储方法如何，数据的逻辑存储都可以分为两种访问数据的方式：块和文件。 最近这种划分非常模糊，因为不存在纯粹的块逻辑以及纯粹的文件逻辑存储。 但是，为简单起见，我们假设它们是。
数据的块存储意味着存在一个物理设备，数据记录在某些固定部分（块）中。 对块的访问将到达某个地址，每个块在设备中都有其自己的地址。
备份通常是通过复制数据块来完成的。 为了确保复制时的数据完整性，将暂停记录新块以及修改现有块。 如果我们从普通世界中进行类比，则最接近的壁橱中的单元格编号相同。
根据逻辑设备的原理，数据的文件存储接近块存储，并且通常在顶部进行组织。 重要的区别是存在存储层次结构和易于理解的名称。 抽象以文件（命名数据区域和目录）的形式突出显示，该目录是一个特殊文件，其中存储了对其他文件的描述和访问。 可以为文件提供其他元数据：创建时间，访问标志等。 他们通常以这种方式进行备份：他们查找更改的文件，然后将它们复制到具有相同结构的另一个文件存储中。 通常通过不存在要写入的文件来实现数据完整性。 文件元数据的备份类似。 最接近的类比是图书馆，该图书馆的各节包含不同的书籍，以及一个具有人类可读书籍名称的目录。
最近，有时描述了另一种选择，该选择从原则上开始数据的文件存储，并且具有相同的古老特征：对象数据存储。
它与文件存储的不同之处在于，它不止一个嵌套（平面布局），而且文件名虽然易于阅读，但仍更适合于机器处理。 备份时，对象存储通常被视为文件存储，但是偶尔还有其他选择。
-有两种类型的系统管理员，即不进行备份的管理员和已经进行备份的管理员。
-实际上，有三种类型：还有一些人可以验证备份是否可以还原。
—未知
值得一提的是，备份数据的过程是由程序执行的，因此它具有与另一个程序相同的缺点。 要消除（但不排除！）对人为因素的依赖，以及对功能的依赖，即所谓的独立性虽然不会产生很大的影响，但可以共同产生明显的效果。 规则3-2-1。 有许多解密方法，但我更喜欢以下解释：您需要存储3组相同的数据，必须以不同的格式存储2组，并且必须将1组存储在地理上远程的存储中。
存储格式应理解如下：
- 如果对物理存储方法有依赖性，我们将更改物理方法。
- 如果对逻辑存储方法有依赖性，我们将更改逻辑方法。
为了获得规则3-2-1的最大效果，建议以两种方式更改存储格式。
从备份准备用于其预期目的（恢复可操作性）的角度来看，有“热”和“冷”备份。 热与冷的区别仅在于一件事：它们可以立即准备工作，而冷以进行恢复则需要一些其他操作：解密，从存档中提取内容等。
不要将热拷贝和冷拷贝与联机和脱机拷贝混淆，这暗示着数据的物理隔离，实际上，这是备份方法分类的另一个标志。 因此，离线副本（未直接连接到需要还原的系统上）可以是热的或冷的（就恢复准备而言）。 联机副本可以在需要还原的地方直接获得，通常是热的，但也有冷的。
此外，请不要忘记，创建备份的过程通常不会以创建单个备份而结束，并且可能会有很多副本。 因此，有必要在完全备份之间进行区分，即 可独立于其他备份恢复的那些，以及差异（增量，差异，递减等）副本-无法独立还原且需要初步还原一个或多个其他备份的那些。
差异增量式备份-尝试节省用于存储备份的空间量。 因此，仅将先前备份中的修改数据写入备份。
差异递减是出于相同的目的而创建的，但方式略有不同：进行了完整备份，但实际上仅存储了新副本和前一个副本之间的差异。
另外，值得考虑在存储顶部进行备份的过程，该过程支持不存在重复存储。 因此，如果在其上编写完整备份，则实际上只会记录备份之间的差异，但是，还原备份的过程将类似于从完整副本还原并且完全透明。
Quis custodiet ipsos custodes？
（谁来守护看守人自己？-拉特。）
当没有备份时，这是非常不愉快的，但是，如果似乎要进行备份，则情况会更糟，但是在还原过程中，它证明无法还原，因为：
- 源数据的完整性受到侵犯。
- 备份存储已损坏。
- 恢复工作非常缓慢，您不能使用部分恢复的数据。
正确构建的备份过程必须考虑到此类注释，尤其是前两个注释。
可以通过多种方式保证源数据的完整性。 最常用的是：a）在块级别创建文件系统快照，b）冻结文件系统的状态，c）具有版本存储的特殊块设备，d）顺序记录文件或块。 校验和还用于确保恢复期间的数据验证。
也可以使用校验和来检测存储的损坏。 另一种方法是使用专用设备或文件系统，在其中无法修改已记录的数据，但可以添加新的数据。
为了加快恢复速度，数据恢复与几个恢复过程一起使用-前提是没有慢网络或慢磁盘系统形式的“瓶颈”。 为了通过部分还原的数据来避免这种情况，可以将备份过程分为相对较小的子任务，每个子任务都单独执行。 因此，可以通过预测恢复时间来一致地恢复性能。 这个问题通常存在于组织平面（SLA）中，因此我们不会在此进行详细介绍。
关于香料的知识不是很多，不是将香料添加到每道菜的人，而是从不添加任何多余香料的人。
B． 西尼亚夫斯基
关于系统管理员使用的软件的惯例可能会有所不同，但是一般原则仍然是相同的，一种或另一种方式，特别是：
- 强烈建议使用现成的解决方案。
- 程序应该可预测地工作，即 不应有未记录的功能或瓶颈。
- 设置每个程序应该足够简单，这样您不必每次都阅读手册或备忘单。
- 如果可能，该解决方案应该是通用的。 不同服务器的硬件规格可能会非常不同。
以下通用程序可用于从块设备中删除备份：
- dd，对于系统管理的资深人士来说很熟悉，类似的程序也适用于此（例如，相同的dd_rescue）。
- 某些文件系统中内置的实用程序（实用程序），这些文件系统创建文件系统的转储。
- 杂项公用事业； 例如partclone。
- 自己的，通常是专有的决定； 例如NortonGhost及更高版本。
对于文件系统，使用适用于块设备的方法可以部分解决备份任务，但是，可以使用以下方法更有效地解决该问题：
- Rsync，一种用于同步文件系统状态的通用程序和协议。
- 内置存档工具（ZFS）。
- 第三方存档工具； 最受欢迎的代表是焦油。 还有其他一些例子，例如dar-着眼于现代系统来代替tar。
另外，值得一提的是创建备份时的数据一致性软件。 最常用的选项是：
- 以只读模式（ReadOnly）挂载文件系统或冻结（冻结）文件系统-方法受到限制。
- 创建文件系统或块设备（LVM，ZFS）状态的快照。
- 使用第三方工具来组织演员表，即使在由于任何原因而无法提供前几段的情况下（如热拷贝程序）。
- 但是，更改复制技术（CopyOnWrite）最常与所使用的FS（BTRFS，ZFS）绑定。
因此，对于小型服务器，您需要提供满足以下要求的备份方案：
- 易于使用-工作时不需要额外的特别步骤，创建和还原副本的步骤最少。
- 通用-在大型和小型服务器上均可使用； 这在增加服务器数量或扩展规模时很重要。
- 它是由程序包管理器安装的，或通过“下载并解压缩”类型的一个或两个命令安装的。
- 稳定-使用标准或长期建立的存储格式。
- 工作快。
来自或多或少符合要求的申请人：
- rdiff备份
- 快照
- 打
- 重复的
- 双重性
- 似曾相识
- 达
- 备份
- 休息
- 博格巴克
具有以下特征的虚拟机（基于XenServer）将用作测试平台：
- 4核2.5 GHz，
- 16 GB的RAM
- 50 GB混合存储（在固态硬盘上缓存的存储量为虚拟磁盘大小的20％）作为独立的虚拟磁盘，无需分区，
- 200 Mbps互联网通道。
几乎同一台计算机将用作备份目标服务器，但只有500 GB的硬盘驱动器。
操作系统-Centos 7 x64：故障是标准的，一个额外的分区将用作数据源。
让我们以一个wordpress网站作为源数据，其中包含40 GB的媒体文件和一个mysql数据库。 由于虚拟服务器的特性差异很大，并且具有更好的可重复性，因此存在
使用sysbench的服务器测试结果。sysbench --threads = 4 --time = 30 --cpu-max-prime = 20,000 cpu运行
sysbench 1.1.0-18a9f86（使用捆绑的LuaJIT 2.1.0-beta3）
使用以下选项运行测试：
线程数：4
从当前时间初始化随机数生成器
素数上限：20,000
初始化工作线程...
线程开始了！
CPU速度：
每秒事件数：836.69
吞吐量：
事件/秒（eps）：836.6908
经过的时间：30.0039s
活动总数：25104
延迟（毫秒）：
最低：2.38
平均：4.78
最多：22.39
95％位：10.46
和：119923.64
线程公平性：
事件（平均/标准差）：6276.00 / 13.91
执行时间（平均/标准差）：29.9809 / 0.01
sysbench --threads = 4 --time = 30 --memory-block-size = 1K --memory-scope = global --memory-total-size = 100G --memory-oper =读取内存运行
sysbench 1.1.0-18a9f86（使用捆绑的LuaJIT 2.1.0-beta3）
使用以下选项运行测试：
线程数：4
从当前时间初始化随机数生成器
使用以下选项运行内存速度测试：
block size: 1KiB
total size: 102400MiB
operation: read
scope: global
Initializing worker threads…
Threads started!
Total operations: 50900446 (1696677.10 per second)
49707.47 MiB transferred (1656.91 MiB/sec)
Throughput:
events/s (eps): 1696677.1017
time elapsed: 30.0001s
total number of events: 50900446
Latency (ms):
min: 0.00
avg: 0.00
max: 24.01
95th percentile: 0.00
sum: 39106.74
Threads fairness:
events (avg/stddev): 12725111.5000/137775.15
execution time (avg/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global
Initializing worker threads…
Threads started!
Total operations: 35910413 (1197008.62 per second)
35068.76 MiB transferred (1168.95 MiB/sec)
Throughput:
events/s (eps): 1197008.6179
time elapsed: 30.0001s
total number of events: 35910413
Latency (ms):
min: 0.00
avg: 0.00
max: 16.90
95th percentile: 0.00
sum: 43604.83
Threads fairness:
events (avg/stddev): 8977603.2500/233905.84
execution time (avg/stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads…
Threads started!
Throughput:
read: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
write: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latency (ms):
min: 0.00
avg: 0.27
max: 18.01
95th percentile: 1.08
sum: 238469.45
- , 1: , ,
- , 2: rsync-based
- , 3: duplicity, duplicati
- , 4: zbackup, restic, borgbackup
- , 5: Bacula Veeam Backup for Linux
- : : AMANDA, UrBackup, BackupPC
- , 6:
- , 7:
:
Finnix