Hướng Dẫn Phục Hồi Cơ Sở Dữ Liệu SQL Server Không Có Backup Log

Phục hồi cơ sở dữ liệu SQL Server là một trong những nhiệm vụ quan trọng nhất đối với DBA (Database Administrator). Trong các tình huống lý tưởng, chúng ta sử dụng backup đầy đủ, backup khác biệt và backup log giao dịch để đưa cơ sở dữ liệu quay trở lại hoạt động. Tuy nhiên, trong một số trường hợp, backup log không có sẵn do backup không hoàn chỉnh, xóa nhầm hoặc tệp log giao dịch bị hỏng. Chúng ta có thể phục hồi cơ sở dữ liệu mà không cần backup log, nhưng điều này có một số thách thức kỹ thuật và rủi ro mất dữ liệu nhất định.

Trong bài viết này, chúng ta sẽ tìm hiểu quy trình từng bước để phục hồi bất kỳ cơ sở dữ liệu nào mà không có backup log giao dịch. Đồng thời, chúng ta sẽ xem xét các thách thức kỹ thuật mà chúng ta có thể gặp phải khi phục hồi cơ sở dữ liệu mà không có backup log giao dịch. Đầu tiên, hãy cùng tìm hiểu cách mà việc không có backup log giao dịch có thể ảnh hưởng đến chiến lược phục hồi của bạn.

Khi Nào Bạn Cần Phục Hồi Mà Không Có Backup Log?

Bạn có thể bị buộc phải ở trong tình huống này trong các trường hợp như:

• Mô hình phục hồi của cơ sở dữ liệu được đặt thành SIMPLE, nơi mà backup log không có giá trị.
• Chuỗi backup log giao dịch bị đứt do tệp log giao dịch bị thiếu hoặc bị hỏng.
• Backup log bị xóa nhầm. Đôi khi, khi chúng ta hết dung lượng lưu trữ, ai đó có thể xóa backup log mà không xác minh backup đầy đủ và khác biệt.
• Cơ sở dữ liệu đã ở chế độ phục hồi FULL, nhưng tổ chức không cấu hình các backup log.

Trong những tình huống này, bạn chỉ có thể dựa vào backup đầy đủ và khác biệt để phục hồi. Dưới đây là quy trình từng bước trong việc phục hồi một cơ sở dữ liệu mà không có backup log giao dịch.

Các Bước Phục Hồi Cơ Sở Dữ Liệu

Hãy cùng tìm hiểu quy trình từng bước để phục hồi cơ sở dữ liệu mà không có backup log. Để minh họa, chúng ta sẽ sử dụng cơ sở dữ liệu Stackoverflow2010.

Đầu tiên, chúng ta cần kiểm tra mô hình phục hồi của cơ sở dữ liệu. Nếu cơ sở dữ liệu ở mô hình phục hồi SIMPLE, thì backup log sẽ không cần thiết.

select database_id, name, create_date, recovery_model_desc from sys.databases where name='Stackoverflow2010'

Kết quả truy vấn:

Như bạn có thể thấy, cơ sở dữ liệu đang ở mô hình phục hồi FULL. Bây giờ hãy xác nhận các backup đầy đủ, khác biệt và log giao dịch gần nhất. Đây là mã truy vấn.

USE msdb;
GO

;WITH BackupHistory AS
(
    SELECT 
        bs.database_name,
        bs.backup_start_date,
        bs.backup_finish_date,
        bs.type,
        bmf.physical_device_name,
        ROW_NUMBER() OVER (PARTITION BY bs.database_name, bs.type ORDER BY bs.backup_finish_date DESC) AS rn
    FROM dbo.backupset bs
    INNER JOIN dbo.backupmediafamily bmf 
        ON bs.media_set_id = bmf.media_set_id
)
SELECT 
    database_name,
    CASE type
        WHEN 'D' THEN 'Backup Đầy Đủ'
        WHEN 'I' THEN 'Backup Khác Biệt'
        WHEN 'L' THEN 'Backup Log Giao Dịch'
    END AS backup_type,
    backup_start_date,
    backup_finish_date,
    physical_device_name
FROM BackupHistory
WHERE rn = 1
  AND type IN ('D','I','L') and database_name='Stackoverflow2010'
ORDER BY database_name, backup_type;

Kết quả truy vấn:

Như bạn có thể thấy, chúng ta không có backup log giao dịch. Do đó, chúng ta phải dựa vào backup đầy đủ và khác biệt. Theo quy trình, chúng ta sẽ phục hồi một backup đầy đủ với tùy chọn NORECOVERY. Tùy chọn NORECOVERY sẽ cho phép chúng ta áp dụng các backup khác biệt và log. Đây là mã để phục hồi backup đầy đủ.

USE [master]
GO
RESTORE DATABASE [Stackoverflow2010] FROM  DISK = N'D:\MS_SQL\Backups\Stackoverflow2010\Stackoverflow2010_full_backup.bak' WITH  FILE = 1,  
MOVE N'TTIConfig' TO N'D:\MS_SQL\DATA\Stackoverflow2010.mdf',  MOVE N'TTIConfig_log' TO N'D:\MS_SQL\LOG\Stackoverflow2010_1.ldf',  NOUNLOAD,  STATS = 5
GO

