Câu hỏi này có thể đọc giống như một bản sao, nhưng dựa trên tình huống và được đăng từ sự nhầm lẫn khi áp dụng kiến ​​thức từ các câu trả lời khác.

Tôi đã đọc hàng tá bài viết (trong số 1 , 2 , 3 , 4 ), nhưng đang tìm thấy những ý kiến ​​trái ngược nhau (dựa trên sự hiểu biết của tôi, hiện đang bị quá tải thông tin, hoặc có lẽ không bao gồm đủ thông tin trong các câu hỏi khác của tôi). Do đó, tôi đang tạo ra câu hỏi này để có được câu trả lời dứt khoát dựa trên tình huống của tôi.

Đưa ra kịch bản sao lưu sau, tôi cần biết liệu phần mềm sao lưu của bên thứ ba có ngăn tôi thực hiện khôi phục hoàn toàn đến điểm sao lưu mới nhất (18:00) không?

Time  | Action                                       | Device   
------|----------------------------------------------|----------------------------
12:00 | Full backup (non copy_only)                  | D:\MyBackupDevice                 
13:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
14:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
15:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
16:00 | Full backup (non copy_only) VSS snapshot     | Third-party off-site device
17:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                
18:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
19:00 | Disaster strikes                             |                                   

Mục tiêu khôi phục của tôi là khôi phục đến điểm sao lưu 18:00 (Tôi biết có một bản sao lưu đuôi có thể được thêm vào để có được các giao dịch còn lại cho đến khi thảm họa xảy ra, nhưng bây giờ hãy giữ mọi thứ đơn giản) .

Dựa trên câu trả lời này , tôi tin rằng bản sao lưu của bên thứ ba gây ra xung đột với việc khôi phục nhật ký giao dịch của riêng tôi (theo câu trả lời này ), điều này ngăn tôi thực hiện khôi phục đến thời điểm đó. Tôi hiểu rằng bản sao lưu nhật ký giao dịch chứa dữ liệu kể từ bản sao lưu không copy_only đầy đủ cuối cùng.

Điều này có đúng không? Có phải bản sao lưu của bên thứ ba ngăn thói quen khôi phục của riêng tôi hoạt động không vì nó là bản sao lưu không copy_only?

Có lẽ điều này sẽ giúp bạn hiểu. Hãy làm một bản demo! Chúng tôi sẽ tạo một cơ sở dữ liệu giả với một số dữ liệu giả.

USE master;

/*Create a dummy database*/
CREATE DATABASE LogRestoreTest

/*We full now*/
ALTER DATABASE LogRestoreTest SET RECOVERY FULL

/*Context is everything*/
USE LogRestoreTest

/*If nothing changes, do we even need a log backup?*/
CREATE TABLE dbo.t1 (Id INT)

Bây giờ chúng tôi sẽ có một bản sao lưu đầy đủ. Chỉ một. Lời hứa.

/*Take a full backup, dummy*/

BACKUP DATABASE LogRestoreTest 
TO DISK = 'F:\Backup\LRT_FULL.bak' 
WITH INIT, FORMAT, COMPRESSION

Bây giờ chúng tôi sẽ thực hiện một số thay đổi và thực hiện một số sao lưu nhật ký. Giống như đời thực. Nó vui. Chưa uống rượu.

/*Make a change*/
INSERT dbo.t1 (Id )
VALUES ( 1 )

/*Take a log backup*/
BACKUP LOG LogRestoreTest 
TO DISK = 'F:\Backup\LRT_LOG_1.trn' 
WITH INIT, FORMAT, COMPRESSION

/*Make another change*/
INSERT dbo.t1 (Id )
VALUES ( 2 )

/*Take another log backup*/
BACKUP LOG LogRestoreTest 
TO DISK = 'F:\Backup\LRT_LOG_2.trn' 
WITH INIT, FORMAT, COMPRESSION

/*Make another change*/
INSERT dbo.t1 (Id )
VALUES ( 3 )

Bây giờ chúng tôi sẽ thực hiện sao lưu toàn bộ 'ngoài băng' và sao lưu nhật ký khác.

