Restic原理分析

左丘恩

2023-12-01

创建存储库

初始化存储库（本地）

restic init --repo ./restic_repo

回车后，需要输入密码

enter password for new repository:
enter password again:
created restic repository 56f6f17938 at ./restic_repo

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

查看生成的目录结构

.
├── config
├── data
│   ├── 00
│   ├── 01
│   ├── 02
......
│   ├── fd
│   ├── fe
│   └── ff
├── index
├── keys
│   └── a1147718095f6ecc356caaae676932f78159a8332bf6ea36aed5ff4763205042
├── locks
└── snapshots

261 directories, 2 files

data目录结构

此时生成了restic存储库的结构，从目录结构上可以很清楚的和设计原理对应。在data目录下，根据十六进制从00一直生成到ff个目录，用于blob的存储。

config文件

由于config采用加密方式存储，无法直接查看，需要使用restic命令查看具体内容。

restic cat -r restic_repo config

输出结果为

repository 56f6f179 opened successfully, password is correct
{
  "version": 1,
  "id": "56f6f17938d86e6a4718d8d5a31ea6503a8bf24606e022c4ac2c2aae75ed52e2",
  "chunker_polynomial": "25fe60909e1433"
}

根据restic设计原理，初始化后版本为1，id为存储库的唯一ID，chunker_polynomial字段包含一个参数，用于将大文件分割成更小的块。

keys目录

而文件部分，在初始化的结构上只存在keys下的文件和config两个文件。其中config文件为加密存储，而keys文件是明文存储，可以直接查看。

python -mjson.tool restic_repo/keys/a1147718095

格式化输出内容为：

{
    "created": "2022-03-23T10:31:42.819697576+08:00",
    "username": "root",
    "hostname": "ray-dev",
    "kdf": "scrypt",
    "N": 8192,
    "r": 8,
    "p": 11,
    "salt": "aziDQSzuuAet1SPMaEcgSLphDb9UyLZ8D/mry7QBMbnL60LTU/sjwXXEctGQNIATe6XeAy+Lgojcej7CV959Gg==",
    "data": "YCG8jYsnxaj2YyF5jc82q7mWPF6YsNNbhISXrsZGab7bsMlFe/dBPbnCUzyigac73cMFdirzrb2n9was+0wcGiTc3TIdQ9op5sbgaqAaCRHzR28zDjq/6b8PCl39rDm0fhwSPT+TrvJ8d9EX7FcnxIltJ2Xio4dsnHmr+2KxIyXhAyPaad4KEDKiTZEhtdw+dorofFB1aDKiTYBysRW1RA=="
}

当打开restic存储库时，会提示用户输入存储库密码。然后将其与 scrypt、密钥派生函数 (KDF) 和提供的参数（N、r、p 和salt）一起派生64个密钥字节。前32个字节用于加密密钥（用于 AES-256），最后32个字节用作消息验证密钥（用于 Poly1305-AES）。这最后32个字节被分成一个16字节的AES密钥“k”，然后是16个字节的密钥“r”。然后将密钥r屏蔽，与 Poly1305 一起使用（有关详细信息，请参阅论文）。

这些消息身份验证密钥（k 和 r）用于计算MAC，使用 JSON 中 data字段包含的字节（在删除 Base64 编码并且不包括最后32个字节之后）。如果密码不正确或密钥文件被篡改，则计算出的 MAC将与数据的最后 16 个字节不匹配，restic 会报错退出。否则，将使用从scrypt派生的加密密钥解密数据。这将生成一个JSON，其中包含此存储库的主加密和消息鉴权密钥（以 Base64 编码）。

restic cat masterkey -r restic_repo

查看信息

repository 56f6f179 opened successfully, password is correct
{
  "mac": {
    "k": "DLMpuMFKlvonh3rpul5yMQ==",
    "r": "DU06C/h5Jg+UAzoLuBsRDA=="
  },
  "encrypt": "H6tU0t5Sbo5hjux3kj9BapWtEqIo63UyyBhcbwBnP+M="
}

存储库中的所有数据都使用这些主密钥进行加密和验证。对于加密，使用计数器模式下的 AES-256 算法。对于消息认证，如上所述使用 Poly1305-AES。

