دیتابیس ارزشمندترین بخش هر سرویس است: سفارش‌ها، کاربران، محتوا و تراکنش‌ها. کپی کردن فایل‌های دیتابیس در حال اجرا بکاپ معتبری نمی‌سازد و انتقال یک دیتابیس چند ده گیگابایتی با روش‌های ساده ممکن است ساعت‌ها قطعی ایجاد کند. در این راهنما بکاپ و انتقال دیتابیس MySQL، MariaDB و PostgreSQL را توضیح می‌دهیم: بکاپ منطقی و فیزیکی، بازیابی در لحظه، خودکارسازی، تست بازیابی و انتقال با کمترین قطعی.
فهرست مطالب
انواع بکاپ دیتابیس
| نوع | ابزار نمونه | مزیت | محدودیت |
|---|---|---|---|
| منطقی (Logical) | mysqldump، pg_dump | قابل‌حمل بین نسخه‌ها، قابل ویرایش | بازیابی دیتابیس‌های بزرگ کند است |
| فیزیکی (Physical) | XtraBackup، Mariabackup، pg_basebackup | بکاپ و بازیابی سریع حجم بالا | وابسته به نسخه و موتور |
| Snapshot دیسک | LVM، ZFS، Snapshot سرور | تقریباً آنی | بدون هماهنگی با دیتابیس ممکن است ناسازگار باشد |
| لاگ تراکنش | Binlog، WAL | بازیابی تا یک لحظه مشخص | همراه بکاپ کامل کاربرد دارد |
Snapshot سرور به‌تنهایی بکاپ کامل نیست؛ توضیح در چرا Snapshot بکاپ نیست. اصول کلی را در بکاپ سرور چیست ببینید.
بکاپ منطقی MySQL و MariaDB
mysqldump --single-transaction --quick --routines --triggers --events \
--default-character-set=utf8mb4 appdb | gzip > appdb-$(date +%F).sql.gz--single-transaction: بکاپ سازگار از جدول‌های InnoDB بدون قفل کردن آن‌ها.--quick: خواندن ردیف‌به‌ردیف برای مصرف حافظه کم.--routines --triggers --events: توابع و رویدادها هم بکاپ شوند.utf8mb4: حفظ صحیح متن فارسی و ایموجی‌ها.
رمز را در خط فرمان ننویسید؛ در فایل ~/.my.cnf با دسترسی ۶۰۰ قرار دهید:
[client]
user=backup
password=STRONG_PASSWORDبازیابی:
gunzip < appdb-2026-10-06.sql.gz | mysql appdbبرای دیتابیس‌های بزرگ، ابزارهای موازی مثل mydumper/myloader یا mysqlsh dump utilities بسیار سریع‌ترند.
بکاپ فیزیکی با XtraBackup و Mariabackup
برای دیتابیس‌های ده‌ها گیگابایتی، بکاپ فیزیکی فایل‌های داده را در حال کار و بدون توقف کپی می‌کند:
# MySQL (Percona XtraBackup) — MariaDB: mariabackup با گزینه‌های مشابه
xtrabackup --backup --target-dir=/backup/full-$(date +%F)
xtrabackup --prepare --target-dir=/backup/full-2026-10-06مرحله --prepare بکاپ را برای بازیابی سازگار می‌کند. بازیابی با توقف سرویس و --copy-back در پوشه داده خالی انجام می‌شود. نسخه XtraBackup باید با نسخه MySQL سازگار باشد. بکاپ افزایشی هم پشتیبانی می‌شود.
بکاپ PostgreSQL
pg_dump -Fc -d appdb -f appdb-$(date +%F).dump # فرمت سفارشی فشرده
pg_restore -d appdb_new -j 4 appdb-2026-10-06.dump # بازیابی موازی
pg_dumpall --globals-only > globals.sql # کاربران و نقشهافرمت -Fc امکان بازیابی انتخابی جدول‌ها و بازیابی موازی را می‌دهد. کاربران و نقش‌ها در pg_dump نیستند؛ آن‌ها را جداگانه بکاپ بگیرید. برای بکاپ فیزیکی و PITR، ابزارهایی مثل pgBackRest یا Barman استاندارد هستند.
بازیابی در لحظه (PITR)
اگر ساعت ۱۴:۰۵ کسی به اشتباه یک جدول را حذف کند، بکاپ دیشب یعنی از دست رفتن داده‌های امروز. با نگهداری لاگ تراکنش‌ها، می‌توانید بکاپ کامل را بازیابی و لاگ‌ها را تا ۱۴:۰۴ اجرا کنید:
- MySQL/MariaDB: Binary Log را فعال (
log_bin) و فایل‌های binlog را همراه بکاپ‌ها نگه دارید؛ سپس باmysqlbinlog --stop-datetimeتا لحظه مورد نظر اجرا کنید. - PostgreSQL: آرشیو WAL با pgBackRest یا Barman و بازیابی با
recovery_target_time.
PITR هدف RPO (حداکثر داده قابل از دست رفتن) را از ساعت‌ها به دقیقه‌ها می‌رساند؛ این مفاهیم را در برنامه بازیابی از فاجعه توضیح داده‌ایم.
خودکارسازی و نگهداری
- بکاپ را با cron یا systemd timer زمان‌بندی کنید؛ راهنما در cron و systemd timers.
- از یک کاربر دیتابیس با کمترین دسترسی لازم برای بکاپ استفاده کنید.
- بکاپ‌ها را رمزنگاری و به محلی خارج از سرور منتقل کنید؛ ابزارهایی مثل restic یا Borg هر دو کار را انجام می‌دهند.
- سیاست نگهداری: مثلاً ۷ بکاپ روزانه، ۴ هفتگی و ۶ ماهانه.
- موفقیت هر اجرا را با هشدار پایش کنید تا بکاپ بی‌صدا متوقف نشود؛ نمونه در آموزش Uptime Kuma.
تست بازیابی
بکاپی که بازیابی نشده، فقط یک فایل است. به‌طور منظم:
- آخرین بکاپ را روی یک سرور یا کانتینر جداگانه بازیابی کنید.
- تعداد ردیف‌های جدول‌های اصلی و آخرین رکوردها را با تولید مقایسه کنید.
- برنامه را به نسخه بازیابی‌شده وصل و عملکرد را بررسی کنید.
- زمان کل بازیابی را ثبت کنید؛ این عدد RTO واقعی شماست.
انتقال دیتابیس با کمترین قطعی
روش ۱: Dump و Restore برای دیتابیس‌های کوچک تا متوسط. با پنجره نگهداری کوتاه: برنامه را در حالت فقط‌خواندنی یا نگهداری قرار دهید، dump بگیرید، در مقصد بازیابی کنید و برنامه را به مقصد وصل کنید. انتقال مستقیم بدون فایل میانی:
mysqldump --single-transaction --routines --triggers appdb | gzip | ssh new-db "gunzip | mysql appdb"روش ۲: Replication برای دیتابیس‌های بزرگ یا حساس به قطعی:
- یک بکاپ فیزیکی یا منطقی با موقعیت binlog (یا GTID) بگیرید و روی سرور جدید بازیابی کنید.
- سرور جدید را به‌عنوان Replica سرور فعلی تنظیم کنید تا تغییرات را دنبال کند.
- وقتی تأخیر Replica به صفر رسید، نوشتن روی سرور قدیم را متوقف کنید، از هم‌گام بودن مطمئن شوید و برنامه را به سرور جدید وصل کنید.
قطعی در این روش به چند ثانیه تا چند دقیقه می‌رسد. در PostgreSQL، Logical Replication امکان مشابهی حتی بین نسخه‌های مختلف می‌دهد.
نکات مهم انتقال:
- Character Set و Collation مبدأ و مقصد یکسان باشد؛ در غیر این صورت متن فارسی خراب می‌شود.
- کاربران و دسترسی‌های دیتابیس را هم منتقل کنید.
- اگر نسخه دیتابیس را هم ارتقا می‌دهید، تغییرات ناسازگار نسخه جدید را بررسی و روی محیط آزمایشی تست کنید.
- اتصال برنامه به دیتابیس جدید را از طریق شبکه خصوصی برقرار کنید؛ راهنما در شبکه خصوصی VPS.
برای انتقال سایت وردپرسی کامل، راهنمای انتقال وردپرس به هاست جدید را ببینید.
سوالات متداول
کپی پوشه /var/lib/mysql بکاپ معتبر است؟
فقط اگر سرویس کاملاً متوقف باشد. کپی فایل‌ها در حال اجرا، بکاپ ناسازگار و احتمالاً غیرقابل بازیابی می‌سازد. از ابزارهای بکاپ یا Snapshot هماهنگ استفاده کنید.
هر چند وقت از دیتابیس بکاپ بگیرم؟
به میزان داده‌ای بستگی دارد که می‌توانید از دست بدهید. فروشگاه‌ها و سیستم‌های تراکنشی بکاپ روزانه به‌علاوه لاگ تراکنش برای PITR لازم دارند.
بکاپ از Replica بگیرم یا سرور اصلی؟
بکاپ از Replica بار سرور اصلی را کم می‌کند، اما باید مطمئن باشید Replica هم‌گام و سالم است. Replication جایگزین بکاپ نیست؛ حذف اشتباهی فوراً به Replica هم منتقل می‌شود.
بکاپ دیتابیس داخل Docker را چطور بگیرم؟
با اجرای ابزار بکاپ داخل کانتینر: docker exec db pg_dump -Fc -U app app > app.dump. کپی Volume در حال اجرا همان مشکل کپی فایل‌های زنده را دارد. آشنایی با Docker در آموزش Docker.
بکاپ و بازیابی مطمئن
برای طراحی بکاپ دیتابیس، PITR و انتقال بدون قطعی، خدمات مدیریت سرور تراست هاست را ببینید. سرورهای مجازی با دیسک NVMe هم برای دیتابیس‌های پربار آماده‌اند.