/*A second full backup appears!*/
BACKUP DATABASE LogRestoreTest 
TO DISK = 'F:\Backup\LRT_FULL_2.bak' 
WITH INIT, FORMAT, COMPRESSION

/*Take another log backup*/
BACKUP LOG LogRestoreTest 
TO DISK = 'F:\Backup\LRT_LOG_3.trn' 
WITH INIT, FORMAT, COMPRESSION

Nếu tôi muốn khôi phục dữ liệu để sao lưu nhật ký thứ ba, tôi có hai tùy chọn.

Khôi phục bản sao lưu đầy đủ đầu tiên và cả ba bản sao lưu nhật ký:

/*Restore the full backup*/
RESTORE DATABASE LogRestoreTest
FROM DISK = 'F:\Backup\LRT_FULL.bak' 
WITH REPLACE, NORECOVERY


/*Square one*/
RESTORE DATABASE LogRestoreTest
FROM DISK = 'F:\Backup\LRT_LOG_1.trn' 
WITH NORECOVERY

/*What about to here?*/
RESTORE DATABASE LogRestoreTest
FROM DISK = 'F:\Backup\LRT_LOG_2.trn' 
WITH NORECOVERY

/*Obligatory Your Mom*/
RESTORE DATABASE LogRestoreTest
FROM DISK = 'F:\Backup\LRT_LOG_3.trn' 
WITH NORECOVERY

Hoặc tôi có thể khôi phục đầy đủ gần đây nhất và sau đó là tệp nhật ký cuối cùng:

/*Restore the full backup*/
RESTORE DATABASE LogRestoreTest
FROM DISK = 'F:\Backup\LRT_FULL_2.bak' 
WITH REPLACE, NORECOVERY


/*What happens if I try to jump the restores?*/
RESTORE DATABASE LogRestoreTest
FROM DISK = 'F:\Backup\LRT_LOG_3.trn' 
WITH NORECOVERY

Bạn sẽ phải tha thứ cho tôi khi không giải thích về các bản sao lưu khác biệt ở đây, nhưng có rất nhiều tài nguyên ngoài đó bao gồm tài liệu DBA 101.

Hi vọng điêu nay co ich!

_{Cộng đồng wiki trả lời :}

Trong câu hỏi trước của bạn , bạn đã nói:

... có vẻ như công cụ này đã sử dụng các copy_onlybản sao lưu, do đó phá hủy chuỗi log

Một FULLbản sao lưu không bao giờ phá vỡ chuỗi log.

Một COPY_ONLY FULLbản sao lưu không chỉ đặt lại cơ sở vi sai (điểm tham chiếu cho DIFFERENTIALbản sao lưu).

Vì vậy, không , 16:00 | Full backup (non copy_only) VSS snapshotsẽ không ngăn bạn thực hiện thành công trình tự khôi phục sau:

1. 12:00 | Full backup (non copy_only)
2. 13:00 | Tran log backup (non copy_only)
3. 14:00 | Tran log backup (non copy_only)
4. 15:00 | Tran log backup (non copy_only)
5. 17:00 | Tran log backup (non copy_only)
6. 18:00 | Tran log backup (non copy_only)

Có một chuỗi khôi phục ví dụ bằng cách sử dụng bản FULLsao lưu không mới nhất ở đây:

• Áp dụng sao lưu nhật ký giao dịch (SQL Server)

Một LOGbản sao lưu chứa dữ liệu kể từ lần LOGsao lưu cuối cùng . FULLvà DIFFERENTIALsao lưu không cắt bớt nhật ký.

Từ Nhật ký giao dịch (SQL Server)

Trong mô hình khôi phục đầy đủ hoặc mô hình khôi phục được ghi nhật ký hàng loạt, nếu một điểm kiểm tra đã xảy ra kể từ lần sao lưu trước, việc cắt xén xảy ra sau khi sao lưu nhật ký (trừ khi đó là bản sao lưu nhật ký chỉ sao chép).

Tôi sẽ hợp nhất thông tin từ các câu trả lời trước của tôi thành một câu trả lời duy nhất ở đây để giải thích một chút về những gì xảy ra trong kịch bản của bạn. Tôi muốn chỉ ra rằng các điều kiện tiên quyết trong câu hỏi của bạn đã thay đổi một chút từ câu hỏi này sang câu hỏi khác.

