Gdzie w systemie plików powinienem przechowywać współdzielone dane?

Gdzie w systemie plików unix znajduje się konwencjonalna lokalizacja do zapisywania danych innych niż dane użytkownika, na przykład danych udostępnianych przez nfs lub ftp, lub kopii zapasowych?

Mógłbym oczywiście utworzyć i użyć dowolnego dowolnego folderu (takiego jak / home / shared, / data lub / var / data), ale naprawdę zastanawiam się, czy istnieją jakieś wytyczne dotyczące „najlepszych” lub „wspólnych” praktyk. Filesystem Hierarchy Standard nie określa lokalizację dla współdzielonych danych.

W przypadku kopii zapasowych mam tendencję do używania / var / backups, ale skoro piszę do nich kilka cronjobs, czy naprawdę powinno być pozostawione do użytku?

To pytanie nie wydaje się mieć jasną odpowiedź w Filesystem Hierarchy Standard , która określa /srvjako „zawierać [em] Dane site-specific, które jest obsługiwane przez ten system” . (3.16.1)

Głównym celem określenia tego jest, aby użytkownicy mogli znaleźć lokalizację plików danych dla konkretnej usługi oraz aby usługi wymagające jednego drzewa dla danych tylko do odczytu, danych zapisywalnych i skryptów

(mój nacisk)

Uwaga: „Obsługiwane przez system” niekoniecznie odnosi się do Internetu. To nie musi nawet oznaczać sieci. Dotyczy to nawet wspólnego systemu. Ponadto, słowa „ witryna i usługa” należy rozumieć w ich znaczeniu sprzed internetu. Twoja strona może być „działem fizyki” lub „biurem finansów”.

Mówi dalej:

W dużych systemach przydatne może być ustrukturyzowanie / srv według kontekstu administracyjnego, takiego jak / srv / physics / www, / srv / compsci / cvs itp. Ta konfiguracja różni się w zależności od hosta. Dlatego żaden program nie powinien polegać na konkretnej strukturze podkatalogu istniejącej / srv lub danych koniecznie przechowywanych w / srv. Jednak / srv powinien zawsze istnieć w systemach zgodnych z FHS i powinien być używany jako domyślna lokalizacja takich danych.

Dlatego należy dodatkowo uporządkować swoje dane w katalogach, takich jak /srv/nfs, /srv/backupi tak dalej.

Powinienem również wspomnieć, że niewiele osób już to robi. Ale nie ma dobrego powodu, aby tego nie robić. Standard w żadnym wypadku nie jest przestarzały.

/varjest tradycyjnie używany do buforowania wydruku i plików dziennika, ale jest także używany przez serwer WWW Apache (w systemach Debian i tak - SUSE use / srv); Wydaje się, że nie ma zgody co do tego, czy /varjest to właściwy katalog dla współdzielonych danych. Ale jeśli zdecydujesz się go użyć, na pewno nie będziesz żałować.

Uwaga: odpowiedź Karthicka w żadnym wypadku nie jest błędna. FHS mówi, że / srv „powinno być używane jako domyślna lokalizacja dla takich danych”, ale standard pozostawia miejsce na własne preferencje, w zależności od sposobu interpretacji warunków.

• Dane niespecyficzne dla użytkownika mogą być przechowywane w / usr / local / var, aby nie znalazły się ponownie w udziale newtwork.
• Wszystko, co nie jest pod ../local/ .., może skończyć się na udziale nfs, więc jeśli chcesz pobrać dane z udziału nfs i upewnij się, że są one przechowywane lokalnie na dysku twardym komputera.
• Następnie powinieneś wybrać ścieżkę z ... / local / .. .... reszta zależy od charakteru danych, od rodzaju. Może to być / local / var lub / local / tmp itp. .

Hierarchia systemu plików:

Zobacz także

Nie sądzę, że FHS definiuje jakiekolwiek miejsce dla udostępnionych danych użytkownika. To użytkownicy muszą przechowywać tam udostępnione dane. Zwykle używam /usr/local/sharedlub /home/shared.

Widziałem, /exportjak służyłem do obsługi NFS i /mntdo montowania udziału NFS lokalnie, w środowisku korporacyjnym, jak sugerowano w dokumentacji NFS, standard, który, jak podejrzewam, pierwotnie pochodził z Sun OS, później przemianowany na Solaris.

Te /etc/exportsnazwy plików eksportowane woluminów oraz /exportskatalog służy im do zdalnych użytkowników, którzy zamontować je na /mnt. Host serwera może również montować te same udziały przy /mntużyciu tego samego demona nfs na potrzeby dowolnych klientów lub procesów działających lokalnie na serwerze, aby zachować zgodność z dowolnymi zdalnymi hostami i być może zachować funkcjonalność wyrównywania obciążenia, przydziałów itp.

To jest tak blisko „standardu”, jak to tylko możliwe. Pamiętaj, że /exportnie ma go w FHS, dlatego /exportzostał dodany niezależnie, więc prawdopodobnie nikt nie jest zadowolony /srv. Prawdopodobnie z powodu potencjalnego pomylenia z „usługami” działającymi jako demony zamiast woluminów „obsługiwanych”. /exportjest jednoznacznie nazwany z małą szansą na zamieszanie. Nigdy niczego nie widzę /srv.