محتوای آموزشی وبلاگ نت‌آرام
برای بکاپ یک دیسک جداگانه در نظر گرفته‌اید و مسیر آن مثلاً
/backup است. مدتی بعد می‌بینید فضای دیسک اصلی سرور پر شده، در حالی که انتظار داشتید بکاپ‌ها روی دیسک دوم باشند. یک علت رایج این است که دیسک دوم متصل نشده یا به اصطلاح mount نشده است؛ پوشه /backup همچنان وجود دارد، اما دیگر پنجره‌ای به دیسک دوم نیست و فایل‌های جدید روی فایل‌سیستم اصلی نوشته می‌شوند.این مسئله می‌تواند روی سرور مجازی ایران یا سرور اختصاصی ایران رخ دهد. در مثال‌ها مسیر فرضی
/backup است؛ مسیر واقعی برنامه خود را جایگزین کنید. دستورها در ترمینال سرور لینوکسی و با کاربر دارای دسترسی sudo اجرا می‌شوند. قبل از جابه‌جایی یا حذف هر بکاپ، مطمئن شوید نسخه قابل بازیابی دیگری در محل امن دارید.۱. ببینید برنامه واقعاً کجا می‌نویسد
اول مسیر مقصد را از تنظیمات برنامه بکاپ یا دستور زمان‌بندی‌شده پیدا کنید. فرض کنیم مقصد
کد / دستور/backup است. این دستور نشان می‌دهد آن مسیر در حال حاضر روی کدام فایل‌سیستم قرار گرفته است:df -hT /backup
ستون‌های
کد / دستورFilesystem و Mounted on را بخوانید. اگر مسیر روی همان فایل‌سیستمی است که / را نگه می‌دارد، ممکن است دیسک جداگانه مانت نشده باشد. برای مقایسه:df -hT /
یکسان بودن نام فایل‌سیستم در این دو خروجی سرنخ است، اما اگر آگاهانه بکاپ را روی همان دیسک اصلی تنظیم کرده‌اید طبیعی است. حالا دقیق‌تر بررسی کنید آیا خود
کد / دستور/backup نقطه مانت است:mountpoint /backup
پیام
is not a mountpoint یعنی در لحظه اجرای دستور، فایل‌سیستم جداگانه مستقیماً در آن نقطه متصل نیست. ممکن است برنامه شما عمداً از زیرپوشه یک مانت دیگر استفاده کند؛ در آن حالت نقطه مانت واقعی را در تنظیمات پیدا کنید.۲. منبع متصل‌شده را با مقصد مورد انتظار مقایسه کنید
کد / دستورfindmnt -T /backup -o TARGET,SOURCE,FSTYPE,OPTIONS
findmnt -T فایل‌سیستمی را نشان می‌دهد که مسیر را پوشش می‌دهد؛ اگر دیسک بکاپ وصل نباشد، ممکن است خروجی همچنان / را نشان دهد. برای بررسی مانت دقیق همان پوشه:findmnt -M /backup -o TARGET,SOURCE,FSTYPE,OPTIONS
در خروجی دوم،
کد / دستورSOURCE را با دیسک یا آدرس فضای پشتیبان مورد انتظار مقایسه کنید. وجود یک مانت کافی نیست؛ ممکن است دیسک اشتباه در مسیر درست وصل شده باشد. برای دیسک‌های بلوکی می‌توانید شناسه‌ها را ببینید:lsblk -f
ستون‌های
UUID و MOUNTPOINTS یا در برخی نسخه‌ها MOUNTPOINT کمک می‌کنند دیسک و محل اتصال آن را شناسایی کنید. NFS، فضای شبکه و bind mount لزوماً UUID دیسک محلی ندارند؛ منبع آن‌ها را با اطلاعات ارائه‌دهنده و تنظیمات خود تطبیق دهید.اگر
کد / دستور/backup مانت نیست، اندازه فایل‌های فعلی همان پوشه را بدون عبور از فایل‌سیستم‌های دیگر ببینید:sudo du -xsh /backup
عدد بزرگ نشان می‌دهد ممکن است فایل‌های قابل توجهی در پوشه زیرین ذخیره شده باشند. این دستور به شما اجازه حذف هیچ فایلی را نمی‌دهد و برای بکاپ فعال ممکن است مقدار هنگام اجرا تغییر کند.
۳. جلوی ادامه نوشتن در مقصد اشتباه را بگیرید
کار بکاپ را طبق روش نرم‌افزار خود موقتاً متوقف یا زمان‌بندی آن را غیرفعال کنید؛ نام سرویس و اثر توقف در هر سیستم متفاوت است. اگر بکاپ در حال نوشتن است، پیش از جابه‌جایی داده صبر کنید تا کار به شکل امن پایان یابد یا طبق راهنمای همان ابزار متوقف شود. درباره مقصد، حجم، تاریخ و زمان توقف یادداشت بردارید.
برای دیدن فایل‌های زمان‌بندی کاربر جاری:
کد / دستورcrontab -l
برای root، در صورتی که کار بکاپ متعلق به root است:
کد / دستورsudo crontab -l
اگر پیام نبود crontab دیدید، ممکن است زمان‌بندی با systemd، کنترل‌پنل یا ابزار دیگری انجام شود. کورکورانه همه cronها را متوقف نکنید. اگر کار با systemd مدیریت می‌شود، نام واقعی آن را از فهرست زیر پیدا کنید:
کد / دستورsystemctl list-timers --all
۴. چرا بعد از مانت‌کردن، فایل‌ها ظاهراً ناپدید می‌شوند؟
وقتی دیسک درست را روی
/backup مانت کنید، فایل‌هایی که پیش‌تر در پوشه زیرین روی دیسک اصلی نوشته شده‌اند معمولاً پشت مانت پنهان می‌شوند؛ خودبه‌خود حذف یا به دیسک بکاپ منتقل نمی‌شوند و همچنان فضای دیسک اصلی را اشغال می‌کنند. بنابراین دیدن بکاپ‌های قدیمی روی دیسک متصل، به معنی آزادشدن فضای اشغال‌شده در پوشه زیرین نیست.قبل از اتصال مجدد، فهرست فایل‌های موجود را بررسی و هر نسخه لازم را در یک مقصد امن دیگر کپی کنید. مطمئن شوید مقصد کپی خودش روی همان دیسک پر نیست و پس از کپی، اندازه و امکان بازیابی نسخه را بررسی کنید. اگر دیسک بکاپ اکنون مانت است و فایل‌های زیرین پنهان شده‌اند، برای بازکردن آن مانت در زمان سرویس‌دهی عجله نکنید؛ ابتدا وابستگی برنامه‌ها را مشخص و یک بازه نگهداری انتخاب کنید. حذف فایل‌هایی که هویت یا سلامت نسخه جایگزینشان مشخص نیست، راه‌حل مناسبی برای آزادکردن فضا نیست.
۵. مقصد اصلی را دوباره متصل کنید
اگر فایل‌سیستم بکاپ در
کد / دستور/etc/fstab با مسیر /backup به‌درستی تعریف شده و منبع آن را می‌شناسید، ابتدا خط مربوط را ببینید:grep -n '/backup' /etc/fstab
از روی این خروجی، UUID یا منبع شبکه و نوع فایل‌سیستم را با دیسک اختصاص‌یافته مقایسه کنید. اگر دستگاه یا شبکه مشکل دارد، اول همان علت را رفع کنید. پس از اطمینان از درست‌بودن تعریف و اثر مانت بر فایل‌های زیرین، می‌توانید فقط همان مقصد را متصل کنید:
کد / دستورsudo mount /backup
اگر خطا داد، متن آن را بخوانید؛ اجرای
کد / دستورmount -a روی سرور عملیاتی می‌تواند فایل‌سیستم‌های دیگری را نیز تحت تأثیر قرار دهد و برای این آزمون لازم نیست. سپس این دو دستور را تکرار کنید:mountpoint /backup
کد / دستورfindmnt -M /backup -o TARGET,SOURCE,FSTYPE,OPTIONS
اگر مقصد مانت است اما منبع صحیح نیست، کار بکاپ را شروع نکنید. اگر منبع درست است، فضای خالی آن را با
df -hT /backup ببینید و یک آزمون کوچک و قابل حذف در پوشه آزمایشی مورد تأیید خود انجام دهید. بررسی کنید چه کاربری اجازه نوشتن دارد و فایل‌ها به‌صورت عمومی در وب قابل دانلود نباشند.۶. کاری کنید بکاپ در نبود مقصد اجرا نشود
راهکار باید با نرم‌افزار بکاپ شما سازگار باشد. برای یک دیسک محلی با UUID مشخص، می‌توان پیش از دستور اصلی بررسی کرد که هم مسیر مانت است و هم UUID همان دیسک مورد انتظار است. این یک نمونه اسکریپت است؛ آن را داخل فایل اسکریپت خود و قبل از خط اجرای بکاپ بگذارید، نه در فایلی که محتوایش را نمی‌شناسید:
کد / دستور#!/bin/sh
set -eu
backup_mount='/backup'
expected_uuid='UUID-REAL-BACKUP-DISK'
if ! mountpoint -q "$backup_mount"; then
echo 'Backup stopped: destination is not mounted' >&2
exit 1
fi
actual_uuid="$(findmnt -n -M "$backup_mount" -o UUID)"
if [ -z "$actual_uuid" ] || [ "$actual_uuid" != "$expected_uuid" ]; then
echo 'Backup stopped: unexpected destination UUID' >&2
exit 1
fi
# دستور بکاپ موجود خود را فقط پس از این بررسی قرار دهید.
به‌جای مقدار نمونه، UUID واقعی را از خروجی
lsblk -f و اطلاعات دیسک خود بگذارید. این روش برای مقصدهای بدون UUID، مانند بسیاری از مسیرهای شبکه، مناسب نیست؛ در آن‌ها باید منبع مورد انتظار و وضعیت mount را با روشی متناسب با همان سرویس بررسی کنید. دسترسی اسکریپت و مسیر اجرا را با مدیر سیستم تطبیق دهید. هنگام بازنویسی cron یا systemd، کار قبلی را دوباره به‌صورت جداگانه اضافه نکنید، چون ممکن است دو بکاپ هم‌زمان بسازید.اگر بکاپ به‌صورت یک سرویس systemd اجرا می‌شود، گزینه
RequiresMountsFor= می‌تواند وابستگی به مانت‌های لازم را ایجاد کند، ولی به‌تنهایی ثابت نمی‌کند منبع مورد نظر شما متصل است. طبق مستندات systemd، آن را باید با بررسی مقصد واقعی و هشدار مناسب ترکیب کنید. اگر نگهبان از اجرای بکاپ جلوگیری کرد، حتماً آن را به یک هشدار قابل مشاهده وصل کنید؛ بکاپ اجرا‌نشده نباید بی‌صدا سالم به نظر برسد.۷. تأیید نهایی
بعد از اصلاح، یک اجرای کنترل‌شده انجام دهید و لاگ آن را بخوانید. بررسی کنید فایل تازه روی منبع درست ساخته شده، حجم و تاریخ آن منطقی است و یک بازیابی آزمایشی در محیط جداگانه موفق می‌شود. سپس با یک آزمون امن در محیط آزمایشی، نبود مقصد را شبیه‌سازی کنید و مطمئن شوید دستور بکاپ اجرا نمی‌شود و هشدار دریافت می‌کنید. مانت جداگانه به‌تنهایی جای نسخه خارج از سرور را نمی‌گیرد؛ تفاوت snapshot و بکاپ را هم ببینید.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام