Làm thế nào để biết nếu một chuỗi log sao lưu bị hỏng?

Tôi đã gặp tình huống Sao lưu gốc được tạo trên Máy chủ.
Tôi tình cờ thấy msdbrằng có một công cụ sao lưu của bên thứ ba ( AppAssure) cũng đang sử dụng VSS (loại) backup to virtual device.

Tại một số khoảng thời gian, AppAssure (sao lưu được thực hiện VIRTUAL DEVICE) đang thực hiện COPY_ONLY backupvà tại một khoảng thời gian khác, nó đang thực hiện FULL backupphá vỡ chuỗi nhật ký.

Có cách nào ( T-SQL query) để biết khi nào một chuỗi nhật ký dự phòng bị hỏng không?

Dưới đây là một ảnh chụp màn hình của tình hình từ tháng Hai.

Đọc tham khảo / Hỏi và tương tự

Bạn có thể muốn kiểm tra câu trả lời của tôi mà tôi đã đăng để trả lời cho câu hỏi: Sao lưu VSS có phá vỡ logchain không? (dba.stackexchange.com)

Giải thích trong câu trả lời của tôi cũng liên kết đến câu hỏi Làm cách nào tôi có thể sao lưu cơ sở dữ liệu SQL Server bằng Windows Server Backup? (serverfault.com) cũng được trả lời bởi chính tôi.

Chuỗi nhật ký giao dịch

Khi sao lưu Nhật ký giao dịch (TLOG) được thực hiện, thông tin sao lưu được lưu trữ trong cơ sở dữ liệu msdb trong các bảng khác nhau. Các thông tin được lưu trữ sẽ chứa các thông tin như backup_type, logical_device_name, physical_device_name, is_copy_only, is_snapshot, và nhiều ..._lsncột (LSN = số thứ tự đăng nhập).

Bạn có thể truy xuất thông tin chuỗi sao lưu nhật ký giao dịch từ phiên bản SQL Server của mình thông qua cơ sở dữ liệu msdb với tập lệnh sau:

/* ==================================================================
 Author......:  hot2use 
 Date........:  25.04.2018
 Version.....:  0.1
 Server......:  localhost (first created for)
 Database....:  msdb
 Owner.......:  -
 Table.......:  various
 Type........:  Script
 Name........:  ADMIN_Retrieve_Backup_History_Information.sql
 Description.:  Retrieve backup history information from msdb database
 ............   
 ............   
 ............       
 History.....:   0.1    h2u First created
 ............       
 ............       
================================================================== */
SELECT /* Columns for retrieving information */
       -- CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS SRVNAME, 
       msdb.dbo.backupset.database_name,
       msdb.dbo.backupset.backup_start_date,
       msdb.dbo.backupset.backup_finish_date,
       -- msdb.dbo.backupset.expiration_date, 

       CASE msdb.dbo.backupset.type
            WHEN 'D' THEN 'Full'
            WHEN 'I' THEN 'Diff'
            WHEN 'L' THEN 'Log'
       END  AS backup_type,
       -- msdb.dbo.backupset.backup_size / 1024 / 1024 as [backup_size MB],  
       msdb.dbo.backupmediafamily.logical_device_name,
       msdb.dbo.backupmediafamily.physical_device_name,
       -- msdb.dbo.backupset.name AS backupset_name,
       -- msdb.dbo.backupset.description,
       msdb.dbo.backupset.is_copy_only,
       msdb.dbo.backupset.is_snapshot,
       msdb.dbo.backupset.checkpoint_lsn,
       msdb.dbo.backupset.database_backup_lsn,
       msdb.dbo.backupset.differential_base_lsn,
       msdb.dbo.backupset.first_lsn,
       msdb.dbo.backupset.fork_point_lsn,
       msdb.dbo.backupset.last_lsn
FROM   msdb.dbo.backupmediafamily
       INNER JOIN msdb.dbo.backupset
            ON  msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id 

        /* ----------------------------------------------------------------------------
        Generic WHERE statement to simplify selection of more WHEREs    
        -------------------------------------------------------------------------------*/
