SQL Server MDF/LDF Hỏng Hoặc Bị Ransomware: Phân Biệt Lỗi Và Khả Năng Trích Xuất

Khi Database Không Mở Được, Cần Xác Định Điều Gì?

ERP hoặc phần mềm kế toán mất kết nối có thể do SQL Server ngừng hoạt động, mất quyền truy cập file hay lỗi lưu trữ. MDF không attach được cũng chưa chứng minh mọi bản ghi đã mất. Đổi phần mở rộng hoặc xuất hiện thư đòi tiền chuộc là dấu hiệu cần điều tra ransomware, chưa đủ để xác định họ mã độc hoặc phạm vi tác động.

• Truy cập/tài nguyên: file thiếu, đường dẫn thay đổi, quyền dịch vụ hoặc dung lượng không đủ.
• Cấu trúc/tính nhất quán: page, metadata hoặc transaction log không còn phù hợp.
• Ransomware: cần xác minh nội dung file thật, nguồn sạch và mức độ mã hóa.

Các nhóm có thể cùng tồn tại. Trước khi thử attach, hãy lưu thông báo đầy đủ, phiên bản SQL Server và danh sách MDF/NDF/LDF. Database từ phiên bản mới hơn không attach vào engine cũ hơn. Giữ nguồn nguyên trạng và đánh giá trên bản sao phù hợp; file đang được ghi không nên được coi là bản sao nhất quán chỉ vì copy hoàn tất.

Xem lớn

Attach thất bại cần được đối chiếu với bộ file và lỗi cụ thể.

Mở ảnh gốc

Tham khảo: Microsoft Learn — Database Detach and Attach · Microsoft Learn — Database Files and Filegroups

SUSPECT Và RECOVERY PENDING Khác Nhau Thế Nào?

Trạng thái chỉ dẫn điểm bắt đầu điều tra. Đọc SQL ERRORLOG theo thời điểm sự cố, thay vì chọn một lệnh sửa chỉ dựa trên tên trạng thái.

Xem lớn

Trạng thái database là điểm bắt đầu để điều tra nguyên nhân.

Mở ảnh gốc

EMERGENCY là chế độ chẩn đoán có quyền truy cập hạn chế, không phải dấu xác nhận dữ liệu đã được phục hồi. Mọi thay đổi trạng thái cần được DBA đánh giá trên nguồn đã bảo toàn.

Tham khảo: Microsoft Learn — Database States

Đọc Đúng Các Lỗi SQL Server 823, 824 Và 825

Xem lớn

Lỗi I/O và kiểm tra page cần được xem cùng lớp lưu trữ.

Mở ảnh gốc

Ghi nhận tên file, offset/page, thời điểm và thông báo kèm theo; đối chiếu Windows Event Log. msdb.dbo.suspect_pages hỗ trợ xem lịch sử page lỗi nhưng không phải bản kiểm toán toàn bộ database. Lỗi 825 cần xử lý nguyên nhân lưu trữ trước khi thất bại trở nên liên tục.

5171 nói file không phải primary database file; cần xác minh đúng loại file. 9004 liên quan xử lý transaction log. Lỗi mở file như 5120 cần đọc mã hệ điều hành và quyền truy cập. Các dấu hiệu này không tự chứng minh ransomware hay tỷ lệ mất dữ liệu.

Tham khảo: Microsoft Learn — MSSQLSERVER_823 · Microsoft Learn — MSSQLSERVER_824 · Microsoft Learn — MSSQLSERVER_825 · Microsoft Learn — Database Engine Events and Errors 5000–5999 · Microsoft Learn — MSSQLSERVER_9004 · Microsoft Learn — Manage the suspect_pages Table

Từ HDD/SSD, RAID Và Máy Ảo Đến SQL Data Page

Sự cố có thể nằm dưới database: HDD/SSD, RAID, NAS/SAN hoặc file system. Với máy ảo, cần phân biệt datastore như VMFS trên host VMware, file VMDK/VHDX và file system trong guest như NTFS. MDF đọc ra từ một volume sai cấu trúc hoặc bộ đĩa ảo thiếu có thể không phải nguồn hoàn chỉnh.

MDF là file dữ liệu chính, NDF là file dữ liệu phụ; LDF chứa transaction log phục vụ recovery. LDF không phải bản sao đầy đủ của MDF. Chuỗi LSN giúp đối chiếu trình tự log, không biến mọi log còn sót thành một lịch sử dữ liệu hoàn chỉnh.

• Trong kiến trúc page truyền thống, SQL Server dùng page 8 KiB và header 96 byte.
• PFS theo dõi trạng thái/free space; GAM/SGAM và IAM mô tả cấp phát extent cho đối tượng.
• Metadata/system catalog, index, LOB và row-overflow cũng phải còn đủ để diễn giải dữ liệu.

Xem lớn

Phân tích page giúp đánh giá cấu trúc và vùng dữ liệu còn đọc được.

Mở ảnh gốc