存储库可以有多个不同的密码，每个密码都有一个密钥文件。这样，无需重新加密所有数据即可更改密码。

小文件备份

为了测试方便，我们创建一个文本类型文件，该文件只包含一个字符，例如0。

cat demo.txt

内容如下：

查看文件的大小：

stat demo.txt

输出为：

File: ‘demo.txt’
  Size: 2             Blocks: 8          IO Block: 4096   regular file
Device: 803h/2051d    Inode: 878940853   Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-03-23 14:39:15.857514408 +0800
Modify: 2022-03-23 14:39:13.157444776 +0800
Change: 2022-03-23 14:39:13.157444776 +0800
 Birth: -

此时我们的目录结构为

source_dir
└── demo.txt

0 directories, 1 file

我们使用restic进行备份

restic -r restic_repo --verbose backup source_dir/demo.txt

输入正确的密码后备份成功

repository 56f6f179 opened successfully, password is correct
lock repository
load index files
no parent snapshot found, will read all files
start scan on [source_dir/demo.txt]
start backup on [source_dir/demo.txt]
scan finished in 0.204s: 1 files, 2 B

Files:           1 new,     0 changed,     0 unmodified
Dirs:            1 new,     0 changed,     0 unmodified
Data Blobs:      1 new
Tree Blobs:      2 new
Added to the repo: 750 B

processed 1 files, 2 B in 0:00
snapshot 6ca52f2f saved

此时，我们回到restic存储库中来检查一下文件增加的情况，为了方便查看，我用git将初始化的信息进行了commit，这样就能看到本次备份后的文件变化情况。

23 data/62/62f89d280ebdf875ef6f0d12e4d90d0e807a48506e60064ecb4d58a2c733177a
23 data/b3/b3346e2e87eee7a8d1a17052ce1d1d09784c072b949205f3c632dd503b867096
549 index/701f1ff24a647a51ebfadfaf973721075b62819408f3ac647e7a757e147de059
251 snapshots/6ca52f2f0978fbcfa16fdade23b2f20ba4f5a4a71882bb63cc0d4bec2970161a

我们来分析一下文件的变化情况，我们发现在data目录下增加了两个文件，而index和snapshots下分别增加了一个文件。

包（Packs）

很明显restic在存储文件时是根据文件名称前两位决定将文件存放在哪个目录下，比如62f89d280ebdf875ef6f0d12e4d90d0e807a48506e60064ecb4d58a2c733177a就存放在data/62下面。

在data目录下增加的两个文件就是restic的包，我们通过list命令可以查询存储库中包的列表

restic -r restic_repo list packs

返回所有包的信息，与目录中的内容对应

62f89d280ebdf875ef6f0d12e4d90d0e807a48506e60064ecb4d58a2c733177a
b3346e2e87eee7a8d1a17052ce1d1d09784c072b949205f3c632dd503b867096

虽然在cat中提供了查看pack内容，但是由于加密的原因，无法查看其中的内容，与直接执行cat返回内容一致

索引

查看index情况，和snapshots一样使用目录下的id进行查询

restic -r restic_repo cat index 701f1ff24a647a51ebfadfaf973721075b62819408f3ac647e7a757e147de059 | python -mjson.tool

通过返回数据，我们可以看到packs与blobs的对应关系，通过返回，我们可以得知pack 62f89d280ebdf875ef6f0d12e4d90d0e807a48506e60064ecb4d58a2c733177a中包含的是实际数据，而另外一个pack包含的则是tree，即目录结构，虽然原理文档对于offset和length的计算有介绍，但是单从描述的方式上还不足以理解，需要对源码进行分析。

{
    "packs": [
        {
            "id": "62f89d280ebdf875ef6f0d12e4d90d0e807a48506e60064ecb4d58a2c733177a",
            "blobs": [
                {
                    "id": "9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa",
                    "type": "data",
                    "offset": 0,
                    "length": 34
                }
            ]
        },
        {
            "id": "b3346e2e87eee7a8d1a17052ce1d1d09784c072b949205f3c632dd503b867096",
            "blobs": [
                {
                    "id": "5dbab6dedd6e621d742e9e2327e8e8da6198ed188321d68b6cc5ec1dc9ebafc2",
                    "type": "tree",
                    "offset": 405,
                    "length": 407
                },
                {
                    "id": "e8a97749d4bdd53506bd5979dec630d8606cc98e46ed6c07432242592382b322",
                    "type": "tree",
                    "offset": 0,
                    "length": 405
                }
            ]
        }
    ]
}

