پرش به محتویات

۶. دیسک، پارتیشن و فایل‌سیستم

خطا در این فصل معمولاً از دست‌رفتن داده است. قبل از هر فرمان نوشتنی، دستگاه را با UUID/سریال مطمئن شوید، نه فقط نام /dev/sdX (که ممکن است بعد از ریبوت یا اتصال دیسک جدید جابه‌جا شود).

راهنمای سریع

فرمان کاربرد ریسک
df -hT / df -ih / du -xhd1 ظرفیت، inode، مصرف پوشه‌ها بدون تغییر
lsblk -f / blkid / findmnt دیسک‌ها، UUID، mount ها بدون تغییر
smartctl -H/-a / nvme smart-log سلامت دیسک بدون تغییر
pvs / vgs / lvs وضعیت LVM بدون تغییر
mount / umount / mount -a اتصال تغییر
lvextend -r / resize2fs / xfs_growfs افزایش فضا تغییر
fsck / xfs_repair ترمیم مخرب (فقط روی unmount)
mkfs / wipefs / dd / pvcreate / vgremove / lvremove ساخت/پاک‌سازی مخرب

ظرفیت و نقاط اتصال

df -hT
df -ih
df -h --output=source,fstype,size,used,avail,pcent,target
du -sh /var/log
du -xhd1 /var 2>/dev/null | sort -h
sudo ncdu -x /var                 # پیمایش تعاملی مصرف (بسته ncdu)
lsblk -f
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,UUID,MODEL,SERIAL
findmnt
findmnt -O ro                     # mount های فقط‌خواندنی (نشانهٔ مشکل!)
  • df -hT: فضای آزاد فایل‌سیستم و نوع آن.
  • df -ih: مصرف inode؛ ممکن است فضای دیسک آزاد باشد اما inode تمام شده باشد.
  • du: اندازه فایل‌ها/دایرکتوری‌ها؛ با -x از عبور به فایل‌سیستم‌های دیگر جلوگیری می‌کند.
  • lsblk -f: دیسک‌ها، پارتیشن‌ها، UUID و نوع فایل‌سیستم. به‌جای mount | column -t از findmnt استفاده کنید (خوانا و فیلترپذیر).
  • آستانه‌ها: هشدار در ۸۰٪ و بحرانی در ۹۰٪ فضا و inode؛ بعضی فایل‌سیستم‌ها بالای ۹۵٪ کند می‌شوند.

du و df با هم نمی‌خوانند؟

df فضای اشغال‌شدهٔ فایل‌سیستم را می‌گوید، du مجموع فایل‌های قابل‌مشاهده را. اختلاف معمولاً فایل حذف‌شدهٔ هنوز باز (sudo lsof +L1)، فایل‌هایی زیر یک mountpoint (زیر نقطهٔ اتصال پنهان شده‌اند)، snapshot یا فضای رزرو است.

پیدا کردن مصرف‌کنندهٔ inode

# کدام پوشه بیشترین تعداد فایل را دارد؟
sudo bash -c 'for d in /*; do [ -d "$d" ] && printf "%s %s\n" "$(find "$d" -xdev 2>/dev/null | wc -l)" "$d"; done | sort -n | tail'

بررسی دیسک و سلامت

sudo fdisk -l
sudo blkid
sudo smartctl -H /dev/sda            # خلاصهٔ سلامت (PASSED/FAILED)
sudo smartctl -a /dev/sda            # جزئیات: Reallocated, Pending, CRC
sudo smartctl -t short /dev/sda      # آزمون کوتاه (پس‌زمینه) ؛ نتیجه با -a
sudo nvme smart-log /dev/nvme0       # NVMe (بسته nvme-cli)
sudo dmesg -T | grep -Ei 'I/O error|nvme|scsi|ext4|xfs|ata[0-9]'
cat /proc/mdstat                     # RAID نرم‌افزاری
sudo mdadm --detail /dev/md0

smartctl به بسته smartmontools نیاز دارد و همه کنترلرهای RAID اطلاعات SMART را مستقیم ارائه نمی‌کنند (برای RAID سخت‌افزاری ابزار سازنده یا -d megaraid,N).

نشانه‌های خطر SMART: افزایش Reallocated_Sector_Ct، Current_Pending_Sector، Offline_Uncorrectable، UDMA_CRC_Error_Count (معمولاً کابل)، Media_Wearout/Percentage Used نزدیک ۱۰۰٪ در SSD. با اولین نشانه، بکاپ را تأیید و دیسک را برنامهٔ جایگزینی کنید؛ تعمیر نکنید.

SMART خودکار با smartd

بررسی دستی SMART کافی نیست؛ smartd آزمون‌ها را زمان‌بندی می‌کند و خرابی را گزارش می‌دهد:

sudo systemctl enable --now smartd        # نام سرویس در برخی توزیع‌ها smartmontools است
# /etc/smartd.conf — خط DEVICESCAN نمونهٔ پیش‌فرض را با این جایگزین کنید:
DEVICESCAN -a -o on -S on -s (S/../.././02|L/../01/./03) -m storage@example.internal -M test

معنی: S/../.././02 آزمون کوتاه هر شب ساعت ۰۲، L/../01/./03 آزمون بلند روز اول هر ماه ساعت ۰۳. -M test هنگام شروع سرویس یک پیام آزمایشی می‌فرستد تا مسیر هشدار را واقعاً امتحان کنید؛ بعد از اطمینان آن را بردارید. روی RAID سخت‌افزاری، شکل دستگاه (-d megaraid,N و مانند آن) فرق می‌کند.

اتصال موقت

sudo mkdir -p /mnt/data
sudo mount /dev/sdb1 /mnt/data
findmnt /mnt/data
sudo mount -o ro,noexec,nosuid,nodev /dev/sdb1 /mnt/data   # برای بررسی دیسک ناشناخته
sudo umount /mnt/data

پیش از mount مطمئن شوید دستگاه درست است (lsblk -o NAME,SIZE,MODEL,SERIAL). هنگام unmount، فرایندهای فعال ممکن است مانع شوند (target is busy):

sudo lsof +f -- /mnt/data
sudo fuser -vm /mnt/data
sudo umount -l /mnt/data    # lazy: فقط آخرین چاره (NFS گیرکرده)؛ مشکل را پنهان می‌کند

/etc/fstab

برای اتصال پایدار معمولاً از UUID استفاده می‌شود، نه نام متغیر /dev/sdX.

sudo blkid
sudo cp -a /etc/fstab /etc/fstab.bak.$(date +%F)
sudoedit /etc/fstab
sudo findmnt --verify
sudo systemctl daemon-reload
sudo mount -a                # تست اتصال بدون ریبوت؛ خطا را همین‌جا ببینید

# نمونه خط fstab — فیلدها: دستگاه  مقصد  نوع  گزینه‌ها  dump  fsck-order
UUID=1111-2222-3333  /data  ext4  defaults,noatime,nofail  0  2
  • nofail: اگر دیسک نبود، بوت در حالت emergency نمی‌ماند (برای دیسک‌های داده، نه /).
  • noexec,nosuid,nodev برای /tmp و پارتیشن‌های داده، سطح حمله را کم می‌کند.
  • ستون آخر 2 برای غیر-ریشه، 1 فقط برای /، 0 برای بدون fsck (XFS/NFS).
  • پس از تغییر fstab، آن را اعتبارسنجی کنید و پیش از reboot، اتصال‌ها را در پنجره نگهداری آزمایش کنید. خطای fstab ممکن است بوت یا اتصال فایل‌سیستم را مختل کند (کنسول لازم می‌شود).

افزایش فضا (LVM + فایل‌سیستم)

sudo pvs
sudo vgs
sudo lvs -a -o +devices
sudo pvdisplay
sudo vgdisplay
sudo lvdisplay

مسیر رایج وقتی فضای VG آزاد است:

# نمونه است؛ نام VG/LV و اندازه را با محیط خود تطبیق دهید
sudo lvextend -r -L +20G /dev/vgdata/lvapp      # -r: فایل‌سیستم را هم بزرگ می‌کند
# یا همهٔ فضای آزاد:
sudo lvextend -r -l +100%FREE /dev/vgdata/lvapp

اگر -r نمی‌خواهید، دستی: ext4 → sudo resize2fs /dev/vgdata/lvapp؛ XFS → sudo xfs_growfs /mountpoint. هر دو آنلاین قابل افزایش‌اند.

وقتی دیسک مجازی در hypervisor/ابر بزرگ شده (VM):