Một chứng từ có thể phụ thuộc nhiều bảng, page hoặc file. Về đánh giá phục hồi, còn đọc được nhiều byte không đồng nghĩa có đủ chứng từ: một vùng metadata nhỏ bị hỏng có thể ảnh hưởng nhiều đối tượng. Cần xác định bản ghi nào thực sự lấy được và kiểm định từng quan hệ.

Tham khảo: Microsoft Learn — Database Files and Filegroups · Microsoft Learn — Page and Extent Architecture Guide · Microsoft Learn — The Transaction Log · Microsoft Learn — Troubleshoot Database Consistency Errors

Mất LDF, BAK Hỏng Hoặc Thiếu Backup Chain

Attach bộ file database và restore backup là hai hướng khác nhau. Hãy kiểm kê full, differential và log backup, xác định recovery model và trình tự phù hợp; không chỉ chọn BAK lớn nhất hoặc mới nhất. Ưu tiên restore thử bản sạch trong môi trường riêng và kiểm tra dữ liệu sau restore.

RESTORE VERIFYONLY kiểm tra khả năng đọc và tính đầy đủ của bộ backup, không thay cho restore thật hoặc kiểm tra toàn bộ cấu trúc dữ liệu. Một file BAK có tên và dung lượng hợp lý chưa đủ chứng minh nó dùng được.

FOR ATTACH_REBUILD_LOG chỉ dành cho database read/write, đã shutdown sạch và có đủ MDF/NDF. Thao tác này làm đứt chuỗi log backup; Microsoft khuyến nghị full backup sau đó. Khi crash, thiếu NDF hoặc còn giao dịch chưa hoàn tất, không thể áp dụng điều kiện này bằng cách xóa LDF.

Snapshot cần được xác minh thời điểm, tính nhất quán và khả năng truy cập. Riêng database snapshot của SQL Server phụ thuộc database nguồn, không thay cho backup độc lập. Snapshot máy ảo cũng cần được kiểm tra cùng chuỗi đĩa và ứng dụng; đừng mặc định đó là bản sạch sau sự cố.

Xem lớn

Transaction log và bộ backup có vai trò khác nhau khi phục hồi.

Mở ảnh gốc

Tham khảo: Microsoft Learn — CREATE DATABASE: ATTACH_REBUILD_LOG · Microsoft Learn — Database Detach and Attach · Microsoft Learn — Backup Overview · Microsoft Learn — RESTORE VERIFYONLY · Microsoft Learn — Database Snapshots · Microsoft Learn — The Transaction Log

SQL Server Bị Ransomware: Khi Nào Có Thể Trích Xuất Dữ Liệu?

Bước đầu là xác minh phạm vi mã hóa trên mẫu được phép và bộ dữ liệu thật. Mã hóa toàn file, theo khối hoặc không liên tục tạo ra các điều kiện khác nhau. Giữ nguyên file mã hóa, backup và nguồn thay thế để so sánh; một phần mở rộng không mô tả đầy đủ cơ chế mã hóa.

Xem lớn

Phạm vi mã hóa và cấu trúc còn nguyên quyết định hướng đánh giá.

Mở ảnh gốc

Khả năng trích xuất cần đối chiếu page chưa mã hóa, catalog, LOB, file phụ, log và bản sao có thể dùng. Page còn nguyên chưa bảo đảm table hoặc quan hệ đầy đủ. Về giới hạn mật mã, nội dung đã bị mã hóa mạnh toàn bộ có thể không lấy được dữ liệu rõ nếu thiếu khóa và không có nguồn thay thế dùng được.

TDE là cơ chế mã hóa dữ liệu hợp lệ của SQL Server, không phải dấu hiệu ransomware. Với TDE dùng chứng thư, cần đúng certificate và private key để chuyển database; triển khai EKM cần cơ chế truy cập khóa tương ứng. Sửa MDF không thay thế khóa TDE. Đánh giá khả năng trích xuất dữ liệu mã hóa phải xét cả hai lớp nếu ransomware tác động lên database đã dùng TDE.

Tham khảo: Microsoft Learn — Page and Extent Architecture Guide · Microsoft Learn — Transparent Data Encryption · Microsoft Learn — Move a TDE-Protected Database · Microsoft Learn — Backup Overview

Bảy Bước Ra Quyết Định Phục Hồi SQL Server

Chọn hướng xử lý dựa trên bằng chứng và ưu tiên nghiệp vụ. Quy trình dưới đây giúp quản trị viên thống nhất quyết định trước mỗi thao tác có thể thay đổi nguồn.

1. Khoanh vùng sự cố

   Cô lập hệ thống khi nghi ransomware đang hoạt động; kiểm soát việc ghi tiếp và phối hợp nhóm ứng cứu về chứng cứ cần giữ.

2. Bảo toàn nguồn

   Ghi nhận thời điểm, tình trạng và bộ file. Tạo bản sao/image phù hợp; xác minh bản sao khi có thể trước khi thử nghiệm.

3. Kiểm tra lưu trữ và bộ file

   Xác định tình trạng I/O, volume và tính đầy đủ MDF/NDF/LDF/BAK/TRN, cùng thành phần phụ nếu database sử dụng.