Blob

我们进一步通过cat blob命令进行查询，我们先来查看数据类型

restic -r restic_repo cat blob 9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa

返回的结果就是我们的实际内容

我们再来查看tree类型

restic -r restic_repo cat blob 5dbab6dedd6e621d742e9e2327e8e8da6198ed188321d68b6cc5ec1dc9ebafc2 | python -mjson.tool

此时，返回的是我们的第一级目录

{
    "nodes": [
        {
            "name": "source_dir",
            "type": "dir",
            "mode": 2147484141,
            "mtime": "2022-03-23T14:39:13.157444776+08:00",
            "atime": "2022-03-23T14:39:13.157444776+08:00",
            "ctime": "2022-03-23T14:39:13.157444776+08:00",
            "uid": 0,
            "gid": 0,
            "user": "root",
            "group": "root",
            "inode": 878936120,
            "device_id": 2051,
            "content": null,
            "subtree": "e8a97749d4bdd53506bd5979dec630d8606cc98e46ed6c07432242592382b322"
        }
    ]
}

这里包含subtree，就是我们的子目录，我们进一步查询

restic -r restic_repo cat blob e8a97749d4bdd53506bd5979dec630d8606cc98e46ed6c07432242592382b322 | python -mjson.tool

此时content的内容指向了数据blob 9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa，即我们的文件内容

{
    "nodes": [
        {
            "name": "demo.txt",
            "type": "file",
            "mode": 420,
            "mtime": "2022-03-23T14:39:13.157444776+08:00",
            "atime": "2022-03-23T14:39:13.157444776+08:00",
            "ctime": "2022-03-23T14:39:13.157444776+08:00",
            "uid": 0,
            "gid": 0,
            "user": "root",
            "group": "root",
            "inode": 878940853,
            "device_id": 2051,
            "size": 2,
            "links": 1,
            "content": [
                "9a271f2a916b0b6ee6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa"
            ]
        }
    ]
}

快照

再来查看一下snapshots的情况，直接使用snapshots下面的6ca52f2f0978fbcfa16fdade23b2f20ba4f5a4a71882bb63cc0d4bec2970161a进行查询

restic -r restic_repo cat snapshot 6ca52f2f0978fbcfa16fdade23b2f20ba4f5a4a71882bb63cc0d4bec2970161a

从返回的数据看，snapshots指向了tree，而tree实质上就是最顶层的目录blob

{
  "time": "2022-03-23T14:44:52.064414778+08:00",
  "tree": "5dbab6dedd6e621d742e9e2327e8e8da6198ed188321d68b6cc5ec1dc9ebafc2",
  "paths": [
    "/root/workspace/restic_test/source_dir/demo.txt"
  ],
  "hostname": "ray-dev",
  "username": "root"
}

从以上一个备份过程上，我们不难理解restic是如何进行的备份，那么我们再来测试一下，当达到restic对blob文件进行切割后，如何进行的存储。

大于8MB文件备份

根据原理文档描述，restic针对512 KB以下文件不切分，对于512KB到8MB的文件会保留原有大小，只有大于8MB才会切分，所以我们构建一个10MB文件，为了便于后续观察，我们按照递增方式从1向上增加，每一行为一个数字，即

使用如下命令生成

for i in {1..1450000}; do echo $i; done > 10mb_file.txt

直接对文件进行备份

restic -r restic_repo --verbose backup source_dir/10mb_file.txt

输出详情为

repository 56f6f179 opened successfully, password is correct
lock repository
load index files
no parent snapshot found, will read all files
start scan on [source_dir/10mb_file.txt]
start backup on [source_dir/10mb_file.txt]
scan finished in 0.206s: 1 files, 10.003 MiB