WHERE  1 = 1

       /* ----------------------------------------------------------------------------
       WHERE statement to find Device Backups with '{' and date n days back
       ------------------------------------------------------------------------------- */
       -- AND     physical_device_name LIKE '{%'

       /* -------------------------------------------------------------------------------
       WHERE statement to find Backups saved in standard directories, msdb.dbo.backupfile AS b 
       ---------------------------------------------------------------------------------- */
       -- AND     physical_device_name  LIKE '[fF]:%'                          -- STANDARD F: Backup Directory
       -- AND     physical_device_name  NOT LIKE '[nN]:%'                      -- STANDARD N: Backup Directory

       -- AND     physical_device_name  NOT LIKE '{%'                          -- Outstanding Analysis
       -- AND     physical_device_name  NOT LIKE '%$\Sharepoint$\%' ESCAPE '$' -- Sharepoint Backs up to Share
       -- AND     backupset_name NOT LIKE '%Galaxy%'                           -- CommVault Sympana Backup


       /* -------------------------------------------------------------------------------
       WHERE Statement to find backup information for a certain period of time, msdb.dbo.backupset AS b 
       ---------------------------------------------------------------------------------- 
       AND    (CONVERT(datetime, msdb.dbo.backupset.backup_start_date, 102) >= GETDATE() - 7)  -- 7 days old or younger
       AND    (CONVERT(datetime, msdb.dbo.backupset.backup_start_date, 102) <= GETDATE())  -- n days old or older

       */

       /* -------------------------------------------------------------------------------
       WHERE Statement to find backup information for (a) given database(s) 
       ---------------------------------------------------------------------------------- */
       AND database_name IN ('AdventureWorks2012') -- database names
       -- AND     database_name IN ('rtc')  -- database names

        /* -------------------------------------------------------------------------------
        ORDER Clause for other statements
        ---------------------------------------------------------------------------------- */
        --ORDER BY        msdb.dbo.backupset.database_name, msdb.dbo.backupset.backup_finish_date -- order clause

        ---WHERE msdb..backupset.type = 'I' OR  msdb..backupset.type = 'D'
ORDER BY
       --2,

       2       DESC,
       3       DESC 

^{Thận trọng: Mệnh đề where hiện đang chọn cơ sở dữ liệu AdventureWorks2012}

Chuỗi nhật ký giao dịch bị hỏng

Chuỗi nhật ký (giao dịch) không bao giờ bị phá vỡ trừ khi một trong các điều kiện sau được đáp ứng:

• một tập tin sao lưu Nhật ký giao dịch đã bị xóa
• Không thể truy cập tệp sao lưu Nhật ký giao dịch (ở đâu đó trong thiết bị sao lưu; giải pháp sao lưu của bên thứ 3)
• cơ sở dữ liệu trong mô hình khôi phục SIMPLE
• một bản sao lưu Nhật ký giao dịch đã được thực hiện với tùy chọn TRUNCATE_ONLY
• một bản sao lưu cơ sở dữ liệu FULL được thực hiện mà không có COPY_ONLYtùy chọn và sau đó bị xóa khỏi đĩa vì các nhà phát triển chỉ cần sao lưu nhanh để phân tích tình huống trong cơ sở dữ liệu vàFULL bản sao lưu của bạn trước khi bị xóa bởi (a) thủ tục sao lưu.

Hoàn cảnh của bạn

Trong ảnh chụp màn hình, bạn cung cấp cho bạn một FULLbản sao lưu cơ sở dữ liệu is_copy_onlyvà ngay sau khi FULLsao lưu không có is_copy_only . Bây giờ những gì bạn không biết:

Là thứ hai FULL, không is_copy_onlysao lưu một ảnh chụp nhanh hay không?

Nếu bạn sử dụng tập lệnh của tôi ở trên và thay đổi WHEREmệnh đề để khớp với tên cơ sở dữ liệu của bạn, bạn có thể phát hiện ra rằng FULLbản sao lưu đó không phải is_copy_onlylà một is_snapshot.

Và điều đó có thể mở ra một câu hỏi mới:

Sẽ FULL, is_snapshotcơ sở dữ liệu sao lưu cơ sở dữ liệu của tôi phá vỡ các chuỗi sao lưu đăng nhập?

