بازیابی نقطه‌ای: چطور به یک لحظهٔ مشخص برگردیم

ساعت ۱۴:۴۰ است و کسی ده دقیقه پیش یک DELETE بی WHERE اجرا کرده. اگر دیتابیس در مدل FULL است و بکاپ لاگ می‌گیرید، می‌توانید به ۱۴:۲۹ برگردید — یک دقیقه پیش از فاجعه. این قابلیت دقیقاً همان چیزی است که بابت مدل FULL هزینه می‌دهید.

این مقاله ترتیب کار است، با تأکید روی جایی که معمولاً اشتباه می‌شود.

اول: چیزی را خراب‌تر نکنید

پیش از هر کاری، بکاپ دم‌لاگ بگیرید. این آخرین تکهٔ لاگ است که هنوز بکاپ نشده و بی آن، هر چیزی که بعد از آخرین بکاپ لاگ اتفاق افتاده برای همیشه رفته — از جمله کارهای درست ده دقیقهٔ اخیر.

BACKUP LOG [Sales]
TO DISK = N'E:\backup\Sales_tail.trn'
WITH NORECOVERY, COMPRESSION;

NORECOVERY دیتابیس را در حالت بازیابی نگه می‌دارد، یعنی کاربران دیگر نمی‌توانند بنویسند. این عمدی است: از این لحظه هر نوشتن تازه، کار بازیابی را پیچیده‌تر می‌کند.

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

زنجیره را بسازید

برای رسیدن به 14:29 این‌ها را لازم دارید، به همین ترتیب:

1. آخرین فولِ پیش از آن لحظه
2. آخرین دیفرنشیالِ پس از آن فول و پیش از آن لحظه (اگر دارید)
3. همهٔ بکاپ‌های لاگ از آن نقطه تا لحظهٔ هدف، بی هیچ حفره‌ای

زنجیره را از msdb پیدا کنید:

DECLARE @target DATETIME = '2026-09-21 14:29:00';

SELECT  bs.database_name, bs.type, bs.backup_start_date, bs.backup_finish_date,
        bs.first_lsn, bs.last_lsn, bmf.physical_device_name
FROM    msdb.dbo.backupset bs
JOIN    msdb.dbo.backupmediafamily bmf ON bmf.media_set_id = bs.media_set_id
WHERE   bs.database_name = N'Sales'
  AND   bs.backup_start_date >= DATEADD(DAY, -8, @target)
ORDER   BY bs.backup_finish_date;

یک حفره در زنجیرهٔ لاگ یعنی نمی‌توانید از آن نقطه جلوتر بروید. رایج‌ترین دلیل حفره: کسی یک بکاپ لاگ دستی گرفته و فایلش را جای دیگری گذاشته یا پاک کرده.

بازگرداندن

-- ۱) فول، با نام و مسیر تازه
RESTORE DATABASE [Sales_recover]
FROM DISK = N'E:\backup\Sales_full.bak'
WITH MOVE N'Sales'     TO N'T:\recover\Sales_recover.mdf',
     MOVE N'Sales_log' TO N'T:\recover\Sales_recover.ldf',
     NORECOVERY, STATS = 5;

-- ۲) آخرین دیفرنشیال
RESTORE DATABASE [Sales_recover]
FROM DISK = N'E:\backup\Sales_diff.bak'
WITH NORECOVERY;

-- ۳) لاگ‌ها، به ترتیب. آخری با STOPAT
RESTORE LOG [Sales_recover] FROM DISK = N'E:\backup\Sales_log_1400.trn' WITH NORECOVERY;
RESTORE LOG [Sales_recover] FROM DISK = N'E:\backup\Sales_log_1415.trn' WITH NORECOVERY;
RESTORE LOG [Sales_recover] FROM DISK = N'E:\backup\Sales_log_1430.trn'
WITH STOPAT = '2026-09-21 14:29:00', NORECOVERY;

-- ۴) پایان کار: حالا دیتابیس قابل استفاده می‌شود
RESTORE DATABASE [Sales_recover] WITH RECOVERY;

چند نکته که گیر می‌اندازند:

• همه با NORECOVERY، جز آخری. اگر وسط زنجیره RECOVERY بزنید، دیتابیس باز می‌شود و دیگر نمی‌توانید لاگ بعدی را بزنید. باید از اول شروع کنید.
• STOPAT روی همان فایلی که لحظهٔ هدف در آن است. روی فایل‌های قبلی لازم نیست و روی فایل بعدی خطا می‌دهد.
• MOVE فراموش نشود. بی آن، بازیابی سعی می‌کند روی مسیر فایل‌های اصلی بنویسد و یا خطا می‌دهد یا — بدتر — چیزی را که نباید بازنویسی می‌کند.
• زمان محلی سرور. STOPAT با ساعت سرور مقایسه می‌شود، نه ساعت شما.

اگر نمی‌دانید دقیقاً چه ساعتی

اغلب زمان دقیق را نمی‌دانید و فقط می‌دانید «امروز بعدازظهر». دو راه:

اگر می‌دانید کدام تراکنش مقصر است و علامت‌گذاری شده بوده، می‌توانید با STOPBEFOREMARK تا پیش از آن برگردید. در عمل به‌ندرت این شانس را دارید.

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

چیزی که همه از قلم می‌اندازند

پیش از اجرای زنجیره، بررسی کنید که همهٔ فایل‌ها واقعاً وجود دارند. تاریخچهٔ msdb می‌گوید فایلی نوشته شده؛ نمی‌گوید هنوز آنجاست. فایل‌ها ممکن است با سیاست نگه‌داری پاک شده باشند، یا روی درایوی باشند که دیگر وصل نیست.

هیچ چیز بدتر از این نیست که وسط بازیابی اضطراری بفهمید حلقهٔ سوم از پنج حلقه غایب است. یک بررسی سادهٔ وجود فایل‌ها پیش از شروع، این را به یک مشکل معلوم در دقیقهٔ اول تبدیل می‌کند، نه در دقیقهٔ چهلم.

در DBMug همین بررسی، بخش اجباری ساخت نقشهٔ بازیابی است: نقشه ساخته می‌شود، وجود تک‌تک فایل‌ها چک می‌شود، و بازنویسی یک دیتابیس تولیدی به تأیید صریح نامش و یک بکاپ دم‌لاگ اجباری نیاز دارد. این‌ها احتیاط‌هایی هستند که در آرامش بدیهی به نظر می‌رسند و در بحران فراموش می‌شوند.