Files:           1 new,     0 changed,     0 unmodified
Dirs:            1 new,     0 changed,     0 unmodified
Data Blobs:      6 new
Tree Blobs:      2 new
Added to the repo: 10.004 MiB

processed 1 files, 10.003 MiB in 0:00
snapshot 9b965346 saved

通过输出可以看到：restic发现了一个新的文件，同时生成了6个新的数据Blobs，其中Tree Blobs为2个。通过观察restic repo内的文件变化情况，没有文件被修改，新增了6个文件（无修改文件）：

1.3K ****data/34/347f0dd64113d6fd4cc47dc085405fbff605e942a7a18f92c77aab0bd480e069
3.0M data/ab/ab69b131e8262286a726f65b12462657259961a58ca7adbac480321e9a091565
3.0M data/be/be1e14a1ec2b41ea3e7d02ab985ff99e764a8f5de6c13aaac6ba9180f5ce81cd
4.2M data/be/be4b589501ccd0c6da460659faf5db477b541e6fb46bf5909af5927b03f19ca8
1.3K index/d40932add8acb5cfdd1deae551d59a85deab190b55a578243860fbf71aeb08d0
255 snapshots/9b9653468c30e7943f5d068c2a0210069eab03ca56d8b787c2883be06be2b116

从输出的结果上来看，本次生成的文件中snapshots文件与第一次备份一致，因为仅仅指向blob，所以文件大小没有显著增加，而index文件则比之前大了一倍，从549直接增加到1.3K。

索引

我们仍然通过命令，查看一下索引内的变化情况

restic -r restic_repo cat index d40932add8acb5cfdd1deae551d59a85deab190b55a578243860fbf71aeb08d0 | jq

从生成的结果来看，与备份的标准输出相对应，index文件中总共包含了6个Blobs，其中四个为数据型，两个为目录型，我们直接对数据型blobs进行分析，看看restic是如何对文件进行的拆分。

{
  "packs": [
    {
      "id": "be1e14a1ec2b41ea3e7d02ab985ff99e764a8f5de6c13aaac6ba9180f5ce81cd",
      "blobs": [
        {
          "id": "df59490249716895dd8b67dfe4af369f21dde033b51489ab4ccb3af5d064e65f",
          "type": "data",
          "offset": 0,
          "length": 708813
        },
        {
          "id": "6e837f4efe3effa79c1db760a83dc4a4ed9e8feb0a03d0c3358612248fd6bfd6",
          "type": "data",
          "offset": 708813,
          "length": 2344049
        }
      ]
    },
    {
      "id": "ab69b131e8262286a726f65b12462657259961a58ca7adbac480321e9a091565",
      "blobs": [
        {
          "id": "7d2fc5c4b2b7d183c94460eb6418a4b3a8898d769951281708cf7cf430f99dcd",
          "type": "data",
          "offset": 0,
          "length": 1482607
        },
        {
          "id": "d20d76c1a8e128707d094207f63d3e54bdd34c2f7dbb9bef19bfba9b408232cc",
          "type": "data",
          "offset": 1482607,
          "length": 1616191
        }
      ]
    },
    {
      "id": "be4b589501ccd0c6da460659faf5db477b541e6fb46bf5909af5927b03f19ca8",
      "blobs": [
        {
          "id": "2df049910612d58b07727115601f8a2bf6412ebc036d087a233d26d677290415",
          "type": "data",
          "offset": 1837173,
          "length": 2500255
        },
        {
          "id": "5e137b93f71fca42a5710a5b7e16c75d75c0c4b63b8bc8aab8f334a34c65b4ae",
          "type": "data",
          "offset": 0,
          "length": 1837173
        }
      ]
    },
    {
      "id": "347f0dd64113d6fd4cc47dc085405fbff605e942a7a18f92c77aab0bd480e069",
      "blobs": [
        {
          "id": "005bdcba00bd7ad8f1aa1f7db1aaa8b8539f1839061c40709a519de1b25e4b89",
          "type": "tree",
          "offset": 0,
          "length": 752
        },
        {
          "id": "067835a81002764d000d0e2dd36ea942d9ef176586d80a03878c373777608958",
          "type": "tree",
          "offset": 752,
          "length": 404
        }
      ]
    }
  ]
}

Blob

我们分别对每个Blob进行cat查询，可以清楚看到每一个文件切分的位置，这里不再赘述，这里只列出切割的位置(根据上面输出索引的顺序)，及Blob对应的id。

Blob ID	文件起始行	结尾
df59490249716895dd8b67dfe4af369f21dde033b51489ab4ccb3af5d064e65f	824978	92#
6e837f4efe3effa79c1db760a83dc4a4ed9e8feb0a03d0c3358612248fd6bfd6	1	35073#
7d2fc5c4b2b7d183c94460eb6418a4b3a8898d769951281708cf7cf430f99dcd	181
613182	824977#
d20d76c1a8e128707d094207f63d3e54bdd34c2f7dbb9bef19bfba9b408232cc	6232
926233	1137472
1#
2df049910612d58b07727115601f8a2bf6412ebc036d087a233d26d677290415	137473
1137474	1450000
5e137b93f71fca42a5710a5b7e16c75d75c0c4b63b8bc8aab8f334a34c65b4ae	2
350733	613180
613#

从输出结果来看，我们不难看到restic切割的痕迹和每个Blob的关系，那么restic又是如何管理其中的顺序呢？答案就是最后subtree的contents字段。

最后，我们来通过查看子树的信息来观察contents的排列。

restic -r restic_repo cat blob 005bdcba00bd7ad8f1aa1f7db1aaa8b8539f1839061c40709a519de1b25e4b89 | jq

通过观察contents的排列顺序恰好是我们上述表格内正确的顺序，这样在还原备份时，restic就可以对文件进行重组。

{
  "nodes": [
    {
      "name": "10mb_file.txt",
      "type": "file",
      "mode": 420,
      "mtime": "2022-03-24T07:00:32.751188252+08:00",
      "atime": "2022-03-24T07:00:32.751188252+08:00",
      "ctime": "2022-03-24T07:01:26.38858041+08:00",
      "uid": 0,
      "gid": 0,
      "user": "root",
      "group": "root",
      "inode": 1377358062,
      "device_id": 2051,
      "size": 10488896,
      "links": 1,
      "content": [
        "6e837f4efe3effa79c1db760a83dc4a4ed9e8feb0a03d0c3358612248fd6bfd6",
        "5e137b93f71fca42a5710a5b7e16c75d75c0c4b63b8bc8aab8f334a34c65b4ae",
        "7d2fc5c4b2b7d183c94460eb6418a4b3a8898d769951281708cf7cf430f99dcd",
        "df59490249716895dd8b67dfe4af369f21dde033b51489ab4ccb3af5d064e65f",
        "d20d76c1a8e128707d094207f63d3e54bdd34c2f7dbb9bef19bfba9b408232cc",
        "2df049910612d58b07727115601f8a2bf6412ebc036d087a233d26d677290415"
      ]
    }
  ]
}

小文件修改后备份

在本次备份前，先来尝试修改小文件，我们将原有小文件的内容从0变为1，进行备份。

restic -r restic_repo --verbose backup source_dir/demo.txt

此时restic发现有一个文件进行了改变，增加了一个Data Blob，增加了746字节

repository 56f6f179 opened successfully, password is correct
lock repository
load index files
using parent snapshot 6ca52f2f
start scan on [source_dir/demo.txt]
start backup on [source_dir/demo.txt]
scan finished in 0.219s: 1 files, 2 B

Files:           0 new,     1 changed,     0 unmodified
Dirs:            0 new,     1 changed,     0 unmodified
Data Blobs:      1 new
Tree Blobs:      2 new
Added to the repo: 746 B

processed 1 files, 2 B in 0:00
snapshot 4e2aa2b0 saved

我们看一下存储库内的实际变化情况，虽然只修改了一个字符，但是restic存储库增加了1901个字节。

107 data/30/30b15f86b4797676aa3b15b7b39094887fa5ebc23faeb0005a1de3db3cb5a99e
918 data/b8/b83c8903968a1754a4b935937c80588ca6415bc765b3ac67da3c1b5d99181545
549 index/35a11e5dfa5a4dd5a94ef7865993161e637c6e594b945b91a819c2cbbad5437f
327 snapshots/4e2aa2b01e6c253bff413e80c4838338342eb3cdf21adaee6399e0d196efef24