Nhưng...

.... cho dù điều này diễn ra như thế nào, miễn là bạn có một chuỗi các bản sao lưu FULLvà TLOGsao lưu mà bạn có thể truy cập, bạn vẫn có thể khôi phục cơ sở dữ liệu của mình đến bất kỳ thời điểm nào, ngay cả khi bạn có một FULLbản sao lưu khác ở giữa.

Bạn có thể xác minh điều này với đầu ra của tập lệnh của tôi cho cơ sở dữ liệu của bạn, bằng cách xem first_lsnvà last_lsnsố. Họ nên kết hợp, ngay cả khi bỏ qua một FULLbản sao lưu.

Tốt hơn là an toàn hơn xin lỗi

Tôi có một AdminDB2cơ sở dữ liệu về một trong những trường hợp của tôi. Tôi đã tạo TLOGbản sao lưu, sửa đổi dữ liệu, thực hiện FULLsao lưu, sửa đổi dữ liệu, thực hiện TLOGsao lưu, ....

Hãy xem lịch sử sao lưu của tôi AdminDB2:

dbname    backup_start_date       backup_finish_date            type    Log   physical_device_name                                          C   S   checkpoint_lsn   dbase_backup_lsn     dlsn  first_lsn           flsn    last_lsn
AdminDB2    2018-04-25 17:29:08.000 2018-04-25 17:29:08.000 TLOG    NULL    C:\SQL\Backup\AdminDB2\TLOG\AdminDB2_TLOG_20180425_172908.trn   0   0   36000002022400042   36000002022400042   NULL    36000002021900001   NULL    36000002025100001
AdminDB2    2018-04-25 17:28:48.000 2018-04-25 17:28:48.000 Full    NULL    C:\SQL\Backup\AdminDB2\FULL\AdminDB2_FULL_20180425_172848.bak   0   0   36000002022400042   36000002018900037   NULL    36000002022400042   NULL    36000002024200001
AdminDB2    2018-04-25 17:28:23.000 2018-04-25 17:28:23.000 TLOG    NULL    C:\SQL\Backup\AdminDB2\TLOG\AdminDB2_TLOG_20180425_172823.trn   0   0   36000002018900037   36000002018900037   NULL    36000002021500001   NULL    36000002021900001
AdminDB2    2018-04-25 17:28:07.000 2018-04-25 17:28:07.000 TLOG    NULL    C:\SQL\Backup\AdminDB2\TLOG\AdminDB2_TLOG_20180425_172807.trn   0   0   36000002018900037   36000002018900037   NULL    36000002018400001   NULL    36000002021500001
AdminDB2    2018-04-25 17:27:32.000 2018-04-25 17:27:32.000 Full    NULL    C:\SQL\Backup\AdminDB2\FULL\AdminDB2_FULL_20180425_172732.bak   0   0   36000002018900037   36000001990800037   NULL    36000002018900037   NULL    36000002020600001
AdminDB2    2018-04-25 17:15:00.000 2018-04-25 17:15:00.000 TLOG    NULL    C:\SQL\Backup\AdminDB2\TLOG\AdminDB2_TLOG_20180425_171500.trn   0   0   36000002016000003   36000001990800037   NULL    36000002018100001   NULL    36000002018400001

_{Thứ tự là ngày giảm dần}

Bạn có thể thấy TLOGbản sao lưu cuối cùng ở trên cùng, bản sao lưu trước FULL(ở giữa) tại 2018-04-25 17:28:48.000, TLOGbản sao lưu trước đó 2018-04-25 17:28:23.000, v.v.

Để khôi phục AdminDB2cơ sở dữ liệu về thời điểm hiện tại, tôi sẽ phải sử dụng FULLbản sao lưu đầu tiên từ 2018-04-25 17:27:32.000(vì tôi đã xóa FULLbản sao lưu giữa ) cùng với tất cả các TLOGbản sao lưu.

Hãy thử xem.

1. Xóa FULLtệp sao lưu AdminDB2_FULL_20180425_172848.baktrên đĩa của tôi (hoặc đổi tên nó), chỉ vì nó là cái ở giữa.
2. Mở GUI Khôi phục trong SSMS và thêm ..
   • các FULLsao lưuAdminDB2_FULL_20180425_172732.bak
   • tất cả các TLOGtập tin sao lưu
     • Quản trị viênDB2_TLOG_20180425_172807.trn
     • Quản trịDB2_TLOG_20180425_172823.trn
     • Quản trịDB2_TLOG_20180425_172908.trn
3. Hãy chắc chắn rằng tôi đặt tùy chọn Overwrite the existing database (WITH REPLACE)
4. Thực hiện khôi phục (hoặc tập lệnh ra câu lệnh vào cửa sổ truy vấn)

Kịch bản

USE [master]
RESTORE DATABASE [AdminDB2] FROM  DISK = N'C:\SQL\BACKUP\AdminDB2\FULL\AdminDB2_FULL_20180425_172732.bak' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5, REPLACE
RESTORE LOG [AdminDB2] FROM  DISK = N'C:\SQL\BACKUP\AdminDB2\LOG\AdminDB2_LOG_20180425_172807.trn' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
RESTORE LOG [AdminDB2] FROM  DISK = N'C:\SQL\BACKUP\AdminDB2\LOG\AdminDB2_LOG_20180425_172823.trn' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5
RESTORE LOG [AdminDB2] FROM  DISK = N'C:\SQL\BACKUP\AdminDB2\LOG\AdminDB2_LOG_20180425_172908.trn' WITH  FILE = 1,  NOUNLOAD,  STATS = 5

GO

Đầu ra

15 percent processed.
30 percent processed.
45 percent processed.
60 percent processed.
75 percent processed.
90 percent processed.
100 percent processed.
Processed 848 pages for database 'AdminDB2', file 'AdminDB' on file 1.
Processed 2 pages for database 'AdminDB2', file 'AdminDB_log' on file 1.
RESTORE DATABASE successfully processed 850 pages in 0.134 seconds (49.502 MB/sec).
100 percent processed.
Processed 0 pages for database 'AdminDB2', file 'AdminDB' on file 1.
Processed 2 pages for database 'AdminDB2', file 'AdminDB_log' on file 1.
RESTORE LOG successfully processed 2 pages in 0.005 seconds (3.027 MB/sec).
100 percent processed.
Processed 0 pages for database 'AdminDB2', file 'AdminDB' on file 1.
Processed 1 pages for database 'AdminDB2', file 'AdminDB_log' on file 1.
RESTORE LOG successfully processed 1 pages in 0.005 seconds (0.390 MB/sec).
100 percent processed.
Processed 0 pages for database 'AdminDB2', file 'AdminDB' on file 1.
Processed 2 pages for database 'AdminDB2', file 'AdminDB_log' on file 1.
RESTORE LOG successfully processed 2 pages in 0.005 seconds (3.125 MB/sec).

... Và cơ sở dữ liệu đã trở lại TRỰC TUYẾN.

Tóm lược

Chuỗi sao lưu chỉ bị hỏng khi bạn mất các bản sao lưu TLOG ở giữa, ngoài việc bạn có thể khôi phục cơ sở dữ liệu từ FULLbản sao lưu từ lâu và chỉ cần thêm tất cả các TLOGbản sao lưu.

Tuy nhiên...

... nó là nhanh hơn để có một gần đây hơn FULL, DIFFvà TLOGsao lưu thuận tiện.

_{Thông tin bổ sung để phản hồi nhận xét: Sao lưu Nhật ký giao dịch được thực hiện với tùy chọn TRUNCATE_ONLY - khi điều này xảy ra, có cách nào để biết điều này bằng truy vấn T-SQL}

Sao lưu Nhật ký giao dịch với Truncate_only

Trong các phiên bản trước của SQL Server trước SQL Server 2008, bạn có thể sử dụng câu lệnh sau:

 BACKUP LOG [AdminDB2] WITH TRUNCATE_ONLY

Điều này đã không được chấp nhận và không còn được hỗ trợ. Bạn sẽ nhận được một thông báo lỗi như sau:

Msg 155, Level 15, State 1, Line 10
'TRUNCATE_ONLY' is not a recognized BACKUP option.

