فرآیند بازیابی دیتابیس برای یک ساعت خاص

فرآیند بازیابی دیتابیس برای یک ساعت خاص

گاهی در مدیریت دیتابیس، بازگرداندن آخرین نسخه Backup کافی نیست.
ممکن است اطلاعاتی به‌اشتباه حذف شده باشد، یک Query مخرب اجرا شده باشد یا بخشی از داده‌ها در یک ساعت مشخص دچار تغییرات ناخواسته شده باشند.
در چنین شرایطی، یکی از بهترین راهکارها  Point-in-Time Recovery یا PITR است.
PITR به مدیر دیتابیس اجازه می‌دهد اطلاعات را به یک نقطه زمانی مشخص  برگرداند؛ برای مثال، دیتابیس را به ساعت 14:30 روز گذشته بازگرداند، بدون اینکه الزاماً تمام تغییرات بعد از آخرین Backup از بین بروند.

Point-in-Time Recovery چیست؟

Point-in-Time Recovery به معنای «بازیابی در یک نقطه زمانی مشخص» است.
در این روش، ابتدا یک Full Backup یا Base Backup بازیابی می‌شود و سپس تغییرات ثبت‌شده در Logهای دیتابیس تا زمان موردنظر دوباره روی دیتابیس اعمال می‌شوند.
به زبان ساده:

Full Backup + Transaction Logs = Point-in-Time Recovery

برای مثال، فرض کنید آخرین Backup کامل در ساعت 00:00 گرفته شده و یک عملیات اشتباه در ساعت 14:25 انجام شده است.
اگر بخواهیم دیتابیس را به ساعت 14:24:59 برگردانیم، تنها Restore کردن Backup ساعت 00:00 کافی نیست؛ زیرا اطلاعات سالم بین ساعت 00:00 تا 14:24 نیز باید حفظ شوند.
در MySQL، Binary Log و در PostgreSQL، WAL نقش مهمی در این فرآیند دارند.

🌟آیا می‌خواهید به یک متخصص پایگاه داده تبدیل شوید و در دنیای فناوری اطلاعات بدرخشید؟

با دوره آموزشی SQL Server ما، شما می‌توانید به راحتی و با روشی عملی، تمام مهارت‌های لازم را یاد بگیرید!

این دوره به شما آموزش می‌دهد که چگونه داده‌ها را به بهترین شکل مدیریت کنید، گزارش‌های قدرتمند بسازید و به تحلیل‌های عمیق دست یابید.

با محتوای جذاب و پروژه‌های واقعی، شما نه تنها تئوری را یاد می‌گیرید، بلکه توانایی‌های عملی خود را نیز تقویت می‌کنید.

پس فرصت را از دست ندهید! همین امروز به جمع یادگیرندگان ما بپیوندید و اولین قدم را به سوی آینده شغلی روشن‌تر بردارید!

 ⇐همین حالا شروع کنید و به دنیای داده‌ها بپیوندید!

چرا بازیابی دیتابیس به یک ساعت خاص اهمیت دارد؟

فرض کنید مدیر سیستم به‌اشتباه دستور زیر را اجرا کند:

DROP TABLE customers;

اگر آخرین Backup مربوط به نیمه‌شب باشد، Restore کردن آن Backup باعث از دست رفتن تمام تغییرات ایجادشده از نیمه‌شب تا زمان حادثه می‌شود.
اما با PITR می‌توان دیتابیس را به لحظه‌ای درست قبل از اجرای دستور مخرب بازگرداند.

مهم‌ترین کاربردهای PITR

عبارت‌اند از:

• بازیابی اطلاعات حذف‌شده

• مقابله با خطای انسانی

• بازگردانی دیتابیس بعد از اجرای Query اشتباه

• بازیابی پس از خرابی نرم‌افزاری

• Disaster Recovery

• بررسی وضعیت دیتابیس در یک زمان مشخص

• کاهش میزان Data Loss
  
  
  

فرآیند کلی بازیابی دیتابیس

فرآیند بازیابی دیتابیس به یک ساعت خاص معمولاً شامل مراحل زیر است:

1. مشخص کردن زمان دقیق حادثه

2. تعیین زمان هدف برای Recovery

