背景：
作為一個有點膽怯的人，我到目前為止有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編號儲存在保存檔案中，以防止隨意複製保存檔案。我從未見過在“嚴肅”的應用程式中這樣做。