ハードリンクには、リンク自体（ファイルデータではない）にのみ数百バイトが必要なようです。

追加情報

まず、答えてくれた皆さんに感謝します。

そこで、ディレクトリ/フォルダエントリが4KBを占め、数値が歪んだという以下の答えをテストするためにテストを再実行しました。そのため、今回は1つのディレクトリに20,000個のファイルを入れ、もう1つのディレクトリにはcp'dを使用しました。結果は非常に異なります。ファイル名の長さを削除すると、各ハードリンクの長さは約13バイトで、600バイトよりはるかに優れています。わかりました、完全性のために以下に提供された答えを検討してください。これは、アイテムごとに4KBを占めるディレクトリ/フォルダによるものです。もう一度テストしましたが、今回は何千ものディレクトリを作成し、各ディレクトリにファイルを配置しました。数学を実行した後の計算（ハードドライブが占めるスペースの増加/ファイル数（ディレクトリを無視））は、ファイルごとにほぼ正確に4 KBです。これはハードリンクが数バイトしか占有しませんが、実際のディレクトリ/フォルダエントリが占有していることを示しています。 4KB。

だから私はrsync /ハードリンク/スナップショットバックアップ戦略を実装するつもりで、ハードリンクが占めるデータの量を知りたいです。たとえば、ディレクトリエントリなどで追加のリンクエントリが必要です。とにかく、これに関する情報が見つからないようです。ファイルシステムによって異なります。私が見つけることができる唯一の情報は、それらがスペースを占有していないこと（おそらくファイルの内容のためのスペースを占有しないという意味）と、それらが占めるスペースは、ハードリンクを保存するのに数バイトしか占有していないので無視できるということです。

だから私は2つのシステム（仮想マシン1つ、物理ハードウェア1つ）を選択し、rootディレクトリからrootとして次のことをしました。

mkdir link
cp -al usr link

このusrディレクトリには約54,000個のファイルが含まれています。ハードディスクの空き容量が約34MB増加します。これにより、各ハードリンクは約600バイトを占めます。それとも私が何か間違っているのでしょうか？

どちらのシステムでもLVMを使用しており、フォーマットはext4です。

ファイル名のサイズは合計1.5MB程度です（ls -Rを実行してファイルにリダイレクトすることによって得られました）。

正直なところ、ハードリンクを使用したrsyncは非常にうまく機能するため、いくつかのワーカーサーバーで毎日のバックアップに使用する予定です。また、かなり長い間、このような増分バックアップ/スナップショットを実行するのは簡単だと思います。しかし、10日後には30MBが300MBになる式です。また、実際のファイルデータ/コンテンツが数百KBしか変更されない場合は、1日に30MB以上のハードリンクを保存することが過度に見えるかもしれませんが、最新のディスクサイズに対するあなたの主張に同意します。このハードリンクサイズがどこでも言及されていなかったので、私が何か間違っているのではないかと思いました。 Linuxオペレーティングシステムでは、600バイトは一般的なハードリンクですか？

使用されたスペースを計算するためにdfbeforeとafterを実行しましたcp -al。