3. پیدا کردن آخرین Backup معتبر قبل از زمان هدف

4. بررسی سالم بودن Backup

5. پیدا کردن Logهای موردنیاز

6. Restore کردن Backup

7. Replay کردن Logها

8. متوقف کردن Recovery در زمان موردنظر

9. بررسی صحت داده‌ها

10. انتقال دیتابیس بازیابی‌شده به Production در صورت نیاز

به‌صورت ساده:

Full Backup
     ↓
Restore
     ↓
Transaction Logs
     ↓
Replay Changes
     ↓
Target Time
     ↓
Recovered Database

 پیش‌نیازهای PITR

برای اینکه بتوانید دیتابیس را به یک ساعت خاص برگردانید، زیرساخت Backup باید از قبل به شکل صحیح تنظیم شده باشد.

1. Full یا Base Backup

ابتدا باید یک Backup معتبر داشته باشید. برای مثال:

Backup: 2026-08-18 00:00:00
Target: 2026-08-18 14:30:00

در این حالت Backup ساعت 00:00 نقطه شروع Recovery خواهد بود.

2. Transaction Logs

Backup به‌تنهایی برای PITR کافی نیست. باید Log تغییرات دیتابیس نیز در دسترس باشد.
در MySQL معمولاً از Binary Log و در PostgreSQL از WAL استفاده می‌شود.
PostgreSQL با آرشیو کردن WAL در کنار Base Backup امکان بازیابی دیتابیس تا یک نقطه زمانی مشخص را فراهم می‌کند.

3. نگهداری صحیح Backup و Log

اگر بخشی از Logهای بین زمان Backup و زمان هدف از بین رفته باشد، ممکن است Recovery دقیق تا زمان موردنظر امکان‌پذیر نباشد.
بنابراین Backup و Log باید دارای سیاست مشخصی برای نگهداری، امنیت و بررسی سلامت باشند.

بازیابی دیتابیس MySQL به یک ساعت خاص

در MySQL، Point-in-Time Recovery عمدتاً بر پایه Binary Log انجام می‌شود.
پس از Restore کردن Full Backup، رویدادهای Binary Log از زمان Backup تا زمان هدف دوباره اجرا می‌شوند.
ابزار  mysqlbinlog برای کار با این Logها مورد استفاده قرار می‌گیرد.
ابتدا می‌توان Binary Logهای موجود را بررسی کرد:

SHOW BINARY LOGS;

پس از پیدا کردن Backup مناسب، آن را روی یک محیط Recovery Restore می‌کنیم:

mysql -u root -p database_name < backup.sql

در مرحله بعد، Binary Logهای موردنیاز Replay می‌شوند.
نکته مهم این است که نباید تمام Logها بدون تعیین نقطه توقف اجرا شوند؛ زیرا هدف PITR، رسیدن به یک زمان مشخص است.
برای مثال:

00:00 ───────────── 14:24:59 ───── 14:25:00
 │                       │               │
Backup                 Target          حادثه

اگر عملیات مخرب در ساعت 14:25 انجام شده باشد، هدف می‌تواند بازیابی دیتابیس تا قبل از آن عملیات باشد.

بازیابی دیتابیس PostgreSQL به یک ساعت خاص

PostgreSQL برای PITR از Base Backup و WAL استفاده می‌کند.
WAL یا Write-Ahead Log تغییرات دیتابیس را ثبت می‌کند و در صورت Archive شدن می‌تواند برای Recovery مورد استفاده قرار گیرد.
در PostgreSQL می‌توان یک  Recovery Target  تعریف کرد.
یکی از گزینه‌های مرتبط با این موضوع recovery_target_time است که برای تعیین زمان موردنظر Recovery استفاده می‌شود.
برای مثال:

recovery_target_time = '2026-08-18 14:30:00'

در این حالت Recovery تلاش می‌کند دیتابیس را تا نقطه زمانی تعیین‌شده پیش ببرد.

یک مثال واقعی

فرض کنید دیتابیس یک فروشگاه آنلاین در شرایط زیر قرار دارد:

Full Backup:
2026-08-18 00:00:00
خطای انسانی:
2026-08-18 14:25:10
زمان هدف:
2026-08-18 14:25:00

