ساختار فایل‌سیستم لینوکس؛ از / تا /etc و /var

روی لینوکس تقریباً همه‌چیز از یک ریشه با نام / شروع می‌شود. برخلاف حرف درایو در ویندوز، اینجا یک درخت واحد دارید که دیسک‌ها، پارتیشن‌ها و حتی برخی APIهای هسته به‌صورت فایل یا دایرکتوری به آن وصل می‌شوند. اگر ندانید /etc برای تنظیمات است و /var برای داده‌های در حال تغییر، بسته‌ها را در خانهٔ کاربر پخش می‌کنید، لاگ دیسک را پر می‌کند، و استقرار غیرقابل‌بازتولید می‌شود.

Filesystem Hierarchy Standard (FHS) قرارداد رایج بسیاری از توزیع‌های لینوکس برای معنای دایرکتوری‌های سطح بالا است. صفحات man مثل hier(7) و در systemd، file-hierarchy(7) همین نقشه را خلاصه می‌کنند. توزیع ممکن است جزئیات را کمی جابه‌جا کند، ولی یادگیری نقشهٔ FHS خواندن سرور غریبه را سریع می‌کند.

این مقاله دایرکتوری‌های حیاتی، تفاوت دادهٔ ثابت و متغیر، نکات استقرار اپ، و اشتباه‌های رایج را پوشش می‌دهد. مجوزها در ۱۴۷ می‌آیند؛ اینجا تمرکز روی «کجا» است نه «چه کسی اجازه دارد».

پاسخ کوتاه

ریشه / بالای درخت است. /etc تنظیمات سیستم، /var داده‌ها و لاگ‌های متغیر، /home خانهٔ کاربران، /usr برنامه‌ها و داده‌های فقط‌خواندنی توزیع، /opt نرم‌افزار اختیاری شخص ثالث، /tmp موقتی، /boot فایل‌های بوت، و /dev و /proc و /sys رابط‌های دستگاه و هسته‌اند. اپ Production را بی‌برنامه در / یا در خانهٔ root نریزید؛ مسیر پایدار، جداسازی لاگ/داده، و پشتیبان‌گیری را بر اساس همین نقشه طراحی کنید.

فایل‌سیستم لینوکس قرارداد اجتماعی Ops است: اگر هر تیم جایش را اختراع کند، نیمه‌شب هیچ‌کس نمی‌داند بکاپ کدام پوشه را بگیرد.

ریشه و اتصال ذخیره‌سازی

همهٔ مسیرها از / مطلق می‌شوند. پارتیشن جدا برای /home یا /var با mount به همین درخت می‌چسبد. در ابر، حجم اضافه اغلب روی /mnt یا /data mount می‌شود — نام را در مستند تیم قفل کنید. فرمان‌هایی مثل df -h و findmnt برای دیدن «کدام مسیر روی کدام دستگاه است» ضروری‌اند؛ پر شدن یک پارتیشن کوچک /var می‌تواند کل سرویس را بخواباند حتی اگر /home خالی باشد.

bash

df -h findmnt / ls /

نقشهٔ دایرکتوری‌های حیاتی

/etc — تنظیمات

محل کلاسیک فایل‌های پیکربندی سیستم و سرویس‌ها: شبکه، کاربران، واحدهای وابسته، و تنظیمات بسته‌ها. تغییر در /etc باید نسخه‌پذیر باشد (Git خصوصی، Ansible، یا حداقل یادداشت تغییر). کپی پشتیبان قبل از ویرایش دستی عادت خوب است. رمز و کلید را بی‌محابا داخل مخزن عمومی از /etc کپی نکنید.

/var — متغیر

لاگ، کش، اسپول، پایگاه‌دادهٔ بعضی بسته‌ها، و داده‌هایی که با اجرای سیستم رشد می‌کنند. /var/log را مانیتور کنید. اگر اپ لاگ را اینجا می‌نویسد، چرخش لاگ (logrotate) را فراموش نکنید. پر شدن /var یکی از شایع‌ترین علت‌های «ناگهان سایت خوابید» است.

/usr — برنامه‌های سیستم

باینری‌ها، کتابخانه‌ها و مستندات بسته‌های توزیع معمولاً زیر /usr می‌نشینند (/usr/bin، /usr/lib، …). در بسیاری سیستم‌های مدرن /bin به /usr/bin لینک شده است. دستی اینجا را با کپی فایل بهم نریزید؛ از مدیر بسته استفاده کنید تا ارتقا نشکند.

/home — کاربران

خانهٔ کاربران عادی: کد، کلید SSH کاربر، فایل‌های شخصی. برای سرویس Production بهتر است دادهٔ سرویس را در مسیر مشخص سیستمی بگذارید نه فقط داخل /home/ubuntu مگر تیم کوچک و آگاهانه این قرارداد را پذیرفته باشد.

/opt و /srv

/opt برای نرم‌افزار اختیاری شخص ثالث رایج است؛ /srv برای دادهٔ سرویس‌هایی که ارائه می‌دهید (طبق FHS). در عمل تیم‌ها گاهی /var/www یا /srv/app را انتخاب می‌کنند — مهم یکنواختی و مستند است.

/tmp و /var/tmp

موقت. /tmp ممکن است با راه‌اندازی پاک شود؛ /var/tmp ماندگارتر است. برای دادهٔ مهم به آن‌ها تکیه نکنید. روی بعضی سیستم‌ها /tmp با tmpfs در RAM است — برای فایل‌های بزرگ غافلگیرکننده است.

/boot، /dev، /proc، /sys

/boot هسته و فایل‌های بوت. /dev گره‌های دستگاه. /proc و /sys رابط‌های شبه‌فایلی هسته برای فرایندها و سخت‌افزار؛ برای مشاهده مفیدند، برای «پیکربندی دائمی» جای /etc نیستند.

جدول سریع

کجا اپ خودتان را بگذارید؟

الگوی رایج: کد یا آرتیفکت در /opt/myapp یا /srv/myapp، تنظیمات مخصوص محیط در /etc/myapp، دادهٔ پایدار در /var/lib/myapp یا حجم mountشده، لاگ در journald یا /var/log/myapp. واحد systemd به این مسیرها اشاره می‌کند. اگر همه‌چیز را در یک پوشه زیر /home مخلوط کنید، جدا کردن بکاپ و مجوز سخت‌تر می‌شود.

برای کانتینر، مسیر داخل Image جدا از حجم میزبان است. روی میزبان هنوز باید بدانید volume به کدام مسیر host می‌نشیند تا دیسک و بکاپ را مدیریت کنید.

لینک نمادین و درهم‌تنیدگی /bin و /usr

در توزیع‌های جدید، ادغام /usr رایج است: /bin → /usr/bin. اسکریپت‌های قدیمی که فرض‌های سخت دارند گاهی گیج می‌شوند، ولی برای کاربر روزمره شفاف است. قبل از حذف «لینک اضافی»، با readlink -f بفهمید هدف چیست.

مجوز و مالکیت در سطح مسیر

حتی با نقشهٔ درست، اگر /var/lib/myapp مال root باشد و سرویس با کاربر myapp اجرا شود، Permission denied می‌گیرید. ساختار و مجوز با هم معنا دارند. بعد از این مقاله، ۱۴۷–۱۴۹ را بخوانید و روی یک مسیر آزمایشی تمرین کنید.

کشف و عیب‌یابی روی سرور غریبه

1. ls / و df -h برای تصویر کلی.
2. findmnt و lsblk برای فهم mountها.
3. خواندن /etc/os-release برای توزیع.
4. دیدن واحدهای سرویس و WorkingDirectory در systemd.
5. جستجوی تنظیمات با grep کنترل‌شده زیر /etc (نه کور روی کل دیسک).

bash

