概述

file:https://img.shields.io/codecov/c/gitlab/asuran-rs/libasuran.svg?style=for-the-badge file:https://img.shields.io/gitlab/pipeline/asuran-rs/libasuran.svg?style=for-the-badge file:https://img.shields.io/crates/v/libasuran.svg?style=for-the-badge file:https://img.shields.io/crates/l/libasuran.svg?style=for-the-badge

Asuran是一种新的存档格式，同时也是一个读/写库以及命令行工具的实现（用Rust编写）。

特性概述

去重

去重是通过内容定义的切片和内容寻址存储的组合实现的。CAS后端将只存储提交给它的每个块一次。内容定义的切片提供了一种合理的保证，即对象将被分割成块，如果可能的话，将发生重复的块，而不会存储两次。

加密

加密后端是可插拔的，并且可以按块逐块更改。更改默认加密将仅更改新块的加密方法。

每个块都被加密，然后与一个标签一起放入对象中，该标签指示使用的加密算法，如果算法需要，还包括IV。

密钥生成和存储

加密和HMAC使用的密钥在创建存储库时随机生成，并以从用户提供的密码短语派生的密钥加密存储在磁盘上。当前使用的KDF是bcrypt，但将来很可能会用更现代的argon2id替换。

压缩

压缩后端是可插拔的，支持多种压缩算法。压缩在加密之前进行，每个块都标记了用于压缩它的压缩算法[1]。

待办事项 智能压缩

Asuran将支持（但当前不支持）智能加密，其中它将对文件的第一个或几个块进行试验压缩，使用lz4，如果检测到合理的压缩，则使用所选的压缩算法压缩文件的块，否则不进行压缩。

认证

存储库中存储的所有数据都通过加密后MAC构建进行认证，目前支持HMAC-SHA256和Blake2b。如果HMAC未通过验证，Asuran将坚决拒绝解包块。

由CAS使用的密钥内容是通过使用明文的HMAC生成的，使用与用于验证的HMAC不同的密钥。目前这些密钥尚未进行验证。

开发过程/贡献

由于目前只有我在进行开发，当前的开发模式结构并不严谨。未来它将采用按功能分支的模式，分支在被合并到master之前需要通过一组最低测试要求。

欢迎提交拉取请求和问题，并且通过为该项目做出贡献，您同意将您的作品许可在MIT许可证下。

路线图

0.1.0

版本0.1.0应该是一个可以使用的产品。它仍然只能以追加模式运行，但将支持多种加密、压缩和HMAC算法类型。它还将有一个初步稳定的磁盘格式。仓库应能够作为一个专用的操作来验证自身。文件系统目标应正确处理稀疏数据。

1. 待办事项 libasuran

   libasuran 0.1.0应具备以下功能

   • 相对稳定的磁盘格式
   • 支持zlib、lzma和lz4压缩
   • 支持chacha20-poly1305加密
   • 应该有cargo基准测试
   • 应该有一个工作稀疏数据API
   • 应该有一个验证仓库完整性的方法

2. 待办事项 asuran

   asuran 0.1.0应具备以下功能

   • 支持设置压缩类型/级别
   • 支持设置加密类型
   • 支持设置HMAC算法
   • 运行时测试/基准
   • 仓库验证命令

0.2.0

使命声明

asuran归档格式的设计，按照重要性排序

适合长期归档

asuran应该是一个你可以永远保存数据的格式。一旦发布达到0.1.0，格式的任何重大更改都应避免在正向方向上丢失数据，始终提供静态链接的二进制工具，可以在两种格式之间进行归档转换，并且始终提供关于无法保留向前方向的结构/功能的详尽文档。

格式版本应得到良好记录，有易于访问的纯文本文档，以便将纯文本副本存储在重要仓库旁边，足以让未来的工程师在无需访问现有的asuran实现的情况下恢复仓库。

应提供长期归档功能，如可选的校验和数据以防止位错误，以及通过重写每个段来进行内置的本地刷新。

安全

