☰

将整个 300 GB 文件系统添加到 Git Annex 存储库？

tag-icon • tag-icon ubuntu bash memory git
将整个 300 GB 文件系统添加到 Git Annex 存储库？

默认情况下，我会收到一条错误消息，提示我打开了太多来自该进程的文件。如果我手动解除限制，则会收到一条错误消息，提示我内存不足。无论出于何种原因，Git Annex 当前状态似乎并未针对此类任务（一次向存储库添加数千个文件）进行优化。

作为一种可能的解决方案，我的下一个想法是做类似的事情：

cd /
find . -type d | xargs git annex add --$NONRECURSIVELY
find . -type f | xargs git annex add
    # Need to add parent directories of each file first or adding files fails

此解决方案的问题在于，从文档来看，似乎没有在 Git Annex 中非递归添加目录的方法。我是否遗漏了什么或有解决方法？

如果我提出的解决方案是死路一条，那么人们还有其他方法解决这个问题吗？

答案1

更新：不要这样做。

显然，Git Annex 会将添加到存储库的每个文件移动到 .git/annex/objects 中的某个目录结构，然后将其替换为指向 .git 中实际文件的符号链接。如果我没有先尝试添加 /etc，那么这样做就没问题了。

不用说，服务器崩溃了。幸运的是，我想到了一个解决办法：

find /etc -type l | while read file ; do realpath=`realpath "${file}"` ; rm "${file}" ; cp -rfa "${realpath}" "${file}" ; done

编辑：无视；我很笨；系统仍然陷入困境；这将是一个漫长的夜晚。

第二次编辑：设法解除系统故障。这需要大量手动重建 /etc 并重新安装每个软件包，包括重新配置/修复大量软件包以及调试/解决大量 APT 问题。不会再尝试这样做了。

至于控制 300GB 文件的版本问题，每当我决定某件事并使其正常工作时，我都会回来进行更新（无论是否使用 Git Annex）。

答案2

小更新：

  1. 整个问题完全是用户错误造成的。我的根驱动器是 256 GB 的 SSD，而我尝试添加的其中一个文件夹映射到 1.5 TB 的 RAID 1 阵列。无论我如何尝试完成此操作，它都会不可避免地尝试将比驱动器可容纳的更多的文件复制到 /.git 文件夹中（呃）。不知道我以为会发生什么 :/。

  2. 这就是为什么你不要弄乱系统目录......

  3. 在 1.5 TB 驱动器上初始化 Git Annex 存储库，然后只复制我想要备份的根级目录。常规git annex add .操作非常出色，过去五天左右，我的存储库一直在使用 Glacier 进行备份这些 Annex-Glacier 钩子没什么问题。

答案3

我使用附件进行主机管理，如下所示：

  • 在 /var/annex 下创建 git annex 存储库
  • 在 /var/annex 中，为每台机器设置一个子目录 - 这是该机器独有的文件存放的位置。例如，/var/annex/mars.example.com/etc/default/krb5-kdc
  • 有另一个通用目录，用于存放网站独有的文件，例如 /var/annex/example.com/etc/resolv.conf
  • 使用 gnu stow 管理 / 中指向 /var/annex/* 的所有符号链接
  • /var/annex/example.com/usr/local/bin/ 中有一个简单的脚本，它运行 gnu stow 和 git annex （当然，上述所有机制都会将上述脚本符号链接到 /usr/local/bin 中）

这一切就像一个低速、分布式的“管理文件系统”，具有版本控制、暂存以及您想要在使用 git 和 git annex 时纳入的任何制衡功能。

如果您能合理地管理您的机器，则无需签入整个根文件系统——其中大部分内容在不同的机器之间没有差异。您确实需要某种方法来管理软件包的安装和升级，但该工具本身可以连同它用作源数据的软件包和其他 blob 一起签入附件中——同样，所有版本都由 git 提供。

相关内容