cat /etc/os-release lsblk du -sh /var/log/* 2>/dev/null | sort -h | tail

اشتباه‌های رایج

• ریختن آرتیفکت روی / یا /root و فراموش کردن بکاپ.
• لاگ بدون چرخش در /home یا کنار کد.
• ویرایش فایل‌های /usr به‌جای استفاده از بسته یا /opt.
• فرض اینکه یک پوشه پر نیست چون پارتیشن دیگر خالی است.
• پاک کردن /tmp در حالی که فرایند فعال فایل موقت دارد.
• نگه‌داشتن Secret در مسیر world-readable زیر /srv.

چه زمانی از FHS منحرف شوید؟

گاهی سازمان مسیر استاندارد داخلی دارد (مثلاً /apps). اشکالی ندارد اگر مستند، مانیتورینگ و بکاپ هم‌خوان باشند. انحراف بی‌مستند هزینهٔ onboarding است. در کانتینرهای مینیمال ممکن است درخت ساده‌تر باشد؛ باز هم روی میزبان FHS مفید است.

سوالات متداول

آیا همهٔ توزیع‌ها دقیقاً FHS را یکسان پیاده می‌کنند؟

خیر، ولی نزدیک‌اند. همیشه man همان سیستم و مستند توزیع را ترجیح دهید.

/mnt و /media چه فرقی دارند؟

به‌طور سنتی /media برای رسانه‌های قابل‌حمل و /mnt برای mount موقت ادمین است؛ در عمل هر دو برای اتصال استفاده می‌شوند — قرارداد تیم مهم‌تر است.

چرا در /proc فایل می‌بینم ولی روی دیسک نیست؟

چون شبه‌فایل‌سیستم است؛ نمایش وضعیت هسته است نه فایل معمولی برای ویرایش دائمی.

آیا باید /var را پارتیشن جدا کنم؟

در سرورهایی که لاگ/داده رشد می‌کند، جداسازی از پر شدن ریشه جلوگیری می‌کند. در VPS کوچک گاهی یک پارتیشن کافی است اگر مانیتورینگ دیسک داشته باشید.

کد پروژه را در /var/www بگذارم یا /opt؟

هر دو رایج‌اند. /var/www سنت وب‌سرور است؛ /opt برای اپ نسخه‌دار مناسب است. یکی را انتخاب و یکنواخت کنید.

بکاپ و مسیرها

بکاپ بدون فهم ساختار یا زیاده‌روی می‌کند یا چیز مهم را جا می‌اندازد. حداقل: تنظیمات /etc مربوط به سرویس، دادهٔ /var/lib یا volume، و آرتیفکت نسخهٔ deploy. کش /tmp و غالب /usr از روی بسته قابل‌بازیابی است و اولویت بکاپ ندارد مگر سفارشی‌سازی نادر.

قبل از rm -rf روی مسیر سطح بالا، یک بار df و ls و در صورت نیاز mount را چک کنید. بازیابی از بکاپ وقتی مسیرها در مستند تیم ثبت شده باشد ساعت‌ها سریع‌تر است.

ارتباط با کانتینر و ابر

در Kubernetes و Docker، مسیر داخل کانتینر ممکن است FHS مینیمال باشد؛ پایداری داده با volume است. روی VM کلاسیک ابری، همان درخت / را می‌بینید. گیج شدن بین «مسیر داخل کانتینر» و «مسیر روی میزبان» از خطاهای رایج دیپلوی است — در runbook هر دو را بنویسید.

سناریوی عملی: استقرار یک API روی VPS

فرض کنید یک API و یک پایگاه‌داده روی یک VPS اوبونتو دارید. مسیر پیشنهادی: باینری یا پوشهٔ release در /opt/myapi/releases/VERSION با لینک current، فایل محیط غیرسری در /etc/myapi/env (مجوز محدود)، دادهٔ پایدار دیتابیس روی volume جدا که روی /var/lib/postgresql یا /data/pg mount شده، و لاگ اپ یا به journald یا به /var/log/myapi با logrotate. واحد systemd به /opt/myapi/current/bin/server و EnvironmentFile اشاره می‌کند.

اگر همه را در /home/ubuntu/app مخلوط کنید، جدا کردن بکاپ دیتابیس از کد، و دادن حداقل مجوز به کاربر سرویس سخت‌تر می‌شود. برای تیم یک‌نفره کوتاه‌مدت ممکن است کار کند؛ برای تیم و نیمه‌شب پشتیبانی، هزینهٔ پنهان دارد.

قبل از رفتن به Production، یک‌بار روی staging همان نقشهٔ مسیر را پیاده کنید تا اسکریپت deploy مسیرها را hard-codeٔ درست داشته باشد نه فرض‌های محلی لپ‌تاپ.

اندازه‌گیری رشد دیسک بر اساس مسیر

فرمان du به شما می‌گوید کدام زیردرخت سنگین است؛ df می‌گوید پارتیشن چقدر پر است. ترکیب این دو جلوی تصمیم غلط را می‌گیرد. وقتی ریشه ۹۵٪ پر است، اول /var/log و کش‌ها را ببینید، نه اینکه کورکورانه داخل /usr پاکسازی کنید.

bash

sudo du -xh /var --max-depth=2 2>/dev/null | sort -h | tail -n 20 sudo find /var/log -type f -name '*.log' -size +100M -printf '%s %p\n' 2>/dev/null | sort -n

هشدار مانیتورینگ را روی درصد پر بودن هر mount بگذارید، مخصوصاً اگر /var جدا است. پر شدن inode هم جدا از فضای بلوک است؛ df -i را در چک‌لیست بگذارید وقتی میلیون‌ها فایل کوچک می‌سازید.

فایل‌سیستم‌های شبه‌ای و امنیت

دسترسی به /proc و /sys برای عیب‌یابی مفید است اما در کانتینر و محیطهای محدود ممکن است فیلتر شود. روی میزبان چندمستأجره، اطلاعات /proc می‌تواند جزئیات فرایندها را لو بدهد؛ مدل امنیتی توزیع و namespaceها را بشناسید. هرگز به‌عنوان راه‌حل دائمی، تنظیمات را فقط با echo به فایل‌های /proc بدهید بدون اینکه معادل ماندگار در /etc یا پارامتر هسته داشته باشید.

خلاصه

فایل‌سیستم لینوکس درخت واحدی است با قرارداد معنایی برای تنظیمات، دادهٔ متغیر، برنامه‌ها و خانه‌ها. FHS و man hier نقشهٔ مشترک می‌دهند. اپ را با جداسازی کانفیگ/داده/لاگ مستقر کنید، دیسک را بر اساس مسیر مانیتور کنید، و قبل از دستکاری /usr یا پاکسازی /var فکر کنید.

قدم بعد: مجوز و مالکیت همان مسیرها را در ۱۴۷–۱۴۹ درست کنید تا ساختار روی کاغذ به دسترسی واقعی تبدیل شود.

منابع و مراجع

• Filesystem Hierarchy Standard 3.0 — https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
• man7.org — hier(7) — https://man7.org/linux/man-pages/man7/hier.7.html
• man7.org — file-hierarchy(7) — https://man7.org/linux/man-pages/man7/file-hierarchy.7.html
• Ubuntu Server documentation — https://documentation.ubuntu.com/server/
• systemd file hierarchy (freedesktop) — https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html