اتصال و مانت دیسک اضافه سرور در لینوکس

سرور را ریبوت کرده‌اید و بالا نمی‌آید. کنسول روی emergency mode گیر کرده یا پیام Failed to mount /mnt/data می‌دهد و شما فقط با یک دیسک جدید طرف نیستید؛ با خطای fstab طرف هستید. این دقیقاً همان لحظه‌ای است که آدم می‌فهمد «مانت کردن» یک دستور یک‌خطی نیست، یک تصمیم عملیاتی است. اگر همین حالا دیسک اضافه سرور را وصل کرده‌اید و نمی‌دانید از کجا شروع کنید، ترتیب کار این است: شناسایی، پارتیشن‌بندی، ساخت فایل‌سیستم، مانت موقت، تست، بعد دائمی‌کردن.

اول ببینید کرنل دیسک اضافه سرور را می‌بیند یا نه

قبل از هر چیز باید مطمئن شوید دیسک در سطح سیستم‌عامل دیده می‌شود. اگر سرور فیزیکی است و دیسک را تازه به背 slot اضافه کرده‌اید، ممکن است نیاز به rescan داشته باشید:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
sudo partprobe
cat /proc/partitions

خروجی lsblk باید یک دستگاه بدون mountpoint نشان بدهد، مثلاً sdb با حجم 500G. اگر چیزی نمی‌بینید، مشکل پارتیشن‌بندی نیست؛ مشکل لایه پایین‌تر است. در ماشین‌های مجازی، دیسک را باید از پنل به ماشین attach کرده باشید و بعد از آن یک بار ری‌استارت یا rescan لازم است. در سرورهای ابری معمولاً دیسک بلافاصله بعد از attach ظاهر می‌شود، ولی در بعضی پلتفرم‌ها تا خاموش و روشن نشدن، دستگاه در /dev ساخته نمی‌شود.

پارتیشن‌بندی و ساخت فایل‌سیستم روی دیسک اضافه سرور

برای دیسک داده، GPT را انتخاب کنید نه MBR. دلیلش ساده است: MBR سقف 2 ترابایت دارد و اگر بعداً دیسک بزرگ‌تری وصل کنید، مجبور به مهاجرت می‌شوید. با parted کار سریع‌تر پیش می‌رود:

sudo parted /dev/sdb mklabel gpt
sudo parted -a optimal /dev/sdb mkpart primary ext4 0% 100%
sudo mkfs.ext4 -L data /dev/sdb1

برچسب -L data را دست‌کم نگیرید. در سرورهایی که چند دیسک دارند، نام دستگاه بعد از اضافه یا حذف سخت‌افزار جابه‌جا می‌شود و sdb ممکن است روزی sdc شود. با LABEL یا UUID این مشکل حل می‌شود.

انتخاب فایل‌سیستم یک تصمیم واقعی است، نه سلیقه. برای دیسک داده روی سرور عمومی، ext4 انتخاب پیش‌فرض من است: پایدار، ابزار تعمیر بالغ، و رفتار قابل پیش‌بینی زیر بار. XFS را وقتی انتخاب می‌کنم که فایل‌های بزرگ و نوشتن همزمان زیاد باشد؛ مثلاً مخزن بکاپ یا دیسک دیتابیس با فایل‌های چند گیگابایتی. XFS را نمی‌توان کوچک کرد، فقط بزرگ. اگر احتمال می‌دهید روزی لازم شود حجم را کم کنید، از همان اول ext4 بردارید.

مانت موقت، تست، و بعد دائمی‌کردن

هرگز مستقیم سراغ fstab نروید. اول موقت مانت کنید و بنویسید و بخوانید:

sudo mkdir -p /mnt/data
sudo mount /dev/sdb1 /mnt/data
sudo chown deploy:deploy /mnt/data
echo test | sudo tee /mnt/data/probe.txt
df -h /mnt/data

اگر df حجم درست را نشان داد و فایل نوشته شد، حالا وقت دائمی‌کردن است. UUID را بگیرید:

sudo blkid /dev/sdb1

و خط fstab را با UUID بنویسید، نه با نام دستگاه:

UUID=8f3c1a2e-... /mnt/data ext4 defaults,nofail 0 2

دو نکته در همین خط، تفاوت بین یک ریبوت سالم و یک سرور در emergency mode است. اول، nofail: اگر دیسک به هر دلیلی حاضر نباشد، بوت متوقف نمی‌شود. دوم، ستون آخر عدد 2 است نه 1. عدد 1 برای ریشه (/) رزرو شده و اگر به دیسک داده بدهید، fsck ممکن است ترتیب اشتباهی اجرا شود. برای فایل‌سیستم‌های غیرریشه، 2 یا 0 بگذارید.

قبل از ریبوت، همیشه این را اجرا کنید:

sudo mount -a
sudo findmnt --verify

اگر mount -a بدون خطا برگشت، احتمال بوت سالم بالاست. اگر خطا داد، همان‌جا اصلاح کنید؛ نه بعد از ریبوت که فقط کنسول در اختیار دارید.

این‌جا اشتباه می‌کنند

شایع‌ترین اشتباهی که واقعاً دیده‌ام: نوشتن خط fstab با نام دستگاه (/dev/sdb1) به‌جای UUID، و بعد از آن اضافه کردن یک دیسک دیگر. علامتش هم این است که سرور بعد از ریبوت روی emergency mode می‌ایستد و journalctl -xb پیام Dependency failed for /mnt/data می‌دهد، در حالی که خود دیسک سالم است. اشتباه دوم، فراموش کردن nofail روی دیسک‌های غیرحیاتی است. اشتباه سوم که کمتر دیده می‌شود ولی گران تمام می‌شود: مانت کردن دیسک داده روی مسیری که از قبل فایل دارد. اگر /mnt/data پر از فایل باشد و دیسک را رویش مانت کنید، آن فایل‌ها زیر نقطه مانت پنهان می‌شوند. حجم دیسک پر است، ولی du چیز عجیبی نشان نمی‌دهد. برای دیدنشان باید از یک نقطه مانت دیگر یا bind mount استفاده کنید.

وقتی دیسک اضافه سرور را در fstab اشتباه نوشتید و سرور بالا نمی‌آید

راه‌حل، بوت در حالت rescue است. از پنل سرور، rescue mode را فعال کنید و بعد از بوت، دیسک ریشه را مانت کنید و فایل fstab را اصلاح کنید. اگر با rescue آشنایی ندارید، بازنصب سرور و کار با حالت rescue؛ نجات داده‌ها وقتی دسترسی را از دست دادید مسیر دقیق را قدم‌به‌قدم توضیح داده. نکته مهم: در rescue، خط معیوب را کامنت کنید، نه اینکه کل فایل را پاک کنید. بعد از بوت موفق، با UUID درست بازنویسی کنید.

یک راه‌حل موقت دیگر هم هست که در کنسول کار می‌کند: در GRUB کلید e را بزنید و به خط کرنل systemd.unit=emergency.target اضافه کنید. بعد از بوت، ریشه به‌صورت read-only مانت است، پس اول mount -o remount,rw / بزنید و بعد fstab را ویرایش کنید.

مانت دائمی برای سرویس‌ها: systemd mount یا fstab؟

برای دیسک داده معمولی، fstab کافی است و ساده‌تر. اما اگر سرویسی مثل MySQL یا Docker به آن مسیر وابسته است، ترتیب بوت مهم می‌شود. در این حالت یک unit از نوع mount بنویسید تا systemd بتواند وابستگی را دقیق مدیریت کند:

[Unit]
Description=Data disk
Before=mysql.service

[Mount]
What=/dev/disk/by-uuid/8f3c1a2e-...
Where=/mnt/data
Type=ext4
Options=defaults,nofail

[Install]
WantedBy=multi-user.target