lsblk
sudo growpart /dev/sda 1          # بسته cloud-guest-utils / cloud-utils-growpart
sudo pvresize /dev/sda1           # اگر LVM است
sudo lvextend -r -l +100%FREE /dev/mapper/vg-root
# بدون LVM: sudo resize2fs /dev/sda1  یا  sudo xfs_growfs /

کاهش اندازه

XFS را نمی‌توان کوچک کرد. ext4 فقط unmount‌شده و با بکاپ. کاهش LV بدون کوچک‌کردن فایل‌سیستم قبلش = از بین رفتن داده. اگر مجبورید، بازسازی با انتقال داده امن‌تر است.

پیش از تغییرات LVM، نسخه پشتیبان و وضعیت RAID/storage را بررسی کنید. فرمان‌های mkfs, pvcreate, vgremove, lvremove, wipefs مخرب‌اند.

افزودن دیسک جدید به VG

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS     # دیسک جدید: FSTYPE و MOUNTPOINT خالی
sudo wipefs /dev/sdc                                   # بدون -a فقط امضاهای موجود را نشان می‌دهد
sudo pvcreate /dev/sdc
sudo vgextend vgdata /dev/sdc
sudo lvextend -r -l +100%FREE /dev/vgdata/lvapp

اگر pvcreate دربارهٔ امضای قبلی (مثلاً crypto_LUKS یا فایل‌سیستم) می‌پرسد، متوقف شوید؛ یعنی دیسک قبلاً داده داشته و ممکن است دستگاه اشتباه باشد. در اسکریپت، -y را فقط بعد از تطبیق سریال بگذارید؛ بدون آن، فرمان منتظر پاسخ می‌ماند و اسکریپت گیر می‌کند.

خالی کردن یک دیسک از VG (جایگزینی دیسک قدیمی؛ به فضای آزاد معادل در VG نیاز دارد):

sudo pvmove /dev/sdb                  # می‌تواند ساعت‌ها طول بکشد؛ قابل‌ازسرگیری است (دوباره همان فرمان)
sudo vgreduce vgdata /dev/sdb
sudo pvremove /dev/sdb

snapshot در LVM (برای بکاپ سازگار)

sudo lvs -o lv_name,lv_size,origin,snap_percent,data_percent
sudo lvcreate -s -n lvapp_snap -L 5G /dev/vgdata/lvapp     # فقط تغییرات بعد از این لحظه فضا می‌گیرد
sudo mkdir -p /mnt/snap
sudo mount -o ro /dev/vgdata/lvapp_snap /mnt/snap          # XFS: -o ro,nouuid
# ... بکاپ از /mnt/snap ...
sudo umount /mnt/snap
sudo lvremove /dev/vgdata/lvapp_snap
  • اندازهٔ snapshot باید تغییرات حین بکاپ را در خود جا بدهد؛ اگر snap_percent به ۱۰۰ برسد، snapshot نامعتبر می‌شود و بکاپ خراب یا ناقص است. در اسکریپت بعد از بکاپ، snap_percent را بررسی کنید.
  • snapshot را کوتاه‌مدت نگه دارید (کارایی نوشتن origin کم می‌شود) و آن را بکاپ نشمارید: روی همان دیسک‌هاست.
  • برای دیتابیس، snapshot بدون هماهنگی فقط «سازگار در برابر کرش» است؛ PostgreSQL و InnoDB معمولاً از آن بازیابی می‌شوند، اما بازیابی را آزمایش کنید.
  • برگرداندن origin به حالت snapshot: sudo lvconvert --merge /dev/vgdata/lvapp_snap؛ همهٔ تغییرات بعد از snapshot از بین می‌رود. اگر origin در حال استفاده است، ادغام تا فعال‌سازی بعدی (برای / تا ریبوت) به تعویق می‌افتد.

ترمیم فایل‌سیستم

sudo e2fsck -fn /dev/vgdata/lvapp       # -n: فقط بخوان، چیزی را تغییر نده (ext4)
sudo xfs_repair -n /dev/vgdata/lvapp    # فقط گزارش (XFS)
  • fsck/xfs_repair را هرگز روی فایل‌سیستم mount‌شده اجرا نکنید.
  • اگر فایل‌سیستم خود به خود ro شد: dmesg -T | tail -50 را بخوانید (خطای دیسک/کابل/ابر)؛ دلیل را بفهمید و بکاپ بگیرید، بعد ترمیم. mount -o remount,rw / فقط علامت را پنهان می‌کند.

