UNIXファイルシステムのどこに、ユーザー固有ではないデータ（nfsやftp経由で共有されるデータ、またはバックアップなど）を保存する従来の場所はありますか？
もちろん、任意のフォルダー（/ home / shared、/ data、/ var / dataなど）を作成して使用できますが、「ベスト」または「共通」のプラクティスガイドラインがあるかどうかは本当に疑問です。ファイルシステム階層標準は、共有データの場所を指定していません。
バックアップの場合、/ var / backupsを使用する傾向がありますが、いくつかのcronjobが書き込むので、実際に使用する必要がありますか？
回答:
この質問はないで明確な答え持っているように見えるファイルシステム階層標準をかを指定し、/srvとして「このシステムによって提供される[ING]サイト固有のデータが含まれています」。（3.16.1）
これを指定する主な目的は、特定のサービスのデータファイルの場所をユーザーが見つけられるようにすること、および読み取り専用データ、書き込み可能なデータ、およびスクリプト用の単一ツリーを必要とするサービス
（私の強調）
注：「システムによって提供される」とは、必ずしもインターネットを指すとは限りません。ネットワークを意味する必要さえありません。共有システムにも適用できます。さらに、サイトとサービスという言葉は、インターネット以前の意味で理解されるべきです。あなたのサイトは「物理学部」または「財務部」になります。
それは言い続けます：
大規模システムでは、/ srv / physics / www、/ srv / compsci / cvsなどの管理コンテキストごとに/ srvを構成すると便利です。このセットアップはホストごとに異なります。したがって、既存の/ srvの特定のサブディレクトリ構造や、/ srvに必ず格納されるデータに依存するプログラムはありません。ただし、/ srvは常にFHS準拠のシステムに存在し、そのようなデータのデフォルトの場所として使用する必要があります。
したがって/srv/nfs、などのディレクトリでデータをさらに構造化する必要があります/srv/backup。
また、これを行う人はほとんどいません。しかし、そうしない正当な理由はありません。標準は決して古いものではありません。
/var伝統的には、印刷スプールやログファイルなどに使用されますが、Apache Webサーバーでも使用されます（とにかくDebianシステムでは-SUSEは/ srvを使用します）。/var共有データ用の適切なディレクトリであるかどうかについてはコンセンサスがないようです。しかし、代わりに使用することにした場合、後悔はないでしょう。
注：Karthickの答えは決して間違っていません。FHSは/ srvを「そのようなデータのデフォルトの場所として使用する必要がある」と述べていますが、標準では、用語の解釈方法に応じて、ユーザーの好みに応じて余地が残されています。
ファイルシステム階層：
NFSドキュメントで提案されているように、以前/exportはNFSでサービスを提供し/mnt、NFS共有をローカルにマウントするのを見てきました。
/etc/exportsファイル名エクスポートされたボリュームや/exportsディレクトリそれらをマウントし、リモートユーザーにそれらを提供しています/mnt。サーバーホストは/mnt、リモートホストとの互換性を維持し、負荷平準化、クォータなどの機能を保持するために、サーバー上でローカルに実行されているクライアントまたはプロセスの使用に同じnfsデーモンを使用してこれらの同じ共有をマウントすることもできます
それは、「標準」に近いものです。/exportFHSにはないため/export、独立して追加されたため、おそらく誰も満足していないことに注意してください/srv。おそらく、「サービス」ボリュームではなくデーモンとして実行されている「サービス」との潜在的な混乱のためです。/export混乱の可能性がほとんどない明確な名前です。私は何も見ません/srv。
/var/www前/srv/に配置し始めたことに注意してください。