در این سناریو ابتدا سیستم یا دیتابیس موردنظر برای Recovery آماده می‌شود.
سپس Backup ساعت 00:00 روی یک سرور جداگانه Restore خواهد شد.
در مرحله بعد، Logهای موجود از ساعت 00:00 تا 14:25 Replay می‌شوند.
پس از رسیدن به زمان هدف، Recovery متوقف شده و داده‌ها بررسی می‌شوند.
در صورتی که اطلاعات صحیح باشند، می‌توان دیتابیس بازیابی‌شده را برای جایگزینی یا انتقال اطلاعات به محیط Production آماده کرد.

تفاوت Backup معمولی و PITR

تفاوت اصلی در میزان اطلاعاتی است که می‌توان بازیابی کرد.
فرض کنید یک Backup روزانه در ساعت 00:00 دارید و حادثه ساعت 16:45 رخ داده است.
با Restore ساده:

00:00 → آخرین وضعیت Backup

اما با PITR:

00:00 → Backup
       +
00:00 تا 16:45 → Transaction Logs
       ↓
16:45 → وضعیت موردنظر

بنابراین PITR می‌تواند میزان از دست رفتن اطلاعات را به شکل قابل‌توجهی کاهش دهد.

اشتباهات رایج در PITR

یکی از اشتباهات رایج، انجام Recovery مستقیماً روی Production است.
بهتر است ابتدا Recovery در یک محیط جداگانه انجام شود.
اشتباه دیگر، نداشتن Logهای کافی است. اگر Backup موجود باشد اما بخشی از Binary Log یا WAL موردنیاز از بین رفته باشد، ممکن است Recovery تا زمان هدف امکان‌پذیر نباشد.
همچنین باید به Timezone توجه ویژه‌ای داشت.
زمان حادثه باید با تاریخ، ساعت و Timezone مشخص ثبت شود تا نقطه Recovery اشتباه انتخاب نشود.
مورد مهم دیگر، تست نکردن Backup است.
داشتن فایل Backup به این معنی نیست که حتماً در زمان بحران قابل Restore خواهد بود.

بهترین روش برای مدیریت Backup

برای یک زیرساخت حرفه‌ای بهتر است استراتژی Backup فقط به Full Backup محدود نشود.
ترکیبی از Full Backup، Backupهای افزایشی در صورت نیاز، Transaction Log Archiving و نگهداری نسخه‌های Backup در محل جداگانه می‌تواند امنیت بیشتری ایجاد کند.
همچنین باید Recovery به‌صورت دوره‌ای در یک محیط آزمایشی تست شود.

یک چک‌لیست ساده برای PITR:

• زمان دقیق حادثه مشخص شده است.

• Timezone مشخص است.

• Backup معتبر پیدا شده است.

• Logهای موردنیاز در دسترس هستند.

• فضای کافی برای Recovery وجود دارد.

• Recovery در محیط جداگانه انجام می‌شود.

• Target Time مشخص است.

• داده‌های بازیابی‌شده بررسی می‌شوند.

• قبل از انتقال به Production تأیید نهایی انجام می‌شود.

جمع‌بندی

 بازیابی دیتابیس برای یک ساعت خاص یکی از مهم‌ترین قابلیت‌ها برای حفاظت از اطلاعات در برابر خطای انسانی، حذف ناخواسته داده‌ها و خرابی سیستم است.
در این فرآیند، ابتدا یک Full یا Base Backup بازیابی می‌شود و سپس Logهای تغییرات تا زمان مشخص‌شده Replay می‌شوند.
در MySQL این فرآیند بر پایه Binary Log و در PostgreSQL بر پایه WAL انجام می‌شود.
نکته مهم این است که PITR فقط یک عملیات Restore نیست؛ بلکه بخشی از یک استراتژی کامل Backup، Log Management، Disaster Recovery و تست دوره‌ای Recovery محسوب می‌شود.
اگر Backupها به‌درستی تهیه و نگهداری شوند و Logهای موردنیاز نیز در دسترس باشند، می‌توان در بسیاری از سناریوها دیتابیس را به نقطه‌ای بسیار نزدیک به زمان وقوع حادثه بازگرداند و میزان از دست رفتن اطلاعات را به حداقل رساند.