TL; DR

Không , sao lưu ảnh chụp nhanh FULL thường xuyên của giải pháp bên thứ 3 từ ví dụ của bạn sẽ không phá vỡ chuỗi sao lưu.

Đường cơ sở

Đường cơ sở cho lời giải thích sẽ là bảng của bạn như được xác định trong câu hỏi của bạn:

Time  | Action                                       | Device   
------|----------------------------------------------|----------------------------
12:00 | Full backup (non copy_only)                  | D:\MyBackupDevice                 
13:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
14:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
15:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
16:00 | Full backup (non copy_only) VSS snapshot     | Third-party off-site device
17:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                
18:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
19:00 | Disaster strikes                             |           

Giải thích về Sao lưu

Mỗi khi SQL Server thực hiện sao lưu cơ sở dữ liệu, nó sẽ chèn thông tin Số thứ tự Loq (LSN) có liên quan vào lịch sử sao lưu msdb, để trong trường hợp khôi phục, quá trình sẽ biết tệp nào (bộ sao lưu) cần khôi phục cơ sở dữ liệu . Nó lưu trữ các chuỗi sao lưu với sự giúp đỡ của LSNs trong các cột first_lsn, last_lsnvà database_backup_lsn(và một số cột khác).

Thông tin này cũng được lưu trữ trong các tập tin sao lưu. Các cột này hỗ trợ quá trình khôi phục khi khôi phục cơ sở dữ liệu từ bản sao lưu FULL và bản sao lưu TLOG bổ sung.

Các first_lsnsẽ chứa LSN của giao dịch đầu tiên được lưu trữ trong bản sao lưu TLOG và last_lsnsẽ chứa các LSN của giao dịch cuối cùng trong bản sao lưu TLOG.

Các database_backup_lsnsẽ chứa LSN của sao lưu đầy đủ cuối cùng.

Dừng lại. Quay lại. Đọc phần này một lần nữa.

Ví dụ về số LSN từ một tình huống tương tự

backup_type checkpoint_lsn      database_backup_lsn first_lsn           last_lsn             
Full        35000001911700042   35000001908000042   35000001911100002   35000001913500001    
Log         35000001911700042   35000001911700042   35000001911200001   35000001914300001    
Log         35000001911700042   35000001911700042   35000001914300001   35000001914600001    
Log         35000001911700042   35000001911700042   35000001914600001   35000001914900001    
Log         35000001911700042   35000001911700042   35000001914900001   35000001915200001    
Full        35000001915700042   35000001911700042   35000001915700042   35000001917500001    
Log         35000001915700042   35000001915700042   35000001915200001   35000001918300001    

Như bạn có thể thấy trong ví dụ này, LSN của các bản sao lưu TLOG luôn khớp với nhau. Bản last_lsnsao lưu TLOG trước đó khớp với first_lsnbản sao lưu TLOG tiếp theo.

Tuy nhiên, bản sao lưu FULL có LSN bắt đầu bên trong phạm vi LSN của bản sao lưu TLOG tiếp theo và kết thúc bên trong phạm vi LSN của cùng bản sao lưu TLOG.

Khôi phục dựa trên bảng ví dụ của bạn

Nếu bạn được yêu cầu khôi phục cơ sở dữ liệu của mình đến 18:00 do lỗi vào lúc 19:00 thì bạn sẽ yêu cầu sao lưu FULL từ 12:00 và sao lưu Nhật ký giao dịch của bạn từ 13:00 đến 18:00.

Các LSN sẽ không bị gián đoạn. Không cần sao lưu FULL của bên thứ 3.

Bạn có thể xác minh điều này bằng cách kiểm tra cột first_lsnvà last_lsncác bản sao lưu hiện tại của bạn. Họ nên phù hợp với nhau.

Kết thúc giải thích

Bạn có thể kết thúc lời giải thích ở đây và ngay bây giờ, nhưng có những cân nhắc được đưa ra liên quan đến giải pháp của bên thứ 3 và giải pháp bạn đang sử dụng để sao lưu.

(Còn tiếp...)

Tham khảo: Máy chủ SQL - Tìm hiểu sao lưu máy chủ SQL (Paul S. Randal)