用于在chkstore中存储文件系统的命令行工具。
chkfs的Python项目详细描述
chkfs-一个命令行工具，用于在chkstore中存储文件系统。
这将使用chkstore库存储文件系统。用例目标包括：
- 使用的冗余拷贝备份许多不同的旧硬盘驱动器 以消除重复数据的方式创建文件系统。
- 以自描述的透明格式存储，以便如果用户发现 他们自己安装了一个典型的新linux，但没有网络，也没有 访问此代码，他们仍然可以使用bzip2、cat， CP等。
- 具有原子一致缓存进度状态的增量备份：
如果备份进程终止，则可以重新启动该进程并赶上其
上次运行时不使用大量资源。
- 原子一致性意味着备份进程可能在 任何不损坏商店的步骤。
- 一致性 同时更新存储而不丢失一致性。 在这种情况下，唯一的失败是覆盖"快照指针"。 使用昂贵的扫描可以重建悬挂的快照指针 商店的。
- 缓存意味着可以删除进度跟踪状态，并且 唯一的影响是下一次备份运行将使用更多的磁盘I/O 和时间，但不会丢失信息或还原任何已提交的 备份状态。
- 支持许多不同的备份源文件系统（旧DOS脂肪，ISO9660，
NTFS…）支持从内核读取文件系统
通过安装，但是备份工具应该保存所有相关的
文件系统元数据。
- 这包括任何编码中的文件名。已知的编码是 ascii和utf8，但是如果两种编码都不能表示文件名， "未知"编码直接存储二进制数据。编码是 先验证ascii，然后utf8，然后下降 回到未知。这意味着编码只是一个提示，因为 非ascii或非utf8文件名可能会被误解为 那些编码。但是，没有数据丢失或损坏。
- 还原部分存储的数据。
- 存储的数据可以细粒度地检查和恢复 方式，例如从大型快照中检索单个文件， 或可传递的目录。
- 递归目录结构。
- osx、tahoe lafs和其他一些文件系统允许递归目录 结构。（例如，在OSX中，目录可能是硬链接的。）
不支持的用例：
- 删除。我的理念是买一个新硬盘并保存数据 永远。有安全隐患，但不知道 未来的数据有多有价值。
- 冗余。底层文件系统或存储驱动程序可以处理 这一点，最好将复杂性放在另一层。
- 高可用性。如果存储节点爆炸，则所有数据都将丢失。 为了防止这种情况发生，请使用其他工具，如Tahoe Lafs。
- 隐私。委派到底层文件系统。
- 跨越信任界限。这是为任何人 有了读取权限，商店可以读取所有内容。如果用户需要 在备份中的隐私，他们可以在备份之前加密文件 并管理这种复杂性
- 将chkfs存储在"不寻常"或旧文件系统上：设计 用于存储旧文件系统内容，但不用于存储 旧文件系统。特别是，chkstore和chkfs采用目录 可以保存许多条目，名称至少在80 ascii左右 字节长。（他们目前还假设存储文件系统 支持有效提交的硬链接，以及 避免多进程冲突。）
未来用例：
- 一个只读保险丝接口，可方便地从chkfs中恢复。
附加用例：
- 作为后端集成到其他网络/分散数据存储中 如Camlistore或Tahoe Lafs.
- 为什么不是cp-a或cp-r？
- 这在某些方面是有损失的，而chkfs不是：vfs元数据 关于源文件没有被复制，源文件系统可能有 不能存储在目标文件系统中的元数据（包括 不同的文件名编码问题）。chkfs也遭受了一些 依赖vfs层读取源代码的这些限制 文件系统。同时也牺牲了 作为文件系统直接可用的备份文件（没有 熔丝接口），所以chkfs失去了运行find grep的能力， 例如。
- 为什么不使用tar或许多现有的非常成熟的unix备份系统呢？
- 我知道的"老派"解决方案并不支持所有 以上使用案例没有过度头痛。权衡是 老派的解决方案在 环境和广泛可用。
- 为什么不使用camlistore、tahoe lafs、freenet或分散存储
科技X？
- 我不需要分散个人备份。没有必要 用于网络、冗余或信任边界复杂性。（见 不支持的功能部分。）
- 为什么不使用bup或其他更擅长重复数据消除的方案呢？
- 如前所述，chkfs更喜欢"相当透明"的商店。 应该可以在不使用此工具的情况下恢复备份，但是 仅限BZIP2、CP、VIM等。
欢迎加入QQ群-->： 979659372