Sau khi backup đầy đủ được phục hồi, chúng ta cần phục hồi backup khác biệt. Vì chúng ta không có backup log giao dịch, chúng ta sẽ phục hồi backup khác biệt bằng tùy chọn WITH RECOVERY. Tùy chọn WITH RECOVERY sẽ hoàn tất quy trình phục hồi và đưa cơ sở dữ liệu trở lại trực tuyến. Bạn không thể áp dụng bất kỳ backup khác biệt hoặc log giao dịch nào trên đó. Đây là mã để phục hồi backup khác biệt.

USE [master]
GO
RESTORE DATABASE [Stackoverflow2010] FROM  DISK = N'D:\MS_SQL\Backups\Stackoverflow2010\Stackoverflow2010_differential_backup.bak' WITH  FILE = 1,  NOUNLOAD,  STATS = 5
GO

Sau khi quá trình hoàn tất, hãy kiểm tra trạng thái của cơ sở dữ liệu.

select database_id, name, create_date, recovery_model_desc, state_desc from sys.databases where name='Stackoverflow2010'

Kết quả truy vấn:

Như bạn có thể thấy, cơ sở dữ liệu đã trực tuyến. Tin xấu là chúng ta không thể phục hồi cơ sở dữ liệu đến thời điểm thất bại.

Thách Thức Khi Phục Hồi Mà Không Có Backup Log

Việc phục hồi mà không có backup log giao dịch đưa ra nhiều thách thức cấp độ DBA:

• Bạn không thể phục hồi cơ sở dữ liệu đến một thời điểm cụ thể trước khi xảy ra sự cố. Bạn chỉ có thể phục hồi dữ liệu đến backup đầy đủ hoặc khác biệt cuối cùng.
• Nếu backup cuối cùng của bạn cũ, bạn có thể mất hàng giờ hoặc thậm chí hàng ngày dữ liệu / giao dịch. Ví dụ, nếu bạn thực hiện backup đầy đủ hàng tuần và backup khác biệt hàng ngày, bạn sẽ chỉ phục hồi dữ liệu đến backup khác biệt thành công cuối cùng.
• Nếu cơ sở dữ liệu bị hỏng hoặc tệp log bị thiếu, bạn không thể backup phần đuôi của log. Điều này dẫn đến mất mát giao dịch vĩnh viễn.
• Nếu backup khác biệt bị thiếu hoặc hỏng, bạn phải sử dụng backup đầy đủ cuối cùng. Việc phục hồi backup đầy đủ làm tăng thời gian ngừng hoạt động và mất dữ liệu lớn.

Thực Hành Tốt Nhất Để Ngăn Chặn Điều Này

• Luôn sử dụng mô hình phục hồi FULL cho các cơ sở dữ liệu trong môi trường sản xuất và cấu hình kế hoạch bảo trì để tạo ra các backup log giao dịch. Nếu bạn sử dụng mô hình phục hồi SIMPLE, hãy thực hiện backup khác biệt thường xuyên để giảm thiểu mất mát dữ liệu.
• Luôn tự động hóa quy trình backup. Bạn có thể sử dụng kế hoạch bảo trì SQL Server, bộ lập lịch tác vụ Windows hoặc tác vụ SQL Server agent.
• Xác thực các backup bằng cách sử dụng RESTORE VERIFYONLY và test phục hồi định kỳ. Bạn cũng có thể cấu hình quy trình xác thực backup trong các kế hoạch bảo trì cơ sở dữ liệu. Nếu bạn có máy chủ bổ sung, hãy kiểm tra quy trình phục hồi thường xuyên.
• Lưu trữ backup ở vị trí tách biệt và an toàn. Bạn có thể sử dụng lưu trữ đám mây, điều này đáng tin cậy hơn.
• Sử dụng các công cụ giám sát (các tác vụ SQL Agent, các script tùy chỉnh hoặc các giải pháp bên thứ ba như Stellar, Redgate hoặc SQL Monitor) để phát hiện các backup bị thiếu. Nếu bạn không thể đầu tư tiền vào các công cụ giám sát, hãy tạo các script tùy chỉnh gửi cảnh báo nếu backup thất bại.

Kết Luận

Phục hồi cơ sở dữ liệu SQL Server mà không có backup log là khả thi, nhưng điều này đi kèm với chi phí mất dữ liệu cao hơn, thời gian ngừng hoạt động và các SLA bị phá vỡ. Trong khi các bước thực hiện đơn giản (backup đầy đủ → backup khác biệt → phục hồi), những rủi ro vận hành là rất lớn. Một chiến lược backup vững chắc bao gồm việc thực hiện các backup log giao dịch thường xuyên là cách duy nhất để đảm bảo phục hồi đáng tin cậy theo thời điểm và tránh những cạm bẫy này trong môi trường sản xuất. Bây giờ, nếu cơ sở dữ liệu bị hỏng và bạn không có backup có sẵn, bạn có thể sử dụng các công cụ chuyên nghiệp như phần mềm phục hồi dữ liệu Stellar. Nó có nhiều tính năng giúp phục hồi cơ sở dữ liệu SQL. Cùng với các tệp cơ sở dữ liệu, bạn cũng có thể sửa chữa các tệp backup bị hỏng.