Phương pháp mới là sao lưu vào đĩa NULvà được thực hiện bằng lệnh sau:

BACKUP LOG [AdminDB2] TO DISK='NUL'

Điều này sẽ trả về các thông tin sau:

Processed 1 pages for database 'AdminDB2', file 'AdminDB_log' on file 1.
BACKUP LOG successfully processed 1 pages in 0.001 seconds (1.464 MB/sec).

Tư vấn
Đỗ KHÔNG sử dụng trong sản xuất. Bạn sẽ mất khả năng khôi phục về thời điểm trong quá trình sao lưu TLOG đó.

Tham khảo: BACKUP (Transact-SQL) (Microsoft Docs)

Lịch sử sao lưu của bạn sẽ hiển thị điều này như sau:

dbname      backup_start_date       backup_finish_date      type ldev  pdev C   S   checkpoint_lsn   dbase_backup_lsn     dlsn  first_lsn           flsn    last_lsn
AdminDB2    2018-04-26 09:35:05.000 2018-04-26 09:35:05.000 Log NULL    NUL 0   0   36000002030100002   36000002022400042   NULL    36000002033400001   NULL    36000002033700001

Thông tin cho cả logical_device_name( ldev) và physical_device_name( pdev) sẽ chứa giá trị NULL. Đây là một dấu hiệu cho thấy a BACKUP LOG ...đã được thực hiện với TRUNCATE_ONLY(new TO DISK='NUL':). Bạn sẽ mất khả năng khôi phục qua điểm này bằng cách sử dụng các bản sao lưu Nhật ký giao dịch.

_{Thông tin bổ sung để phản hồi nhận xét: Có - đây là is_snapshot = 1 [backup]}

is_snapshot

Vui lòng đọc phần is_snapshot trong câu trả lời của tôi cho câu hỏi Sử dụng sao lưu VSS của bên thứ ba cộng với sao lưu SQL gốc

Từ câu trả lời ban đầu của tôi:

Nếu lịch sử sao lưu cơ sở dữ liệu có cờ is_snapshotđược đặt thành 1thì bạn biết rằng sao lưu này được thực hiện bằng phần mềm của bên thứ 3 đã kích hoạt SQL Server Writer (Dịch vụ VSS cho SQL Server) cho phép phần mềm bên thứ 3 sao lưu cơ sở dữ liệu gần như ngay lập tức .

Từ tài liệu chính thức về Sao lưu ảnh chụp là gì:

Sao lưu ảnh chụp nhanh SQL Server được thực hiện với sự hợp tác của các nhà cung cấp phần cứng hoặc phần mềm bên thứ ba hoặc cả hai. Các nhà cung cấp này sử dụng các tính năng của SQL Server được thiết kế cho mục đích này. Công nghệ sao lưu cơ bản tạo ra một bản sao tức thời của dữ liệu đang được sao lưu. Việc sao chép tức thời thường được thực hiện bằng cách chia một bộ đĩa được nhân đôi hoặc bằng cách tạo một bản sao của khối đĩa khi nó được ghi. Điều này bảo tồn bản gốc. Tại thời điểm khôi phục, bản gốc được cung cấp ngay lập tức và đồng bộ hóa các đĩa bên dưới xảy ra trong nền. Điều này dẫn đến các hoạt động khôi phục gần như ngay lập tức.

Tham khảo: Sao lưu ảnh chụp nhanh (Microsoft Technet)

Một bản sao lưu được tạo bằng tính năng này cũng có thể được khôi phục gần như ngay lập tức.

Tóm lược

Các bản sao lưu của bên thứ 3 nên được đánh dấu là is_snapshot = 1và is_copy_only = 1. Những bản sao lưu sẽ không xung đột với các bước sao lưu bổ sung / thủ tục thực hiện sử dụng có nguồn gốc SQL Server BACKUP DATABASE..., BACKUP DATABASE ... WITH DIFFERENTIAL....và BACKUP LOG...báo cáo. Các bản sao lưu cơ sở dữ liệu của bên thứ 3 không phải là một phần của bộ sao lưu hiện có.

Tôi hy vọng thông tin này là đủ.

