原文引自：
本文档描述BackupPC 4.1.3版本,2017年6月3日发布。
Overview
BackupPC是一个高性能、企业级备份系统，它可以备份Unix,Linux,Windows,和MacOSX电脑,台式机和笔记本电脑到服务器的磁盘。 BackupPC高度可配置,且易于安装和维护
Features include:
l 一个聪明的池计划最小化磁盘存储和磁盘I/O。 相同或者不同PC机上的相同文件在多个备份中仅存储一次，从而大量节省磁盘存储和磁盘读写
l 压缩功能进一步减少存储占用，取决于将要备份的数据类型。由于只有新文件才需要压缩(那些文件不在池中), 压缩对CPU的影响是比较低的。
l 一个强大的http / cgi用户界面允许管理员可以查看当前状态，编辑配置,添加/删除主机,查看日志文件,并允许用户初始化和取消备份和从备份中浏览和恢复文件。
l http / cgi用户界面提供国际化支持，目前提供英语，法语，德语，西班牙语，意大利、荷兰、波兰、巴西，葡萄牙、中国、波兰、捷克、日本、乌克兰和俄罗斯。
l 不需要客户端软件。使用Windows标准smb协议用于提取备份数据。在linux、unix或MacOSX客户端, rsync,tar(基于ssh / rsh / nfs之上)或ftp是用来提取备份数据。或者, 在Windows也可以使用rsync (使用cygwin), 因为rsync提供了有效的传输并允许增量备份来检测几乎所有的变化。
l 灵活的恢复选项。单个文件可以从CGI接口的任何备份直接下载。从任何备份所选定的文件或目录都可以从CGI界面下载的Zip或Tar归档。最后, 支持从CGI接口直接恢复所选定的文件或目录到客户端机器(使用smb或tar)。
l BackupPC支持移动环境，笔记本电脑只是间歇性地连接到网络,具有动态IP地址(DHCP)。配置设置允许通过较慢的广域网连接的机器(如:拨号, DSL, 电缆)不备份,即使他们使用相同的固定或动态IP地址时直接连接到局域网。
l 灵活的配置参数允许多个备份并行执行,哪些共享要备份, 哪些目录要备份或者不备份的规定, 电子邮件提醒用户各种全量和增量备份调度等等。配置参数可以设置系统全局或也可以在基于每台电脑上
l 如果他们的电脑最近没有被备份，则定期发送电子邮件提醒。邮件内容,时间和策略是可配置的。
l BackupPC
GitHub主持的开源软件。
BackupPC 4.0
这是发布的第一个4.0版本，4.0对BackupPC作了重大改写，本节提供BackupPC 4.0一个简短的功能和变化的概述。
V4版本的简短汇总摘要：
l 不使用硬连接(暂时做原子重命名除外)。在应用程序级别通过批处理的方式处理引用计数 (硬连接将仍然保留在任何遗留V3版本的备份)。
l 备份作为“反向增量”被存储——最近的备份总是填满的，较老的备份通过合并所有的增量来重组, 并作为最近的下一个填满的备份的开始，向后工作。
由于上句翻译可能不准，原英文如下：
Backups
are stored as "reverse deltas" - the most recent backup is always
filled and older backups are reconstituted by merging all the deltas starting with the nearest future
filled backup and working backwards.
l 这是与V3相反的,增量备份相对于之前的备份作为”正向增量“被存储 (典型的最后一次完整备份或之前的低级别增量备份,或者最后一个通过rsync的完整备份)
l 由于最近的备份是填满的,因此查看/恢复备份(这是最常用的备份)不需要从其他备份合并任何增量。
l 增量/完整备份的概念和非填满/填满存储是分离的。默认情况下，最近的备份总是填满的,其余的备份、完整备份是填满的和增量备份是非填满的,但这是可配置的。
l 使用全文件MD5摘要,它存储于目录的属性文件。每个备份目录只包含一个空的属性文件，它的名字包括自己的MD5摘要,用于在池中查找的属性文件的内容。反过来,这个文件包含了目录中每个文件的元数据,包括每个文件的MD5摘要。
l 池布局仍然支持通过链来处理md5碰撞。虽然MD5碰撞可以构造且现在众所周知的,但碰撞的可能性非常低。V4的池文件不像V3版本，从来不重命名或者移动。
l 可以删除任何备份(如果前一个备份不是填满的，增量合并到前一个更老的备份)。
l 反向增量允许“无限增长”——如果你愿意以快速备份换取风险，则不需要作完整的备份，备份风险是指如果一个文件的元数据文件(例如,mtime或大小)没有改变，则文件的变化将不会被检测到。(注：如果一个文件的change time变化了，即属主，属组改变，可能不会被检测到)
l 现在用rsync作的“完整”备份使用 --checksum (而不是——ignore-times), 这在服务器端是更有效的, 服务器只需要检查,由客户端对文件计算的校验和,与mtime, nlinks, 尺寸属性一起,以查看文件是否已经改变。如果你想要一个更保守的方法,你可以把它改回到 --ignore-times, 它要求服务器向客户机发送块校验和。
l 使用rsync--checksum和允许BackupPC在池中任何地方猜测一个潜在的匹配,甚至是第一次备份。在这种情况下,通常的rsync仍然交换块校验和以确保完整的文件是相同的。
l 使用一个修改的rsync称为rsync_bpc(目前基于rsync-3.0.9)在服务器端(代替File::RsyncP), 使用一个C代码接口到BackupPC存储。所以整个rsync数据路径现在由C代码编译,这比perl快得多。
l 由于rsync-3.X的使用。支持acl和xattrs, 许多其他有用的选项(但不是全部)都被支持。Rsync协议3.0支持高效的增量文件列表,这极大地提高了内存使用和启动时间。它还支持MD5全文件校验和,匹配BackupPC新的摘要。允许一个完全文件摘要在服务器端像检查mtime一样(容易)被检查。
l BackupPC代码的重要部分现在用C代码编译为一个新模块称为BackupPC::XS, 它被动态链接到perl。
这里是一个更新详细的讨论：
l 全新的备份存储。没有硬连接! 备份被存储为反向增量,最近的备份总是填满。之前备份“n”包含相对于之前备份“n + 1” 的变化。
l 由于每个备份是基于上一次填满的备份,(正向)增量的概念被去除。
l 示例: 假定备份# 4是最近,因此备份#4是填满的,而备份# 0 至 3是不填满的。
备份#
0 至 3只是存储了相对于下一个备份需要重组那些备份的反向变化。
n 查看/恢复备份# 4, 所有信息存储在备份# 4
n 查看/恢复备份# 3、备份# 4(填满的), 与备份# 3的增量合并(注:反向增量)
n 查看备份/恢复# 2、备份# 4(填充), 与备份# 3,#2增量合并(注:反向增量)
n 以此类推
|
当一个新的备份(# 5)开始,我们开始将备份# 4重命名为#备份 5。在那一瞬间,备份# 4存储(现在)是空的(这意味着备份# 4和# 5目前相同)。当备份运行时,改变被填加的备份#5,相反的变化被添加到备份# 4,保持备份# 4不变的“视图”。 (be make to...with 使…与…)
备份完成后, 备份# 5是目前最新填满版本的备份,而备份# 4包含必要的从备份# 5返回到备份# 4状态的改变。如果在新的备份操作中没有检测到变化,存储树备份# 4将是空的。如果只有一个文件改变了,新文件将在备份# 5下面, 之前的文件将备份# 4下面(这种说法在技术上不完全正确,因为文件不存储在备份树下,更正确, 备份# 5的属性文件将指向新的池文件,和备份# 4的属性文件将指向旧的池文件)。
l 增量/完整备份和非填满/填满存储现在分离的。最近的备份总是充满的(无论最近的备份是完整或增量)。为了方便更快的恢复旧的备份，某个更老的备份可以是填满的(因为需要合并的备份更少), 用于指定过期调度。
l 当备份启动时,有几种不同的情况下决定如何存储备份和之前的增量备份是否存储:
1． 没有已存在的备份:创建一个新的备份# 0，即做一个完整的备份(即:没有之前的增量存储)。
2． V3备份存在,但没有V4备份。最新的V3备份被复制为V4格式,再做完整的备份(即:没有之前增量存储)。
3． 最新的V4备份是一个完整(填满)的,或者自上一次填满备份大于$Conf { FillCycle }。上次备份被复制以创建一个新的填满备份, 作一个新的备份(即:没有之前的增量存储)。
4． 有V4备份，但是自上一次填满备份小于$Conf{
FillCycle }。最近一次备份被重编号# n + 1, 把反向增量填充到初始化为空的备份树# n。
5． 压缩开关可以在备份时打开/关闭。这不是好的测试,甚至很难有效地支持。因为这是填满的，所以我们把这作为一个全新的(空的)的备份, 这样我们就不需要合并备份时打开或关闭压缩选项。
6． 上一次备份是V4部分。如果之前的V4备份是填满的(而不是部分),然后就做另一个适当的备份。否则,视为(上面的)案例4。当完成备份时(无论是否成功或者是另一个部分),删除在备份#n中之前的增量,合并累计改变到备份# n - 1。(注：术语“部分” 将在下面段落【backup基础】段落讲述)
l (在V4里)“部分”备份的处理已经改变了。不像在V3中, 下一个备份之前删除”部分”备份, 在V4里部分被保留,并作为下一个备份的起点。参见上面的例6。如果新的备份失败,且如果没有文件被备份,则空备份# n被移除。
l 备份存储为特殊的目录树,但每个目录只包含一个“属性”文件。属性文件长度为零,其名称包括MD5摘要的以便内容可以在池中查找。(mangle: v. 压坏，糟蹋. n 轧布机)，
在池中属性内容包含目录内容:为每一个文件,这意味着元数据,xattrs和文件内容的MD5摘要。
l 修改rsync称为rsync_bpc,基于rsync 3.0.9,用于在服务器端, 通过C代码(层)模拟的所有文件系统的操作系统调用与BackupPC存储兼容。这意味着rsync的数据路径现在完全由C编译, 这将意味着显著提速。这也意味着许多(但不是所有)的rsync选项是原生支持的。
l BackupPC存储和池代码的重要部分是用C编写的(相同的代码用于服务器rsync_bpc中)。BackupPC:FileZIO, BackupPC::PoolWrite, BackupPC:Attrib,
BackupPC::AttribCache BackupPC::PoolRefCnt(引用计数和存储)都换成BackupPC::XS, 一个C代码perl扩展。
l 支持扩展属性(xattr)。Rsync配置为“store acl using xattr”,意味着acl和xattrs都支持。
l rsync支持无限增量备份。最近的备份总是填满的, 因此一个增量备份仍保留最近的填满的备份了。
l 可以删除任何V4备份 --- 合并到下一个较老的备份取决于它是否是一个已经填满的备份。
l 文件摘要全文件MD5摘要。相比V3碰撞更不可能,但仍然是有可能的。通过16字节的MD5摘要扩展实现复制 (即:16字节为普通文件,17字节是下一个255副本等)。(17字节有点不理解)
l V4池文件存储在一个新的(目录)层次, 深度为两层, 每一层7 bit位 (即:顶级目录128个,每个目录下又包含128个目录. 注：2的16次方：16384个目录)。
l V4池文件永远不会移动或重命名。
l 对于硬链接文件，其索引节点(inode)存储在每个备份树里。这使得备份硬链接比V3准确, 并且在备份中提供了一致的inode编号。
l 大小为零的文件或空属性文件不会被写或者进入池. (特注：这有可能意味着空文件不会被备份，如果是python的init文件，这类文件遍布于各个包中，如果备份过程不备份或者不能被恢复，恢复出来的python程序将无法使用，这一点需要在实践中求证：求证结果是空文件会备份)
l 硬连接的取消意味着引用计数必须由BackupPC代码维护。在开发和测试术语中，这是一个最高的风险之一。引用计数维护每一个备份，每一个主机以及整个池。
1. 每个操作都会改变引用计数 (如:做一个新的备份, 删除一个备份, 或复制(填满)一个备份)在客户端的备份目录创建一个或多个poolRefDelta文件 (即:TopDir / pc /主机/ NNN)。这些文件是MD5摘要列表,和相应的计数增量。
2. 每天晚上,BackupPC_nightly运行BackupPC_refCountUpdate, 对于每一个主机, 用新增量来更新每个主机引用计数数据库(注: 这里所说的数据库并不是mysql或者oracle, 老外习惯把包含数据的文件，也称为数据库)。然后结合中所有主机引用计数文件来创建全局池引用计数数据库。
3. BackupPC_refCountUpdate可以与备份并发运行。如果你仍有V3备份和v3池, BackupPC_nightly仍然需要运行和检查旧V3池文件,这些文件可以删除。但由于没有新的V3备份发生,BackupPC_nightly可以与备份并发运行。
l 有一个新的工具BackupPC_fsck可以检查/修复每个主机和全局引用计数。通过分析每个备份树中所有的属性文件验证了每个主机引用计数数据库。通过梳理所有的主机引用计数数据库并加以比较来验证全局引用计数数据库。
BackupPC运行时，BackupPC_fsck时不能运行。
l 当BackupPC_refCountUpdate更新全部的引用计数时,它删除引用计数为0的池文件。为了避免竞态条件,它分一个两阶段处理。首先, 它使用文件属性标记零引用计数的文件。下次运行(通常是24小时后),任何仍然标记为零引用计文件将被删除。其他的代码知道不使用已标记池文件以避免竞态条件。
l 进度指示:一个简单的状态显示当前已处理的文件数量。但很难把它转换为一个百分比, 因为直到备份完成才能知道处理文件的总数。但知道文件数量还是非常有用,因为你可以根据之前的备份对当前备份有个预期,或知道你改变哪个配置(如:添加一个新的大型树)。
l BackupPC_link已删除, 因为它已不再使用。
l 由于文件不再存储在备份树, 浏览备份树甚至比V3更加困难 (你只需要处理mangling)。一个新工具BackupPC_ls就像“ls - l”, 准确的显示目录列表文件,及其MD5摘要。
BackupPC_ls 既可以显式地列出主机名、数量、和unmangled路径,也可以给出完整的(mangled破坏)路径,这使得使用目录完成更加容易。在BackupPC_ls中配置tcsh和bash,加上一些新的钩子,给一个更自然的文件/目录完成是可能的(注：这句不太理解)
BackupPC_zcat也可以显示MD5摘要(您可以从BackupPC_ls粘贴)。目前BackupPC_zcat不支持树分析BackupPC_ls(它只能zcat实际文件),但这应该很容易纠正。
l 配置到期: 因为全量/增量是解耦从填满/空,到期有点复杂。
对过期参数的约定是 “FullKeepPeriod / FullKeepCnt”等与填满备份相关,和“IncrKeepPeriod
/ IncrKeepCnt”与非填满备份相关。
l V3迁移:没有特别的约定。V4可以浏览/查看/ V3恢复备份。当你安装V4, 任何V3备份没有更改。如果你从V3升级,一定要设置$Conf{ PoolV3Enabled } to 1,以便老的V3池搜索匹配的文件。
? 当你安装V4时,它会注意到V3池存在。运行configure.pl应该设置配置{ PoolV3Enabled } 为1在这种情况下,但是你应该确保检查这个选项。
? 当V4版本第一次备份时,BackupPC_backupDuplicate运行复制最近V3备份以创建一个新的V4备份。一个最近的V3备份“填满”视图被用于创建一个“填满的”V4备份树。
这一步可能会耗时,因为需要读取每个文件(作为V3文件)并写成V4文件。然而,V4池代码知道V3池, 因此它将V3池文件到V4池。所以这复制过程中不消耗大量的池存储空间,但是每个文件仍然需要读(计算MD5摘要)和“写”(实际上只是匹配/链接).
? 到期:所有V3 + V4备份是在综合考虑的基础上进行到期检查。
? 干净的新安装V4版本中，计算和检查V3摘要的步骤被消除了。
? 从V4降级到V3: 未经测试且不推荐。理论上可以删除任何新的V4备份、删除V4池本身, 你应该能够重新安装V3并且仍然可以访问原始的完整工作V3存储(除了任何可能在V4中基于正常备份过期配置中定期删除的V3备份)。
然而, 任何迁移到V4的V3池文件将不再V3池中。所以后续V3备份将消耗更多的存储因为文件被重新添加到旧V3池。
希望降级没有必要…
l 优化: C代码实现提供了显著的性能优势,而且更加灵活。
潜在的V4优化计划,但尚未实现,包括:
? rsync-bpc不支持校验和缓存。
? rsync-bpc 使用ignore-times选项，实际上读取每个未改变的文件三次,和写一次(正常rsync读两次, 写一次, 额外的一次是由于压缩)。仔细优化可以消除两个读和写。最后通过缓存校验和读可以消除。
? BackupPC_refCountUpdate，BackupPC_fsck，BackupPC_backupDuplicate， BackupPC_backupDelete都是单线程的。
Backup basics
Full Backup
? 完整的备份是一个完整的共享的备份。BackupPC可以配置为定期完整备份(通常每周)。BackupPC可以配置为保持一定数量的完整备份。还支持指数到期,允许保留各种年份的完整备份(例如,一个可设置数量的最近每周的完整备份,加上一个可设置数量的较早的相隔2,4,8或16周完整备份)。
Incremental Backup
? 增量备份是自上一次成功的备份之后又修改过的文件的备份。
? Rsync是 BackupPC是最好的选择。自上次完全备份后，任何文件的属性发生了变化(即:uid、gid,mtime模式,大小)都会被备份。删除的，新文件和重命名文件,都可以被rsync 增量检测到。
? 对于SMB和Tar, BackupPC使用修改时间(mtime)来确定自从上次备份后哪些文件已经改变了。这意味着SMB和tar 增量是不能够检测删除文件、重命名文件或新文件的修改时间是在上一次较低级备份之前。(这句不太理解)(注：如果文件的属主，属组，权限发生变化(ctime)，使用smb, tar, 则可能无法被检测到)
? BackupPC也可以配置为保持一定数量的增量备份,并保持较少非常老的增量备份。
? 当浏览或恢复时，BackupPC基于每个备份的级别，”填充“ 增量备份, 给每一个备份“完整”的外观。这使得浏览和恢复备份更容易:您可以从任何一个备份恢复并不依赖备份是增量的还是完整的。
Partial Backup
? 当一个完整的或增量备份失败或取消,最近的备份被标记为“部分”。V4之前,这样的备份是不完整的,下一次备份完成时，它将会被删除。
? 在V4版本中，部分备份表示上次备份是不完整的。然而,由于V4备份做了适当的更新,它代表了最好的和最新的备份。部分备份可以浏览或者就像一个成功的完整或增量备份一样，用于恢复文件。它将被用作下一次备份的起点。
Identical Files
? BackupPC池里相同的文件。“相同的文件”是指文件相同的内容,并不是必须相同的权限,所有权或修改时间。两个文件可能有不同的权限,所有权,或修改时间, 只要内容是相同的，但仍然放入池中。这是可能的，因为BackupPC存储文件元数据(权限、所有权和修改时间)与文件内容是分离的。
? V4之前,相同的文件使用硬连接存储。在V4 版本后,硬连接消除了(除了临时原子重命名),和引用计数是在应用程序级别完成的。(注：引用计数取代了硬连接)
Backup Policy
根据你站点的需求,你需要决定你的备份策略是什么。BackupPC不是被设计来提供精确的重装失败的磁盘。有关更多信息,请参见“一些限制”。然而,rsync和tar为linux / unix客户传输,加上完全支持特殊的文件类型,扩展属性等, 这很可能意味着构造一个linux / unix文件系统。
BackupPC保存备份到磁盘上。因为池可以相对经济地保持几个星期或几个月的旧备份。
在一些网站基于磁盘的备份将是足够的,不需要第二个异地云,磁盘或磁带备份。这个系统对任何单点故障是健壮的:如果客户端磁盘失败或丢失文件, BackupPC服务器可以用来恢复文件。如果服务器磁盘失败, BackupPC可以重新创建一个新的文件系统,并从客户端创建新的备份。由于花了更多的钱在越来越好的RAID系统，服务器磁盘失败的机会可能非常小。然而, 如果他们物理距离很近, 仍有灾难性事件的风险,如火灾或地震既可以摧毁BackupPC服务器也可以摧毁它备份的客户端。
一些网站可以选择进行定期备份到磁带或cd / dvd。假定每周做这种备份，可以使用BackupPC的归档功能。
其他用户已经报告成功的将可移动磁盘数据转移到BackupPC数据驱动器,或者使用rsync镜像BackupPC数据池到异地。(第一句不太理解)
在V4版本中, 因为硬连接永久不再使用, 复制V4池要容易得多, 允许远程复制池。
Resources
BackupPC home page：BackupPC home page
Github：
packages BackupPC-XS and rsync-bpc are
available at
https://github.com/backuppc/backuppc/releases
https://github.com/backuppc/backuppc-xs/releases
https://github.com/backuppc/rsync-bpc/releases
on SourceForge:
https://sourceforge.net/projects/backuppc/files
BackupPC Wiki：
翻译体会：
方向决定生死，细节决定成败。
细节真的很重要，一字之差 谬以千里
对语法的掌握很重要，了解文章所描述的事物同样重要
不能孤立的翻译单个单词，要多注意词组
翻译是否合理，是否符合逻辑，依赖于上下文的理解和判断
具有广泛意义的单词：take , give,make
