پس از اضافه کردن دیسک به سرور، با lsblk نام آن را پیدا کنید، با parted یک پارتیشن GPT بسازید و با mkfs.ext4 فرمت کنید. یک پوشه مثل /mnt/data بسازید و دیسک را mount کنید. برای دائمی شدن، UUID دیسک را با blkid بگیرید و با گزینهٔ nofail در /etc/fstab ثبت کنید، سپس با mount -a پیش از ریبوت تست کنید. مراقب باشید دیسک اشتباهی را فرمت نکنید؛ فرمت همهٔ دادهها را پاک میکند.
چه زمانی به دیسک جدید نیاز دارید؟
وقتی فضای دیسک اصلی سرور رو به اتمام است، یا میخواهید دادهها را از سیستمعامل جدا نگه دارید، اضافه کردن یک دیسک یا Volume جدید راهحل رایجی است. کاربردهای معمول:
- نگهداری فایلهای آپلودی کاربران، دیتابیس یا volumeهای داکر روی دیسک جداگانه.
- فضای پشتیبانگیری محلی پیش از انتقال به جای دیگر.
- جدا کردن لاگها تا پر شدنشان سیستمعامل را از کار نیندازد.
بسیاری از ارائهدهندگان سرور مجازی امکان افزودن دیسک اضافه از پنل را دارند. مزیت دیسک جداگانه این است که اگر روزی سرور را عوض کنید یا سیستمعامل را از نو نصب کنید، دادهها روی دیسک داده دستنخورده باقی میمانند و فقط کافی است آن را دوباره وصل کنید. پس از افزودن، سیستمعامل دیسک را میبیند، اما تا وقتی آن را پارتیشنبندی، فرمت و mount نکنید، قابلاستفاده نیست. اگر مشکل فعلیتان پر شدن دیسک است، پیش از خرید فضای بیشتر راهنمای رفع خطای No space left on device را ببینید؛ گاهی چند گیگابایت لاگ یا image قدیمی داکر قابلپاک کردن است.
- شناسایی با lsblk
دیسک بدون پارتیشن و با اندازهٔ مورد انتظار را پیدا کنید.
- پارتیشنبندی با parted
جدول GPT و یک پارتیشن روی کل فضا.
- فرمت با mkfs.ext4
ساخت فایلسیستم؛ همهٔ دادهٔ قبلی پاک میشود.
- mount در /mnt/data
اتصال موقت و تست با df -h.
- ثبت در fstab
با UUID و گزینهٔ nofail، سپس تست با mount -a.
گام ۱: پیدا کردن دیسک جدید
با lsblk همهٔ دیسکها و پارتیشنها را ببینید:
lsblk
دیسک جدید معمولاً هیچ پارتیشن و نقطهٔ mount ندارد و نامی مثل vdb یا sdb یا nvme1n1 دارد. اندازهٔ دیسک را با چیزی که در پنل اضافه کردهاید مقایسه کنید تا مطمئن شوید دیسک درست را پیدا کردهاید. این مهمترین قدم است. فرمت کردن دیسک اشتباه، همهٔ دادههای آن را بدون بازگشت پاک میکند. اگر شک دارید، دستور زیر را اجرا کنید؛ دیسک جدید نباید هیچ فایلسیستم یا برچسبی داشته باشد:
sudo blkid /dev/vdb
sudo file -s /dev/vdb
اگر خروجی data بود، دیسک خالی است. اگر نوع فایلسیستمی مثل ext4 نشان داد، یعنی روی آن قبلاً چیزی بوده و باید دوباره بررسی کنید.
گام ۲: پارتیشنبندی
برای یک دیسک دادهٔ ساده، یک پارتیشن که کل فضا را بگیرد کافی است. با parted و جدول پارتیشن GPT:
sudo parted -s /dev/vdb mklabel gpt
sudo parted -s -a optimal /dev/vdb mkpart primary ext4 0% 100%
lsblk /dev/vdb
حالا پارتیشن vdb1 ساخته شده است. نام پارتیشن در دیسکهای NVMe کمی متفاوت است؛ مثلاً nvme1n1p1.
بعضی مدیران برای دیسک داده اصلاً پارتیشن نمیسازند و مستقیم روی کل دیسک فایلسیستم ایجاد میکنند؛ این کار ممکن است و گسترش دیسک را کمی سادهتر میکند، اما ابزارهای دیگر ممکن است دیسک بدون جدول پارتیشن را خالی تشخیص دهند. داشتن جدول پارتیشن روش امنتر و رایجتر است.
گام ۳: فرمت کردن
فایلسیستم ext4 برای بیشتر کاربردهای سرور پیشفرض مطمئنی است:
sudo mkfs.ext4 -L data /dev/vdb1
گزینهٔ -L data یک برچسب به فایلسیستم میدهد که شناسایی را سادهتر میکند. XFS هم گزینهٔ خوبی است، مخصوصاً برای فایلهای بزرگ؛ اما یک تفاوت مهم دارد: XFS را نمیتوان کوچک کرد، فقط بزرگ.
گام ۴: mount موقت و تست
یک پوشه بهعنوان نقطهٔ اتصال بسازید و دیسک را به آن وصل کنید:
sudo mkdir -p /mnt/data
sudo mount /dev/vdb1 /mnt/data
df -h /mnt/data
حالا هر چیزی که در /mnt/data بنویسید، روی دیسک جدید ذخیره میشود. اما این اتصال با ریبوت از بین میرود.
$ lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTSvda 253:0 0 40G 0 disk`-vda1 253:1 0 40G 0 part /vdb 253:16 0 100G 0 disk$ df -h /mnt/dataFilesystem Size Used Avail Use% Mounted on/dev/vdb1 98G 24K 93G 1% /mnt/data$
گام ۵: mount دائمی با fstab
برای اینکه دیسک پس از هر ریبوت خودکار وصل شود، باید آن را در فایل /etc/fstab ثبت کنید. بهجای نام دستگاه مثل /dev/vdb1 از UUID استفاده کنید؛ چون نام دستگاهها ممکن است پس از ریبوت یا افزودن دیسک دیگر جابهجا شوند، اما UUID ثابت است:
sudo blkid /dev/vdb1
مقدار UUID را بردارید و یک خط به fstab اضافه کنید. ابتدا یک نسخهٔ پشتیبان از fstab بگیرید:
sudo cp /etc/fstab /etc/fstab.bak
echo 'UUID=PASTE-UUID-HERE /mnt/data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab
گزینهٔ nofail بسیار مهم است. بدون آن، اگر روزی دیسک در دسترس نباشد، مثلاً از پنل جدا شده باشد، سرور هنگام بوت منتظر میماند و ممکن است وارد حالت اضطراری شود و حتی SSH هم بالا نیاید. با nofail سیستم بدون آن دیسک بوت میشود.
گام ۶: تست پیش از ریبوت
یک خطای تایپی در fstab میتواند سرور را در بوت بعدی از کار بیندازد. پیش از ریبوت، همیشه این تست را انجام دهید:
sudo umount /mnt/data
sudo mount -a
findmnt /mnt/data
اگر mount -a بدون خطا اجرا شد و findmnt دیسک را نشان داد، fstab درست است. اگر خطا داد، خط را اصلاح کنید یا نسخهٔ پشتیبان را برگردانید. اگر کار به حالت اضطراری کشید، از کنسول وب پنل سرور وارد شوید و fstab را اصلاح کنید.
گام ۷: مالکیت و استفاده
پوشهٔ جدید متعلق به root است. اگر برنامهای با کاربر دیگری باید در آن بنویسد، مالکیت را تغییر دهید:
sudo chown -R deploy:deploy /mnt/data
مدیریت کاربران و دسترسیها در آموزش کاربران و sudo آمده است. برای انتقال دادهٔ موجود به دیسک جدید، مثلاً پوشهٔ آپلودها، از rsync استفاده کنید، سپس مسیر را در تنظیمات برنامه عوض کنید یا یک bind mount بسازید. روشهای rsync در آموزش پشتیبانگیری با rsync آمده است.
انتقال دادههای داکر یا دیتابیس به دیسک جدید
یکی از رایجترین دلایل افزودن دیسک، بزرگ شدن دادههای داکر یا دیتابیس است. برای داکر، پوشهٔ داده بهطور پیشفرض /var/lib/docker است. روش امن انتقال آن:
- سرویس داکر را متوقف کنید:
sudo systemctl stop docker docker.socket. - دادهها را با حفظ مجوزها کپی کنید:
sudo rsync -aHAX /var/lib/docker/ /mnt/data/docker/. - در فایل
/etc/docker/daemon.jsonمقدار"data-root": "/mnt/data/docker"را تنظیم کنید. - داکر را اجرا کنید و با
docker info | grep "Docker Root Dir"مسیر جدید را بررسی کنید. - پس از اطمینان از سالم بودن کانتینرها، پوشهٔ قدیمی را حذف کنید.
برای دیتابیسها هم روند مشابه است: توقف سرویس، کپی کامل پوشهٔ داده با حفظ مالکیت، تغییر مسیر در تنظیمات و اجرای دوباره. در سیستمهایی که AppArmor فعال است، ممکن است لازم باشد مسیر جدید را در پروفایل آن سرویس هم مجاز کنید. هرگز پوشهٔ دادهٔ دیتابیس را در حالی که سرویس در حال اجراست کپی نکنید؛ نتیجه یک نسخهٔ ناسازگار و احتمالاً خراب است. دستورات پایهای که در این مسیر به کار میآیند در دستورات پرکاربرد لینوکس برای سرور آمده است.
بزرگ کردن دیسک پس از افزایش حجم
اگر بعداً حجم همین دیسک را از پنل افزایش دادید، سیستمعامل فضای جدید را خودکار به فایلسیستم اضافه نمیکند. ابتدا پارتیشن را بزرگ کنید، سپس فایلسیستم را:
sudo growpart /dev/vdb 1
sudo resize2fs /dev/vdb1
df -h /mnt/data
برای XFS بهجای resize2fs از sudo xfs_growfs /mnt/data استفاده کنید. دستور growpart در بستهٔ cloud-guest-utils قرار دارد. هر دو عملیات در حالی که دیسک mount است انجام میشوند و نیازی به توقف سرویسها نیست، اما پیش از هر تغییر پارتیشن، پشتیبان داشتن همیشه توصیه میشود.
سؤالات متداول
چرا باید از UUID بهجای /dev/vdb1 در fstab استفاده کنم؟
نام دستگاهها به ترتیب شناسایی دیسکها بستگی دارد و ممکن است پس از ریبوت یا افزودن دیسک دیگر تغییر کند. UUID شناسهٔ یکتای فایلسیستم است و همیشه به همان دیسک اشاره میکند.
گزینهٔ nofail در fstab چه میکند؟
اگر دیسک هنگام بوت در دسترس نباشد، سیستم بدون آن به بوت ادامه میدهد. بدون این گزینه، سرور ممکن است در حالت اضطراری بماند و از طریق SSH در دسترس نباشد.
ext4 بهتر است یا XFS؟
برای بیشتر کاربردهای عمومی ext4 انتخاب ساده و مطمئنی است. XFS برای فایلهای بسیار بزرگ و بار نوشتن موازی عملکرد خوبی دارد، اما قابلکوچک کردن نیست. اگر دلیل خاصی ندارید، ext4 کافی است.
اگر سرور پس از تغییر fstab بوت نشد چه کنم؟
از کنسول وب یا VNC پنل سرور وارد شوید، در حالت اضطراری رمز root را وارد کنید و خط اشتباه fstab را اصلاح یا نسخهٔ پشتیبان را برگردانید، سپس ریبوت کنید. برای جلوگیری، همیشه پیش از ریبوت mount -a را اجرا کنید.
از ۱٬۲۰۰ تومان در ساعت · پرداخت ریالی



