فایل بکاپ ساخته شده، اما آیا می توان با آن سایت را برگرداند؟ این سوال از حجم فایل و پیام موفقیت مهم تر است. برای بکاپ دیتابیس MySQL با mysqldump باید سه چیز کنار هم قرار بگیرند: خروجی سازگار با داده، نگهداری نسخه ای مستقل و بازیابی موفق در محیط آزمایشی. تا بخش آخر انجام نشده، فقط یک فایل SQL داریم که هنوز کارایی آن را نمی دانیم.
این راهنما برای خروجی منطقی از یک دیتابیس برنامه نوشته شده است؛ مثلا پایگاه داده یک فروشگاه کوچک. هدف، کپی کردن همه دیتابیس های سرور یا ساختن replica نیست. فرمان ها نمونه هستند و نام کاربر، نام دیتابیس و مسیر فایل باید با محیط شما تطبیق داده شود. بازیابی را فقط روی یک سرور آزمایشی جدا انجام می دهیم و به دیتابیس فعال سایت دست نمی زنیم.
فرمان های چندخطی این مطلب برای Bash در لینوکس نوشته شده اند. علامت \ ادامه همان فرمان در خط بعد است و < فایل را به ورودی ابزار بازیابی می دهد؛ این قالب را عینا در PowerShell کپی نکنید.
قبل از انتخاب فرمان، معلوم کنید چه چیزی باید برگردد
فرض کنیم فروشگاه فرضی «سپید» سفارش ها را در MySQL نگه می دارد. تصویر محصولات در پوشه فایل هاست و کلیدهای اتصال به درگاه در تنظیمات برنامه ذخیره شده اند. خروجی دیتابیس، به تنهایی نسخه کامل این فروشگاه نیست. اگر تصویرها یا فایل تنظیمات از دست بروند، داشتن جدول سفارش ها تمام مشکل را حل نمی کند. فهرست اقلام لازم برای بازیابی را پیش از شروع بنویسید.
زمان قابل قبول از دست رفتن داده نیز باید روشن باشد. اگر یک نسخه شبانه تهیه می شود، سفارش های بعد از آن در همان فایل وجود ندارند. بازیابی تا یک لحظه مشخص، به برنامه جداگانه و نگهداری مناسب binary log نیاز دارد؛ یک dump معمولی چنین وعده ای نمی دهد. برای هماهنگی برنامه دیتابیس با فایل های سایت می توانید موضوع را در درخواست مدیریت سرور با جزئیات مطرح کنید.
نسخه ابزار را از نسخه سرور جدا ببینید
نصب بودن فرمان mysqldump کافی نیست. ابزار روی دستگاهی اجرا می شود که ممکن است نسخه دیگری از MySQL داشته باشد. همچنین بعضی بسته ها در واقع MariaDB هستند. قبل از خروجی، نسخه ابزار و سرور مبدا را ثبت کنید. فرمان زیر فقط اطلاعات نسخه و موتور جدول های دیتابیس نمونه را می خواند. نام shop_db و کاربر backup_reader فرضی هستند:
mysqldump --version
mysql --version
mysql --user=backup_reader --password --execute="SELECT VERSION(); SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='shop_db';"
سازگاری را با نسخه مقصد هم بررسی کنید. collation، قابلیت های SQL و تعریف اشیا ممکن است بین نسخه ها تفاوت داشته باشند. خروجی گرفتن با ابزار جدیدتر، تضمین وارد شدن فایل به سرور قدیمی تر نیست. در MariaDB ابزار اصلی mariadb-dump است و بعضی خروجی های جدید آن فرمان sandbox دارند که کلاینت قدیمی یا mysql آن را نمی شناسد. این تفاوت در مستندات رسمی mariadb-dump توضیح داده شده است. فرمان MySQL این مقاله را بدون بررسی به MariaDB تعمیم ندهید.
| بررسی پیش از بکاپ | چرا لازم است؟ | نتیجه قابل قبول |
|---|---|---|
| نسخه مبدا، ابزار و مقصد | جلوگیری از ناسازگاری هنگام import | نسخه ها ثبت و در محیط آزمایشی امتحان شده اند |
| موتور جدول ها | روش snapshot برای همه موتور ها یکسان نیست | جدول های غیر InnoDB شناسایی شده اند |
| رویدادها و برنامه های ذخیره شده | صرف داشتن جدول ها کافی نیست | اشیای مورد نیاز در خروجی و آزمون وجود دارند |
| فضای مقصد و دسترسی فایل | خروجی ناقص یا افشای داده ممکن است | فضای کافی، مسیر خصوصی و مجوز محدود وجود دارد |
single-transaction کجا کمک می کند و کجا کافی نیست؟
گزینه single-transaction برای جدول های تراکنشی مانند InnoDB، نمای سازگاری از داده در زمان آغاز تراکنش می سازد. این رفتار را نباید به MyISAM یا MEMORY نسبت داد. اگر جدول غیرتراکنشی دارید، برای هماهنگی داده های آن باید روش مناسب همان محیط انتخاب شود؛ شاید پنجره نگهداری و کنترل نوشتن لازم باشد.
همزمان با این خروجی، تغییر ساختار جدول ها را متوقف کنید. اجرای ALTER، DROP، RENAME یا TRUNCATE روی جدول مورد خروجی می تواند نتیجه را خراب کند یا فرمان را شکست دهد. بهتر است انتشار نسخه برنامه و migration دیتابیس با زمان بکاپ تداخل نداشته باشد. همچنین خروجی خواندن سنگینی ایجاد می کند؛ اولین اجرا را در ساعت شلوغ فروشگاه قرار ندهید. محدودیت های این گزینه در راهنمای رسمی mysqldump آمده است.
یک خروجی مشخص برای یک دیتابیس
ابتدا وارد یک پوشه خصوصی با فضای کافی شوید. نام فایل را برای هر اجرا تازه انتخاب کنید؛ result-file می تواند فایل قبلی را بازنویسی کند. فایل SQL را داخل public_html یا هر مسیر قابل دانلود از وب قرار ندهید. حساب بکاپ باید دسترسی های لازم همان اشیا را داشته باشد و دسترسی مدیریتی سراسری را راه حل هر خطای مجوز ندانید.
mysqldump --user=backup_reader --password \
--single-transaction --quick --no-tablespaces \
--set-gtid-purged=OFF --routines --events --triggers \
--result-file=shop_db-2026-11-10.sql shop_db
در این نمونه رمز بعد از درخواست ابزار وارد می شود؛ آن را به شکل password=SECRET در فرمان ننویسید. برای خودکارسازی، روش نگهداری اعتبارنامه با دسترسی محدود و مطابق سیاست سرور لازم است. mysql_config_editor یکی از ابزارهای MySQL برای مدیریت اطلاعات اتصال است، اما فایل آن را نباید معادل یک گاوصندوق نفوذناپذیر دانست.
گزینه quick داده ها را تدریجی می خواند. routines و events برای اشیایی هستند که ممکن است برنامه به آنها متکی باشد؛ triggers نیز صریح نوشته شده است. مطابق راهنمای برنامه های ذخیره شده MySQL، روی پیش فرض همه اشیا حساب نکنید. انتخاب GTID در این فرمان برای آزمون مستقل است و زنجیره replication را حفظ نمی کند؛ برای replica یا بازیابی نقطه ای، این نسخه را عینا استفاده نکنید.
فایل ساخته شد؛ هنوز کار تمام نشده
کد خروج فرمان و پیام خطا را همان لحظه بررسی کنید. وجود فایل یا بزرگ بودن آن نشانه موفقیت نیست؛ فایل ناقص هم می تواند حجم زیادی داشته باشد. اگر مجوز یک view یا routine کم بود، علت را مشخص کنید و خروجی تازه بگیرید. گزینه force که از خطا عبور می کند، راه مناسبی برای ساختن نسخه قابل اعتماد نیست. نام اجرا، زمان شروع و پایان، نسخه ابزار و نتیجه را در گزارش بکاپ ثبت کنید.
سپس نسخه ای را با مسیر امن به محل مستقل منتقل کنید. ماندن تنها کپی کنار دیتابیس، در خرابی سرور یا حذف حساب کمکی نمی کند. برای تشخیص تغییر ناخواسته فایل می توان checksum را قبل و بعد از انتقال مقایسه کرد؛ یکسان بودن آن فقط سلامت انتقال را نشان می دهد، نه درستی محتوای دیتابیس. فایل بکاپ شامل داده حساس است و محدودیت دسترسی و رمزگذاری محل نگهداری باید متناسب با اطلاعات آن باشد.
بازیابی آزمایشی بدون نزدیک شدن به دیتابیس اصلی
یک محیط جدا و سازگار آماده کنید که به درگاه پرداخت، سرویس پیامک و مشتری واقعی وصل نباشد. دیتابیس خالی shop_restore و حساب restore_lab را فقط در همان محیط بسازید. این حساب نباید به دیتابیس اصلی دسترسی داشته باشد. فرض فرمان بعدی این است که نمونه آزمایشی فقط روی 127.0.0.1 و پورت 3307 در دسترس است؛ این نشانی و پورت تضمین جدایی نیستند و باید واقعا متعلق به محیط آزمایش باشند.
چون خروجی شامل events است، پیش از import مدیر همان نمونه آزمایشی باید Event Scheduler دیتابیس را متوقف کند و با SHOW GLOBAL VARIABLES LIKE 'event_scheduler'; مقدار OFF یا DISABLED را تایید کند. خاموش کردن cron برنامه کافی نیست؛ رویدادهای داخل MySQL زمان بند مستقل دارند. مطابق مستندات Event Scheduler، این دو وضعیت از اجرای رویدادهای زمان بندی شده جلوگیری می کنند. آن را تا پایان این آزمون خاموش نگه دارید؛ این تغییر فقط برای نمونه جدا است و روی دیتابیس اصلی انجام نمی شود.
mysql --protocol=TCP --host=127.0.0.1 --port=3307 \
--user=restore_lab --password --database=shop_restore \
< shop_db-2026-11-10.sql
قبل از اجرا، محتوای SQL و نام دیتابیس های ارجاع داده شده را بررسی کنید. وجود USE، نام کامل جدول یا DEFINER ممکن است مقصد یا مجوز دیگری بخواهد. مثال ما از گزینه databases استفاده نکرده تا خروجی معمول یک دیتابیس، فرمان انتخاب دیتابیس مبدا را اضافه نکند؛ رفتار دقیق را در توضیح قالب خروجی MySQL ببینید. با این حال بررسی فایل و جداسازی محیط همچنان لازم است.
روش بارگذاری فایل SQL در راهنمای بازیابی MySQL آمده است. خطای collation یا DEFINER را با حذف تصادفی خطوط حل نکنید. ابتدا نسخه و تعریف حساب ها را تطبیق دهید، سپس راه حل را روی کپی فایل امتحان کنید. فایل اصلی بکاپ باید دست نخورده بماند تا تغییرات آزمون قابل پیگیری باشند.
چه زمانی می توان به نتیجه اعتماد کرد؟
فقط پیام پایان import را بررسی نکنید. جدول های لازم، view ها، trigger ها و routine های مورد استفاده باید موجود باشند. چند رکورد قدیمی و جدید، متن فارسی، مقدارهای مالی و ارتباط سفارش با اقلامش را کنترل کنید. اگر برنامه را به دیتابیس آزمایشی وصل می کنید، ارسال ایمیل، پرداخت، cron و ارتباطات بیرونی را غیرفعال نگه دارید. شمارش ساده ردیف ها به تنهایی صحت تمام روابط را اثبات نمی کند.
در همان فروشگاه فرضی، آزمون وقتی ارزش دارد که صفحه یک سفارش و اقلام آن درست باز شود و عملیات آزمایشی در محیط جدا کار کند. مدت انتقال و import را هم ثبت کنید؛ اگر بازیابی از زمان تحمل کسب و کار بیشتر است، باید روش بکاپ را بازنگری کرد. برای برنامه ریزی این کار روی سرور مجازی ایران، ظرفیت دیسک و منابع محیط آزمایش را نیز از ابتدا در نظر بگیرید.
چند سوال رایج درباره بکاپ دیتابیس MySQL
آیا mysqldump برای هر دیتابیس بزرگی مناسب است؟
الزاما نه. زمان خروجی، بار خواندن و زمان بازیابی را بسنجید. اگر با نیاز شما سازگار نیست، ابزار یا روش دیگری باید بررسی شود؛ حجم فایل تنها معیار انتخاب نیست.
آیا برای وردپرس همین فایل کافی است؟
خیر. فایل های سایت، رسانه ها و تنظیمات لازم هم باید با برنامه دیتابیس هماهنگ باشند. بدون آنها ممکن است سایت کامل برنگردد.
هر چند وقت یک بار بازیابی را امتحان کنیم؟
فاصله آزمون به تغییرات و حساسیت سرویس بستگی دارد. بعد از تغییر نسخه دیتابیس، ابزار یا روش بکاپ، آزمون تازه انجام دهید و نتیجه قبلی را کافی ندانید.
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.