因为存储库的变化情况与上述相似，这里不再赘述。

大文件修改后备份

我们接下来看看如果是大文件变化，restic的同步情况，我们将我们构造的10MB文件的第一行进行从1修改为a。

restic -r restic_repo --verbose backup source_dir/10mb_file.txt

输出内容，增加了一个1个新的数据blob，增加容量为2.236MB。

repository 56f6f179 opened successfully, password is correct
lock repository
load index files
using parent snapshot 3568a27c
start scan on [source_dir/10mb_file.txt]
start backup on [source_dir/10mb_file.txt]
scan finished in 0.208s: 1 files, 10.003 MiB

Files:           0 new,     1 changed,     0 unmodified
Dirs:            0 new,     1 changed,     0 unmodified
Data Blobs:      1 new
Tree Blobs:      2 new
Added to the repo: 2.236 MiB

processed 1 files, 10.003 MiB in 0:00
snapshot 7505e3f0 saved

看一下存储库的实际变化情况，增加的总大小大约为2.3MB。

2.3M data/b0/b0b147233fd6514fa14229231aa346bb321698e091fd5d2ca2aeb39590d96180
1.3K data/ed/edbf5390498ef9459e359eff4c03da82ee46c1f302a7ef6ec7410af25c825ae1
554 index/10001235dbd9f406ae7bd4030ad3feaf7dbdcddc32da05c125371a0780c578aa
332 snapshots/7505e3f009775ad74c00ca09aa57a854957d7f761a14e72ecd0d5fef9d7e9623

我们再将第100行，修改为aaa。我们看到在同一blob内，每次修改同步的大小是一样的。

repository 56f6f179 opened successfully, password is correct
lock repository
load index files
using parent snapshot 7505e3f0
start scan on [source_dir/10mb_file.txt]
start backup on [source_dir/10mb_file.txt]
scan finished in 0.205s: 1 files, 10.003 MiB

Files:           0 new,     1 changed,     0 unmodified
Dirs:            0 new,     1 changed,     0 unmodified
Data Blobs:      1 new
Tree Blobs:      2 new
Added to the repo: 2.236 MiB

processed 1 files, 10.003 MiB in 0:00
snapshot 98f81417 saved

如果我们增加行数会发生什么呢？根据blob的分割记录，我们大概追加30000行到文件内，此时文件大小情况为

File: ‘10mb_file.txt’
  Size: 10657790      Blocks: 53248      IO Block: 4096   regular file
Device: 803h/2051d    Inode: 1377358062  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-03-24 15:05:36.102065592 +0800
Modify: 2022-03-24 15:11:54.259081906 +0800
Change: 2022-03-24 15:11:54.259081906 +0800
 Birth: -

本次同步后，可能是未达到边界值，所以同步的大小为2.5MB左右。

repository 56f6f179 opened successfully, password is correct
lock repository
load index files
using parent snapshot 98f81417
start scan on [source_dir/10mb_file.txt]
start backup on [source_dir/10mb_file.txt]
scan finished in 0.214s: 1 files, 10.164 MiB

Files:           0 new,     1 changed,     0 unmodified
Dirs:            0 new,     1 changed,     0 unmodified
Data Blobs:      1 new
Tree Blobs:      2 new
Added to the repo: 2.547 MiB

processed 1 files, 10.164 MiB in 0:00
snapshot 84bb70fa saved

总结

通过以上使用测试，首先我们应该了解restic的目录管理逻辑

index目录下的文件记录了每一次备份的完整组织结构，指向packs
snapshots则直接指向了最顶层的blob
data目录中的id是packs id，而packs中可能包含多个blob
blob包含tree和data两种类型，blob记录了大量与文件有关的metadata信息

本文由博客一文多发平台 OpenWrite 发布！

Restic原理分析

创建存储库

data目录结构

config文件

keys目录

小文件备份

包（Packs）

索引

Blob

快照

大于8MB文件备份

索引

Blob

小文件修改后备份

大文件修改后备份

总结

相关阅读

相关文章

相关问答

相关文档