☰

使用 tar 进行增量备份，其中当前文件具有最新版本，而先前文件仅具有不同版本

tag-icon • tag-icon linux backup tar
使用 tar 进行增量备份，其中当前文件具有最新版本，而先前文件仅具有不同版本

我有点熟悉如何使用tar的--listed-incremental标志进行增量备份。最终结果是backup-0文件具有第一个完整备份，然后是backup-1、backup-2、...，backup-x并按备份顺序进行更改。

过去，我曾使用rsync硬链接来备份backup-0当前状态，并且每个backup-x文件夹都有特定于该备份的文件。基本上概述如下http://www.mikerubel.org/computers/rsync_snapshots/和http://www.admin-magazine.com/Articles/Using-rsync-for-Backups/(偏移)。

我想用 tar 模拟该功能。我不能使用硬链接，因为 tar 文件最终将被上传到不维护/不理解链接等的云提供商。我还想将备份打包成 tar，因为我还可以在将它们上传到云之前对其进行加密。

因此，我们的想法是拥有一个不断增长的文件列表，如下所示：

  • backup-0.tar.bz2- 这是当前备份，也是最大的备份，因为它是完整备份
  • backup-1.tar.bz2- 这是昨天的备份，但它只包含与当前备份不同的文件（backup-0.tar.bz2）
  • backup-2.tar.bz2- 这是两天前的备份，但它只包含与昨天不同的文件（backup-1.tar.bz2）
  • backup-3.tar.bz2-...
  • backup-4.tar.bz2-...
  • backup-5.tar.bz2-...

如果这没有意义的话，希望这个有意义。

第一次：

  1. $ touch /tmp/file1
  2. $ touch /tmp/file2
  3. 制作backup-0.tar.bz2

此时backup-0.tar.bz2有/tmp/file1和/tmp/file2。

第二次：

  1. $ touch /tmp/file3
  2. $ rm /tmp/file2
  3. ..施展魔法

在此刻：

  • backup-0.tar.bz2有/tmp/file1和/tmp/file3
  • backup-1.tar.bz2有/tmp/file2；它没有，file1因为它没有改变，所以它在backup-0.tar.bz2

第三次：

  1. $ touch /tmp/file1
  2. $ touch /tmp/file4
  3. ..施展魔法

在此刻：

  • backup-0.tar.bz2有/tmp/file1，，/tmp/file3和/tmp/file4
  • backup-1.tar.bz2因为/tmp/file1它被改变了
  • backup-2.tar.bz2有/tmp/file2

就像这样：

|       | first time | second time | third time              |
|-------|------------|-------------|-------------------------|
| file1 | backup-0   | backup-0    | backup-0 and   backup-1 |
| file2 | backup-0   | backup-1    | backup-2                |
| file3 |            | backup-0    | backup-0                |
| file4 |            |             | backup-0                |

我认为这是一种解决方法，但对我来说效率太低了。也许我可以使用一些功能/标志来提高效率。

  1. 第一次=采取backup-0
  2. 第二次
    1. 重命名backup-0为backup-1
    2. 拿backup-0
    3. 删除backup-1匹配的所有内容backup-0
  3. 第三次
    1. 重命名backup-1为backup-2
    2. 重命名backup-0为backup-1
    3. 拿backup-0
    4. 删除backup-1匹配的所有内容backup-0
  4. 第四次
    1. 重命名backup-2为backup-3
    2. 重命名backup-1为backup-2
    3. 重命名backup-0为backup-1
    4. 拿backup-0
    5. 删除backup-1匹配的所有内容backup-0

我觉得最后一步（从backup-1匹配中删除所有内容backup-0）效率低下。

我的问题是，我该怎么做？如果我使用tar's，--listed-incremental它将执行与我尝试的操作相反的操作。

答案1

如果我使用tar，--listed-incremental它将执行与我尝试的操作相反的操作。

你能意识到这一点真好。我能看到这两种方式的优点和缺点（我不会在这里讨论它们）。从技术上讲，可以逆转这个过程：

  1. 重命名backup-N为backup-(N+1)从 N max循环到 0。
  2. 将完整备份（现在backup-1）恢复到临时目录。
  3. backup-0使用当前数据创建新的快照文件。
  4. 删除backup-1（以前的完整备份）。
  5. 将临时目录视为“新”版本。创建backup-1增量备份，提供上一步的快照文件。（请注意，您需要将工作目录从包含当前数据的目录更改为临时目录，因此相对路径保持不变）。

您可能想知道这是否会使旧（保留）backup-N文件与新文件保持一致。这是合理的怀疑，因为手册上说：

-g，--listed-incremental=FILE
处理新的 GNU 格式增量备份。FILE是快照文件的名称，其中tar存储了附加信息，这些信息用于确定自上次增量转储以来哪些文件发生了变化，因此必须再次转储。 如果FILE在创建存档时不存在，则会创建它并将所有文件添加到生成的存档（级别0转储）中。 要创建非零级别的增量存档N，请创建在级别期间创建的快照文件的副本N-1，并将其用作FILE。

因此建议快照文件应一直更新从完整备份，就好像每次执行完整备份时都需要重建backup-N文件一样。但是：

在列出或提取时，不会检查 的实际内容FILE，只是出于语法要求才需要它。因此，通常使用 来/dev/null代替它。

这意味着如果您backup-N按递增顺序提取文件以获取某个时间之前的状态，则任何backup-M文件 (M>0) 仅期望M-1存在有效状态。无论此状态是从完整备份还是增量备份中获得，关键是这些状态无论如何都应该相同。因此，无论您是backup-M基于完整备份（您将这样做，每个备份都将以完整备份的位置backup-M开始）还是基于增量备份链（如手册所示）创建文件，这都无关紧要。backup-1backup-0

我明白你的观点是保留backup-0最新的完整备份，并能够“回到过去” backup-0，，，，…如果你想将这些文件保存在“愚蠢的”云服务中，你需要根据程序仔细重命名它们，每次都替换并上传一个全新的。如果你的数据很大，那么backup-1上传backup-2backup-1backup-0每次都进行完整备份将会很痛苦。

因此，建议使用“智能”服务器，每次上传“过去到现在”的增量备份时，该服务器都可以构建当前的完整备份。我曾经使用过rdiff-backup几次：

rdiff-backup将一个目录备份到另一个目录，可能通过网络。目标目录最终成为源目录的副本，但额外的反向差异存储在该目标目录的特殊子目录中，因此您仍然可以恢复一段时间前丢失的文件。这个想法是结合镜像和增量备份的最佳功能。rdiff-backup还保留子目录、硬链接、开发文件、权限、uid/gid 所有权、修改时间、扩展属性、acls 和资源分支。此外，rdiff-backup可以通过管道以带宽高效的方式运行，例如rsync。

请注意，该软件自 2009 年以来就没有更新过。我不知道现在它是否是一个好的推荐。

相关内容