RAID نرم‌افزاری (mdadm)

cat /proc/mdstat                                   # [UU] سالم ؛ [U_] degraded ؛ recovery = درصد بازسازی
sudo mdadm --detail /dev/md0 | grep -E 'State|Active|Working|Failed|Spare|Rebuild'
sudo mdadm --examine /dev/sdb1                     # متادیتای یک عضو
cat /sys/block/md0/md/mismatch_cnt                 # بعد از scrub
State معنی
clean / active سالم
clean, degraded یک عضو افتاده؛ داده هنوز در دسترس است ولی بدون افزونگی
recovering / resyncing در حال بازسازی؛ عملکرد افت می‌کند
FAILED افزونگی تمام شده؛ فوراً به رخداد دیسک/RAID بروید

تعویض دیسک خراب:

  1. دیسک درست را پیدا کنید: sudo mdadm --detail /dev/md0 ، سپس lsblk -o NAME,SERIAL یا sudo smartctl -i /dev/sdb | grep -i serial و با برچسب فیزیکی دیسک تطبیق دهید. کشیدن دیسک سالم در حالت degraded یعنی از دست رفتن آرایه.
  2. بکاپ را تأیید کنید. در RAID5/6 با دیسک‌های بزرگ، خرابی دیسک دوم حین بازسازی واقعی و رایج است.
  3. عضو خراب را خارج کنید:
sudo mdadm /dev/md0 --fail /dev/sdb1       # اگر خودش failed نشده
sudo mdadm /dev/md0 --remove /dev/sdb1
  1. دیسک جدید را بگذارید و جدول پارتیشن را از دیسک سالم روی دیسک جدید کپی کنید. جهت مهم است: مقصد همیشه اولین آرگومان --replicate است.
sudo sgdisk --replicate=/dev/sdb /dev/sda     # GPT: کپی جدول sda ← sdb (sdb دیسک جدید است)
sudo sgdisk -G /dev/sdb                       # GUIDهای جدید، تا با دیسک سالم یکی نباشند
# MBR: sudo sfdisk -d /dev/sda | sudo sfdisk /dev/sdb
  1. عضو جدید را اضافه و پیشرفت را دنبال کنید:
sudo mdadm /dev/md0 --add /dev/sdb1
watch -n5 cat /proc/mdstat
  1. بوت‌لودر را روی دیسک جدید هم نصب کنید (sudo grub-install /dev/sdb)، وگرنه با خرابی دیسک اول سرور بوت نمی‌شود. در UEFI، پارتیشن ESP به‌صورت پیش‌فرض آینه نمی‌شود؛ محتوایش را دستی روی دیسک دوم کپی کنید.

سرعت بازسازی: sysctl dev.raid.speed_limit_min dev.raid.speed_limit_max. بالا بردن موقت speed_limit_min بازسازی را سریع‌تر می‌کند، به قیمت کندی سرویس؛ بعد از اتمام به مقدار قبلی برگردانید.

نگهداری:

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf    # RHEL: /etc/mdadm.conf
sudo update-initramfs -u                                           # RHEL: sudo dracut -f
echo check | sudo tee /sys/block/md0/md/sync_action                # scrub دستی (Debian ماهانه خودش انجام می‌دهد)
sudo mdadm --monitor --scan --oneshot --test                       # آزمایش مسیر هشدار (MAILADDR در mdadm.conf)

mismatch_cnt غیرصفر روی RAID1 گاهی بی‌ضرر است (مثلاً swap)، اما روی داده‌های واقعی باید بررسی شود. RAID بکاپ نیست: حذف تصادفی و باج‌افزار را روی هر دو نسخه اعمال می‌کند.

swap

swapon --show
free -h
# ساخت swap file (نمونه 2GB)
sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

swap مصرفی بالا و فعالیت مداوم swap (vmstat ستون si/so غیرصفر) مشکل است؛ وجود مقداری swap اشغال‌شده الزاماً نه (کارایی).

LUKS (رمزگذاری دیسک)

