背景：
私は臆病者なので、これまではddファイルシステム全体をバックアップしてきました。大きな欠点は、これらの完全なバックアップ（残念ながら空きブロックも含まれていました）にメモリを過剰に使用することです。
質問
今はファイルシステム内のファイルのみをバックアップしたいと思っていますが、必要に応じてファイルシステムを再作成できるようにしたいと 思っています。データは簡単に抽出できますが（つまり、を介してrsync -a）、
事例私は見落としますどこ例えばファイルに割り当てられた inode 番号は重要ですか?
/これは特に、システムを含むルート ファイルシステムをバックアップするという背景があります。ファイルシステムについてはあまり心配していませんが、ルート ファイルシステムを復元したときに、突然 inode が変更されるなど、/home/何か奇妙なことが起こるのではないかと想像するほど想像力が豊かです。/
良い回答には、inode 番号が重要になり、最終的に問題を引き起こす可能性があるケースの最も包括的なリストが含まれます。
アップデート いくつかの実験では、例えばハードリンク(当然同じ inode を参照する) には注意が必要かもしれません。必ず同じ inode を再割り当てする必要があるかどうかは不明です。
幸いなことに、ここでは、Ubuntu 12.04 のハードリンクの数は 10 ファイル程度しかありません (そのため、スクリプトで記録して、必要に応じて修復することができ、rsync -ainode 番号を気にする必要はありません)。
例 私が重要だと思うケースの一つはセリナックスセキュリティ モジュールは基本的に inode 番号を使用するため、これはすでに 1 つのケースですが、他にもケースがあるかもしれません。
アップデート2
でダミーの 12.04 Ubuntu システムをバックアップして復元するテストを実行したrsync -aHところ、パーティションを再フォーマットして新しい ext4 をセットアップしましたmkfs.ext4 /dev/sdX -U oldfsUUID。基本的に、ファイルが復元されると、最も頻繁に使用されるすべての inode は元のものとは関連がなくなりました。幸いなことに、Ubuntu 12.04 セットアップのこの 1 つのケースでは、inode は問題にならないようです。これはあまり証明にならないことは承知しています。それでも、問題のあるケースのリストを添えて回答していただければ幸いです。selinuxすでに述べたケースですが、他にもあるかもしれないので、詳しい人から良い回答が得られる可能性があります。
答え1
通常のアプリケーションでは、i ノード番号は重要ではありません。これは、i ノード番号がほとんど使用されないことと、アプリケーションが i ノード番号に依存している場合、バックアップと復元のサイクルの後に動作が停止するためです。したがって、バックアップ システムは i ノード番号を復元せず、アプリケーションは i ノード番号に依存しないため、バックアップ システムは i ノード番号を復元する必要がありません。
バックアップのほとんどのアプローチでは、inode 番号を復元することすらできません。カーネルのファイルシステム ドライバーは、ファイルを作成するときに空いている inode を使用しますが、アプリケーションからそれを制限する方法はありません。
一部のファイルシステムには、inode 番号すらありません。
アプリケーションが inode 番号を使用する唯一の目的は、2 つのパスが同じファイルを指定しているかどうかをテストすることです。つまり、特定の時点でデバイス番号と inode 番号を比較します。このために、デバイス番号と inode 番号は時間の経過に伴って一定である必要はありません。バックアップ プログラム自体がハード リンクを検出するためにこれを実行します。
inode 番号を指定してファイルを開く方法や、inode 番号を指定してパスを指定してファイルにアクセスする方法はありません (基礎となるブロック デバイスへのアクセスを必要とするデバッグ ツールを除く)。ほとんどのファイル システムでは、パスは inode を指しますが、inode にはファイルを含むディレクトリへのポインターが含まれていないため、ファイル システム全体を走査せずにこれを実装することはできません。さらに、ファイルは削除される可能性もあります (つまり、ハード リンク カウントが 0 で、内容が削除されて inode が解放される前に閉じられるのを待機している可能性があります)。
SELinux は、inode 番号ではなく、inode を使用してコンテキストを追跡します。SELinux コンテキストは、他のすべてと同様に、パスを使用して保存されます。
rsync -AHXバックアップを作成する安全で一般的な方法です。
inode番号を使用するアプリケーションを1つ思い浮かべることができます。ローグは、今日でも使用されている Curses ライブラリの原動力となった、最初のフルスクリーン ターミナル ベースのゲームの 1 つです。保存ファイルに inode 番号を保存して、保存ファイルの不用意なコピーを防止します。私は、「本格的な」アプリケーションでこのような処理が行われているのを見たことがありません。