asuran应该充分利用加密和其他加密技术，为用户提供隐私保证。由于可以在不受信任的存储上托管，asuran无法完全防止数据篡改，但应尽可能免受非破坏性篡改（即攻击者向归档中添加新文件），并且能够检测并拒绝被破坏性篡改的归档（即攻击者删除或修改仓库中的文件）。

灵活

asuran不应在存储库中存储的内容或结构上施加任何任意限制，也不应仅限于传统的文件系统抽象。应将替代数据布局，如照片库、电子邮件收件箱和SQL数据库转储视为一等公民。

快速

libasuran应该能够在开启加密和合理压缩的情况下轻松饱和普通消费级桌面上的1Gig以太网端口，或在中等至高端服务器上的10Gig以太网端口。当然，假设libasuran不会超过存储。

易于嵌入

圆锥形Asuran实现（简称Asuran）应该吃自己的狗粮，通过libasuran来执行所有非平凡的仓库操作。libasuran应该提供一个良好文档化和一致的API来与仓库交互，并且应该有一个良好维护和彻底文档化的C FFI，至少与Python绑定。

灵感/动机

本项目受到Borg和Restic的启发。这两者都是非常好的软件，非常适合许多用例，但我的用例似乎介于两者之间。

在许多方面，这个项目旨在结合我认为这两个应用程序最好的特性，同时尝试制作一个可修改和可扩展的框架，可以轻松嵌入到其他应用程序中。

Borg拥有的而Restic缺失的特性

• Borg的性能通常比Restic好得多，在我的工作负载中，我发现这令人不安。
• 可选/可切换加密不要误会，能够在不受信任的存储上安全存储敏感数据真的很不错，但有时你确实是在备份到受信任的存储（例如，在文件系统或驱动器级别已经加密的外部硬盘），双重加密只是额外的开销。
• 可选/可切换压缩Restic完全不支持压缩，这在我的看法中，使它对于许多工作负载来说不可行。

Restic拥有的而Borg缺失的特性

• 可切换存储后端这一点对我来说非常重要。作为一个家庭游戏玩家，能够直接将我庞大的文件备份到无限制的GDrive或类似的服务是一个巨大的优势。这也是我为什么使用Restic进行一些备份的唯一原因。
• 多台计算机写入同一仓库Borg的仓库锁定和块缓存机制使得多台计算机写入同一仓库变得非常痛苦。没有所有计算机都备份到同一仓库将大大降低去重率，而且总体来说并不好。

两者都没有的特性

• Tar导入和导出

这并不完全正确，因为Borg已经有了tar导出并且正在开发tar导入，但它缺少一个对我的工作流程至关重要的特性，即重现相同的tar文件。我的工作流程涉及到一个产生备份为tar文件的程序，当恢复时，会查找必须位于tar文件第一个的特殊文件。我想要能够导入和导出tar，并保持tar的元数据相同，同时仍然能够将tar拆分并去重其中的单个文件，并使用仓库定义的压缩。

• 良好的多线程

  虽然Borg是基于Python的，并不真正使用线程，但Restic支持多线程，但在我看来，它并没有很好地使用它。

与rdedup的比较

rdedup是一个非常不错的工具，但在几个方面对我来说都不够好。

• 没有内置的目录遍历

  rdedup依赖于外部工具（如tar）来制作备份。在我的经验中，这使去重率比Borg在我的工作流程中要低。

• 没有对云后端的当前支持

  这一点几乎可以说是作弊，因为Asuran目前没有对云后端的支持，但Asuran是从一开始就被设计成存储无关的。

• 没有智能分块

  rdedup在从几个好的内容定义切片器中进行选择方面有很好的支持，但缺乏对已知数据类型（如按块分割的磁盘镜像或智能拆分其他应用程序生成的备份以最大程度地提高去重）进行智能切片的框架。

• 几乎没有集成支持

  此投诉在一定程度上也适用于borg和restic，但程度较小。libasuran被设计为可以从其他应用程序中调用，例如碳素风格的自动备份工具，允许轻松创建支持asuran完整功能的用户友好的应用程序。

链接

• 项目网站
• Asuran矩阵聊天室

脚注

1. 使用的压缩级别也包含在此标签中，无论是否需要。