lsblk -f | grep -i crypto
sudo cryptsetup status data                       # وضعیت یک volume بازشده
sudo cryptsetup luksDump /dev/sdX | head -30      # کلید-اسلات‌ها
sudo cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /root/luks-sdX-header.img
sudo cryptsetup luksAddKey /dev/sdX               # رمز/کلید دوم؛ قبل از حذف رمز قدیمی
sudo cryptsetup open /dev/sdX data && sudo mount /dev/mapper/data /mnt/data

هدر LUKS را بکاپ بگیرید

اگر هدر خراب شود، همهٔ داده برای همیشه از دست می‌رود، حتی با رمز درست. فایل هدر را رمزگذاری کنید و خارج از همان سرور نگه دارید. فایل هدر خودش به‌اندازهٔ رمز حساس است.

برای باز شدن خودکار در بوت، /etc/crypttab را با دقت تنظیم کنید (با nofail برای دیسک‌های داده)؛ ذخیرهٔ keyfile روی همان سرور فقط در برابر برداشتن فیزیکی دیسک محافظت می‌کند، نه نفوذ به سیستم.

TRIM و فضای رزرو

sudo fstrim -av                        # SSD/ابر thin (معمولاً timer هفتگی fstrim.timer)
systemctl status fstrim.timer --no-pager
sudo tune2fs -l /dev/sdb1 | grep -i 'reserved block'   # ext4: پیش‌فرض ۵٪ برای root
# برای دیسک داده بزرگ، ۱٪ کافی است (با احتیاط):
# sudo tune2fs -m 1 /dev/sdb1

خطاهای رایج

نشانه علت احتمالی روش بررسی
No space left on device ولی df آزاد inode تمام شده df -ih
df پر، du کم فایل حذف‌شده و باز / mount روی داده sudo lsof +L1 ، findmnt
target is busy پردازش یا shell داخل mount lsof +f -- PATH ، fuser -vm
بوت در emergency mode بعد از ویرایش fstab خط نامعتبر / دیسک نیست کنسول؛ nofail ؛ ویرایش fstab
فایل‌سیستم ناگهان read-only خطای I/O (ext4 errors=remount-ro) dmesg -T ، SMART ، کابل/SAN
wrong fs type, bad option, bad superblock نوع/گزینه اشتباه یا فایل‌سیستم خراب blkid ، dmesg
lvextend موفق ولی df تغییر نکرد فایل‌سیستم resize نشده resize2fs / xfs_growfs یا -r
Device or resource busy هنگام wipefs/mkfs هنوز mount/عضو LVM/RAID lsblk ، pvs ، /proc/mdstat
pvcreate سؤال می‌پرسد/اسکریپت گیر کرده دیسک امضای قبلی دارد (دستگاه اشتباه؟) wipefs /dev/XXX ، سریال را تطبیق دهید
RAID [U_] / degraded عضوی افتاده mdadm --detail ، بخش «تعویض دیسک خراب»
snapshot ناگهان نامعتبر شد پر شدن فضای CoW lvs -o +snap_percent ؛ اندازهٔ بزرگ‌تر

نکات امنیتی و عملیاتی

  • قبل از هر mkfs/dd/wipefs: lsblk -o NAME,SIZE,MODEL,SERIAL,MOUNTPOINTS و نام دستگاه را با صدای بلند با سریال تطبیق دهید. جایگزین بی‌خطر: dd ... of=/dev/XXX را هرگز از history اجرا نکنید.
  • قبل از تغییر ساختار دیسک: بکاپ تأییدشده یا snapshot (پشتیبان‌گیری).
  • هشدار ظرفیت (فضا + inode) و SMART را در مانیتورینگ تعریف کنید؛ دیسک پر شدن یک رخداد قابل‌پیش‌بینی است.
  • برای داده‌های حساس: رمزگذاری (LUKS) و مدیریت کلید.

خلاصهٔ اجرایی

  1. همیشه df -hT و df -ih.
  2. UUID/سریال، نه /dev/sdX؛ nofail برای دیسک‌های داده.
  3. lvextend -r برای افزایش؛ کاهش را اجتناب کنید.
  4. fsck فقط روی unmount؛ اول -n.
  5. SMART/mdstat را مانیتور کنید؛ با اولین نشانه بکاپ را تأیید کنید.
  6. قبل از کشیدن دیسک، سریال را تطبیق دهید؛ هدر LUKS را بکاپ بگیرید؛ snapshot و RAID بکاپ نیستند.