4. Đánh giá các nguồn phục hồi

   Đối chiếu backup sạch, trạng thái SQL, lỗi page/log và phạm vi mã hóa thực tế.

5. Chọn hướng xử lý

   Restore, giải quyết nguyên nhân tài nguyên/I/O, phục hồi cấu trúc hoặc trích xuất trên bản làm việc; ghi lại điều kiện và giới hạn.

6. Kiểm định trong môi trường thử

   Kiểm tra tính nhất quán kỹ thuật, dữ liệu nghiệp vụ và luồng ứng dụng cần dùng.

7. Bàn giao phạm vi đã xác minh

   Nêu rõ đối tượng lấy được, phần thiếu và hạn chế; khôi phục ứng dụng theo kế hoạch của đơn vị quản trị.

Xem lớn

Bảo toàn nguồn, chọn hướng xử lý rồi kiểm định trước bàn giao.

Mở ảnh gốc

Tham khảo: Microsoft Learn — Troubleshoot Database Consistency Errors · Microsoft Learn — Backup Overview · Microsoft Learn — DBCC CHECKDB

Database ONLINE Chưa Đủ: Cần Kiểm Định Những Gì?

ONLINE cho biết database có thể truy cập, không xác nhận mọi dữ liệu nghiệp vụ đầy đủ. Cần hai lớp nghiệm thu: cấu trúc kỹ thuật và kết quả sử dụng thực tế.

• Kỹ thuật: DBCC CHECKDB khi phù hợp; đối chiếu table, số dòng, key/constraint, LOB và các đối tượng bị thiếu.
• Nghiệp vụ: so sánh kỳ dữ liệu, chứng từ, tồn kho/công nợ hoặc chỉ tiêu tương ứng với nguồn thực tế.
• Ứng dụng: thử kết nối, quyền và thao tác cần thiết trên môi trường riêng trước khi chuyển vận hành.

DBCC CHECKCONSTRAINTS hỗ trợ kiểm tra FOREIGN KEY/CHECK, nhưng không thay cho đối chiếu nghiệp vụ. Số dòng phải được so với một mốc đáng tin cậy; đếm được nhiều record hoặc mở được phần mềm chưa đủ xác nhận chính xác.

REPAIR_ALLOW_DATA_LOSS là lựa chọn cuối khi không thể restore từ backup tốt. Nó có thể loại bỏ page/record và để lại sai lệch giao dịch hoặc quan hệ dữ liệu. Vì vậy cần bảo toàn bản sao trước, đánh giá hậu quả và kiểm định lại kết quả; bài này không cung cấp lệnh repair để chạy trên bản gốc.

Xem lớn

Database mở được vẫn cần kiểm tra nghiệp vụ và ứng dụng.

Mở ảnh gốc

Tham khảo: Microsoft Learn — DBCC CHECKDB · Microsoft Learn — DBCC CHECKCONSTRAINTS · Microsoft Learn — Troubleshoot Database Consistency Errors

Checklist DBA Cần Chuẩn Bị

Bộ thông tin rõ ràng giúp giảm thời gian chẩn đoán và tránh thử sai trên nguồn. Dùng danh sách này trước khi chuyển dữ liệu cho nhóm xử lý:

• Phiên bản/build SQL Server, recovery model nếu biết, thời điểm và triệu chứng đầu tiên.
• Toàn bộ MDF/NDF/LDF, BAK/TRN hiện có; giữ tên, đường dẫn và mối quan hệ bộ file.
• SQL ERRORLOG, Windows Event Log, lỗi ứng dụng và những thay đổi gần sự cố.
• Cấu hình HDD/SSD/RAID/NAS/SAN/máy ảo, tình trạng ổ đĩa và thao tác đã thực hiện.
• Backup/snapshot: nguồn, thời điểm, khả năng truy cập và kết quả restore thử nếu có.
• Khi nghi ransomware: ransom note, phần mở rộng và mẫu file được phép kiểm tra; ghi nhận TDE nếu có.
• Danh sách table/phân hệ ưu tiên và người có thể đối chiếu dữ liệu nghiệp vụ.

Không đăng database, mật khẩu, khóa/chứng thư hoặc dữ liệu khách hàng lên bình luận công khai. Tài liệu nhạy cảm cần được tiếp nhận qua kênh bảo mật thống nhất với chủ dữ liệu.

Câu Hỏi Thường Gặp

Tham khảo: Microsoft Learn — Database States · Microsoft Learn — Database Detach and Attach · Microsoft Learn — Move a TDE-Protected Database · Microsoft Learn — DBCC CHECKDB

Khi Cần Đánh Giá Chuyên Sâu

Khi backup không dùng được hoặc lỗi liên quan nhiều tầng, TRecovery by TUNGTEK 🇻🇳 có thể tiếp nhận thông tin để đánh giá hướng xử lý. Hãy bắt đầu bằng mã lỗi, phiên bản, hạ tầng, bộ file và tình trạng backup; phạm vi trích xuất cần được xác minh trước khi kết luận.