背景：
作为一个有点胆怯的人，我到目前为止有dd整个文件系统用于备份。主要缺点是这些完整备份过度使用内存（不幸的是还包括空闲块）
问题
我现在只想备份文件系统内的文件，但如果需要的话还能够重新创建文件系统。虽然可以轻松提取数据（即通过rsync -a），
但我想知道是否有一些案例我忽略在哪里例如分配给文件的索引节点号很重要吗？
特别是在备份/根文件系统及其上的系统的背景下。我不太担心/home/文件系统，但有足够的想象力，可以预期在恢复/根文件系统时可能会发生一些奇怪的事情，并且索引节点突然发生了变化？
一个好的答案应该包括最完整的情况列表，在这些情况下，索引节点号可能很重要并最终导致麻烦。
更新 一些实验表明，例如硬链接（自然地引用相同的索引节点）可能需要一些注意。不确定它们是否需要重新分配相同的索引节点。
幸运的是，这里的普通 ubuntu 12.04 上的硬链接数量只有大约 10 个文件（这样我就可以通过脚本记录它们并在需要时进行修复，并且rsync -a不会关心 inode 编号）
例子 我认为重要的一个案例是SELinux安全模块，因为它基本上使用索引节点号。所以这已经是一种情况了，但也许还有其他情况。
更新2
我只是运行一个测试来备份和恢复虚拟 12.04 Ubuntu 系统，rsync -aH同时重新格式化其间的分区以通过mkfs.ext4 /dev/sdX -U oldfsUUID.本质上，当文件恢复最常用的所有索引节点时，不再与原始索引节点相关。幸运的是，对于我的 Ubuntu 12.04 设置来说，inode 似乎并不重要。我知道这并不能证明什么。我仍然希望得到包含问题案例列表的答案。我已经提到过selinux，但我认为可能还有更多，因此有机会从了解的人那里得到一个好的答案。
答案1
索引节点号对于普通应用程序来说并不重要。部分原因是索引节点编号几乎没有用处，部分原因是如果应用程序依赖于索引节点编号，则它会在备份和恢复周期后停止工作。所以备份系统不会恢复inode编号，因此应用程序不依赖它们，因此备份系统不需要恢复inode编号。
大多数备份方法甚至无法恢复索引节点号。内核中的文件系统驱动程序在创建文件时使用任何空闲的 inode，没有办法从应用程序中限制它。
有些文件系统甚至没有索引节点号。
应用程序使用索引节点号的一件事是测试两个路径是否指定同一文件：在特定时间点比较设备号和索引节点号。为此，设备号和索引节点号不必随时间保持不变。备份程序本身这样做是为了检测硬链接。
无法打开给定 inode 编号的文件，或将文件获取到给定 inode 编号的路径（不包括需要访问底层块设备的调试工具）。在大多数文件系统上，路径指向索引节点，但索引节点不包含指向包含该文件的目录的指针，因此如果不遍历整个文件系统就无法实现这一点。此外，该文件甚至可以被删除（例如，硬链接计数可能为 0，在其内容被删除并释放其 inode 之前等待关闭）。
SELinux 使用 inode 来跟踪上下文，而不是 inode 编号。 SELinux 上下文与其他所有内容一样使用路径存储。
rsync -AHX是一种安全且常见的备份方法。
我可以想到一个使用 inode 编号的应用程序：某些版本流氓，第一个全屏基于终端的游戏之一，它激发了至今仍在使用的 Curses 库。它将inode编号存储在保存文件中，以防止随意复制保存文件。我从未见过在“严肃”的应用程序中这样做。