Де у файловій системі слід зберігати спільні дані?

Де у файловій системі unix є звичайне місце для збереження даних, що не належать користувачеві, наприклад, даних, що передаються через nfs або ftp, або резервного копіювання?

Я, очевидно, міг би створити та використовувати будь-яку довільну папку (наприклад, / home / shared, / data або / var / data), але мені дуже цікаво, чи є якісь "найкращі" чи "загальні" рекомендації щодо практики. Filesystem Hierarchy Standard не визначає місце розташування для загальних даних.

Для резервного копіювання я, як правило, використовую / var / backups, але, як кілька записів до нього записують, чи справді це слід залишити для їх використання?

На це питання , мабуть, є чіткий відповідь у Стандарті ієрархії файлової системи , який визначає /srvяк "містять [ing] дані для конкретних сайтів, які обслуговуються цією системою" . (3.16.1)

Основна мета цього уточнення полягає в тому, щоб користувачі могли знайти розташування файлів даних для певної послуги , і щоб сервіси, яким потрібне єдине дерево для перегляду лише даних, даних, що записуються, та сценаріїв

(мій акцент)

Примітка: "Обслуговується системою" не обов'язково посилається на Інтернет. Це навіть не означає мережу. Це застосовно навіть до спільної системи. Далі, слова сайт та сервіс слід розуміти в їх значенні до Інтернету. На вашому сайті може бути "відділ фізики" або "бюро фінансів".

Продовжує говорити:

У великих системах може бути корисно структурувати / srv за адміністративним контекстом, наприклад / srv / physics / www, / srv / compsci / cvs тощо. Цей параметр відрізнятиметься від хоста до хоста. Тому жодна програма не повинна покладатися на конкретну структуру підкаталогу існуючих / srv або даних, які обов'язково зберігаються в / srv. Однак / srv завжди повинен існувати в системах, сумісних з FHS, і повинен використовуватися як місце за замовчуванням для таких даних.

Тому слід додатково структурувати ваші дані в каталогах , таких як /srv/nfs, /srv/backupі так далі.

Я також повинен зазначити, що мало хто вже робить це. Але немає вагомих причин, чому вони цього не роблять. Стандарт ні в якому разі не застарілий.

/varтрадиційно використовується для таких речей, як шпулі для друку та файли журналів, але він також використовується веб-сервером Apache (так чи інакше в системах Debian - використання SUSE / srv); Здається, немає єдиної думки щодо того, чи /varє правильним каталогом спільних даних. Але якщо ви вирішите використовувати його замість цього, у вас не буде жалю, я впевнений.

Зауважте також: відповідь Картіка аж ніяк не є помилковою. FHS каже / srv "слід використовувати як місце за замовчуванням для таких даних", але стандарт залишає місце для власних уподобань, залежно від того, як ви інтерпретуєте терміни.

• Дані, що не належать користувачеві, можуть зберігатися в / usr / local / var, щоб вони більше не опинилися на спільному ресурсі newtwork.
• Все, що не перебуває під ../local/ .., дозволено закінчувати спільну доступність nfs, тому якщо ви хочете завантажити дані із загальної інформації nfs та переконайтеся, що вони зберігаються локально на жорсткому диску машини.
• Тоді вам слід вибрати шлях із ... / local / .. у ньому .... решта залежить від характеру даних, від його типу. Це може бути / local / var або / local / tmp тощо .

Ієрархія файлової системи:

Подивіться також на це

Я не думаю, що FHS визначає будь-яке місце для спільних даних користувачів. Користувачі до тих, де вони хочуть зберігати там спільні дані. Я зазвичай використовую /usr/local/sharedабо /home/shared.

Я бачив, як /exportраніше служив з nfs та /mntвикористовував для монтажу частки nfs локально, у корпоративному середовищі, як це запропоновано в документації NFS, стандарт, який я підозрюю, що спочатку прийшов із програми Sun OS, пізніше перейменованої в Solaris.

В /etc/exportsіменах файлів, що експортуються томів і /exportsкаталоги служать їм для віддалених користувачів, які змонтують їх на /mnt. Хост сервера може також змонтувати ці ж спільні /mntділянки на використанні того ж демона nfs для використання будь-яких клієнтів або процесів, що працюють локально на сервері, щоб зберегти сумісність з будь-якими віддаленими хостами і, можливо, зберегти функціональність вирівнювання завантаження, квот тощо.

Це наближається до "стандарту", який він отримує. Зауважте, що /exportнемає у FHS, тому /exportбуло додано самостійно, тому, мабуть, ніхто не задоволений /srv. Можливо, через потенційну плутанину з "послугами", які працюють як демони, а не "обслуговуються" томи. /exportоднозначно названий з малою ймовірністю плутанини. Я ніколи нічого не бачу /srv.