اسم فایل باید دقیقاً با مسیر مانت هم‌خوان باشد: mnt-data.mount. اگر اسم را اشتباه بگذارید، unit ساخته می‌شود ولی هرگز فعال نمی‌شود و شما فکر می‌کنید کار می‌کند. هزینه این روش، پیچیدگی بیشتر و دیباگ سخت‌تر است؛ به همین دلیل فقط جایی که وابستگی سرویس واقعاً مهم است سراغش می‌روم.

یک نکته درباره کارایی

اگر دیسک اضافه سرور از نوع NVMe است و روی آن دیتابیس می‌برید، گزینه noatime را به خط fstab اضافه کنید. هر بار خواندن فایل، timestamp دسترسی را به‌روز نمی‌کند و روی بار نوشتن سنگین تفاوت محسوسی دارد. برای دیسک بکاپ که فقط نوشتن روی آن انجام می‌شود، این گزینه تقریباً بی‌اثر است و می‌توانید حذفش کنید.

اگر بعد از مانت کردن، سرعت خواندن و نوشتن پایین‌تر از انتظار بود، قبل از هر تغییری در تنظیمات، تشخیص علت لود بالای سرور؛ راهنمای عملی و گام‌به‌گام را ببینید؛ چون در بسیاری از موارد گلوگاه دیسک نیست، صف I/O یا سرویس دیگری است. برای انتقال داده‌های موجود به دیسک جدید هم انتقال فایل با scp و rsync؛ راهنمای عملی برای سرور گزینه‌های امن را پوشش می‌دهد.

اگر سرور شما مجازی است و دیسک را از پنل اضافه می‌کنید، رفتار attach در سرور ابری و سرور اختصاصی کمی متفاوت است؛ در اولی معمولاً بدون ریبوت ظاهر می‌شود و در دومی ممکن است به rescan کنترلر نیاز باشد. برای محیط‌های لینوکسی سبک‌تر، هاست لینوکس گزینه‌ای است که همین چرخه پارتیشن‌بندی و مانت را بدون درگیری با سخت‌افزار فیزیکی طی می‌کند.

پرسش‌های پرتکرار

چرا بعد از اضافه کردن خط fstab سرور در emergency mode بالا می‌آید؟

چون systemd نمی‌تواند دیسکی را که در fstab تعریف شده مانت کند و بوت را متوقف می‌کند. علت معمولاً UUID اشتباه، نام دستگاه جابه‌جا شده، یا نبودن گزینه nofail است. با journalctl -xb در همان کنسول، خط دقیق مشخص می‌شود.

تفاوت UUID و LABEL در fstab چیست و کدام بهتر است؟

UUID یک شناسه یکتاست که هنگام ساخت فایل‌سیستم تولید می‌شود و تا وقتی فایل‌سیستم را بازنسازید تغییر نمی‌کند. LABEL نامی است که خودتان می‌گذارید و ممکن است تصادفاً تکراری شود. UUID امن‌تر است؛ LABEL فقط وقتی مفید است که می‌خواهید خط fstab خوانا باشد و کنترل نام‌ها را دارید.

آیا باید دیسک اضافه سرور را قبل از مانت فرمت کنم؟

اگر دیسک نو است، بله؛ باید پارتیشن‌بندی و فایل‌سیستم بسازید. اگر دیسک از قبل داده دارد، فرمت کردن همه‌چیز را پاک می‌کند. اول با blkid و lsblk -f ببینید فایل‌سیستم دارد یا نه، و اگر دارد فقط مانت کنید.

چطور بفهمم دیسک واقعاً به‌صورت دائمی مانت شده است؟

بعد از ریبوت، findmnt /mnt/data باید مسیر و UUID را نشان بدهد و systemctl status mnt-data.mount باید active باشد. اگر بعد از ریبوت مانت نیست ولی دستی کار می‌کند، یعنی خط fstab شما هرگز خوانده نشده یا خطای نگارشی دارد.

قبل از هر ریبوت، mount -a و findmnt --verify را اجرا کنید. همین دو دستور، بیشترین تعداد سرورهایی را که در emergency mode گیر می‌کنند نجات می‌دهد.