Theo tài liệu MSDN GIAO DỊCH LOG BACKUP và RESTORE SEQUENCE: Chuyện hoang đường & Sự thật Một chuỗi các T-Logbản sao lưu liên tục được gắn bởi một Log Chain, bắt đầu bằng một bản sao lưu FULL. Bây giờ, trừ khi chúng tôi chạy bất cứ thứ gì rõ ràng phá vỡ chuỗi log (Ví dụ: chạy BACKUP log TRUNCATE_ONLY * hoặc bằng cách chuyển sang mô hình khôi phục SIMPLE), chuỗi hiện tại vẫn còn nguyên. Với chuỗi nhật ký còn nguyên vẹn, bạn có thể khôi phục cơ sở dữ liệu của mình từ bất kỳ bản sao lưu cơ sở dữ liệu FULL nào trong bộ phương tiện, theo sau là tất cả các T-Logbản sao lưu tiếp theo đến điểm bị lỗi.

Và như các MSSQLTIPStài liệu ở đây Khi khôi phục cơ sở dữ liệu, chuỗi RESTORE cơ sở dữ liệu ban đầu phải bắt đầu từ bản sao lưu cơ sở dữ liệu FULL. Chuỗi RESTORE cơ sở dữ liệu không thể bắt đầu bằng sao lưu tệp vi sai hoặc sao lưu nhật ký giao dịch. Khi khôi phục lại cơ sở dữ liệu có bốn LSNs quan trọng: FirstLSN, LastLSN, CheckpointLSNvà DatabaseBackupLSN. Các giá trị này có thể được truy xuất từ ​​tệp sao lưu SQL Server bằng lệnh RESTORE HEADERONLY .

Ví dụ

Trong ảnh chụp màn hình ở trên, tôi muốn hiển thị cho bạn Tiêu đề "Sao lưu đầy đủ" và tiêu đề "Sao lưu nhật ký giao dịch". Nếu loại Sao lưu là 1 , có nghĩa là nó là một phần tiêu đề của sao lưu toàn bộ. Và nếu có 2 nghĩa là tiêu đề sao lưu nhật ký giao dịch.

Trong ảnh chụp màn hình này, tôi muốn hiển thị cho bạn trước Restore Headeronly.. để Sao lưu toàn bộ Sau đó Sao lưu nhật ký giao dịch và một lần nữa Sao lưu toàn bộ cơ sở dữ liệu.

Lưu ý: Ở đây tôi đã nhấn mạnh một số phần trong ảnh chụp màn hình vì lý do bảo mật.

Đối với bạn tham khảo thêm ở đây và đây

Sau khi đọc câu hỏi của bạn, tôi không tin rằng "chuỗi nhật ký" của bạn bị hỏng vì Appsuresao lưu này . Giả sử bạn có thể khôi phục FULLbản sao lưu được thực hiện APPSUREở dòng 5 WITH NORECOVERY, bạn sẽ có thể khôi phục DIFFERENTIALbản sao lưu của mình ở dòng 6 mà không gặp vấn đề gì.

Tôi tin rằng câu hỏi thực sự của bạn là:

Làm cách nào tôi có thể xác định xem các bản sao lưu không sao chép ' giả mạo ' FULLđang được thực hiện mà tôi không biết.

Có thể có nhiều cách tinh vi hơn để xác định điều này, nhưng có lẽ một truy vấn đơn giản để kiểm tra các bản sao lưu không sao chép đang được lưu trữ trên một vị trí mà bạn không mong đợi sẽ đủ.

Từ ảnh chụp màn hình của bạn, có vẻ như các bản sao lưu bình thường của bạn đang được lưu trữ tại E:\SQLBackups. Nó có thể đủ để bạn chạy một truy vấn đơn giản để kiểm tra FULLcác bản sao lưu không sao chép đang được lưu trữ ở một nơi khác.

SELECT s.database_name
    ,m.physical_device_name
    ,s.backup_start_date
FROM msdb.dbo.backupset s
INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id
WHERE s.database_name = DB_NAME() -- Remove this line for all the database
    AND s.is_copy_only = 0
    and physical_device_name not like 'E:\SQLBackup%'
ORDER BY backup_start_date DESC