DATABASE RECOVERY / TRECOVERY
Phục Hồi SQL Server MDF/LDF: Cần Chuẩn Bị Gì Khi Database Lỗi Hoặc Bị Ransomware?
Cần giữ file nào, ghi nhận lỗi gì và kiểm định ra sao khi SQL Server gặp sự cố? Hướng dẫn chuẩn bị nguồn, backup và thông tin nghiệp vụ trước khi đánh giá phục hồi.
#TEKLink208 | Link.TUNGTEK.com/208
Đọc hướng dẫn →
Mục lục bài viết
SQL Server gặp sự cố thường kéo theo gián đoạn kế toán, ERP, kho hoặc ứng dụng nội bộ. Việc chuẩn bị đúng nguồn và thông tin giúp chọn hướng xử lý có căn cứ. Bài này hướng dẫn chủ hệ thống và DBA cần giữ gì, trao đổi điều gì và kiểm định thế nào trước khi đưa dữ liệu trở lại sử dụng.
Trước Khi Thử Attach Hoặc Repair, Hãy Bảo Toàn Nguồn
#Khi kế toán không vào được phần mềm hoặc ERP ngừng ghi nhận giao dịch, áp lực thường là làm database mở lại ngay. Tuy nhiên, attach/detach lặp lại, thay file hoặc sửa trực tiếp có thể làm thay đổi nguồn cần đánh giá. Mục tiêu đầu tiên là giữ lại những lựa chọn phục hồi còn có thể kiểm tra.
- Phối hợp DBA để kiểm soát việc ghi tiếp và ghi nhận đúng thời điểm phát hiện.
- Nếu nghi ransomware còn hoạt động, cô lập đường tấn công theo kế hoạch ứng cứu; quyết định tắt nguồn cần cân nhắc chứng cứ đang tồn tại.
- Giữ bộ file gốc, backup và log; tạo bản làm việc bằng phương pháp phù hợp với tình trạng lưu trữ.
Lưu lại cả những thao tác đã thử và thông báo lỗi. Nếu phần cứng đang suy giảm, cần đánh giá cách sao chụp trước khi tạo thêm tải đọc. Một lần copy file đang được SQL ghi không tự bảo đảm có bản database nhất quán.
Tham khảo: Microsoft Learn — Database Detach and Attach · Microsoft Learn — Troubleshoot Database Consistency Errors
Ghi Nhận Trạng Thái Để Chọn Đúng Việc Cần Kiểm Tra
#Đừng mô tả sự cố chỉ bằng câu “MDF hỏng”. Hãy ghi trạng thái database và chụp thông báo đầy đủ để nhóm xử lý biết recovery đang bị ngăn, đang diễn ra hay đã thất bại.
| Biểu Hiện | Câu Hỏi Cần Làm Rõ |
|---|---|
| RECOVERY PENDING | Tài nguyên hoặc khả năng truy cập file đang ngăn recovery ở đâu? |
| SUSPECT | Vì sao recovery lúc khởi động thất bại? Primary filegroup có thể bị hỏng. |
| RECOVERING | Recovery có tiếp tục tiến triển, hay xuất hiện lỗi mới? |
Vuốt ngang để xem bảng trên màn hình nhỏ.
RECOVERY PENDING không mặc định chứng minh corruption. Đối chiếu ERRORLOG với file, đường dẫn và tài nguyên trước khi chọn phương án. EMERGENCY là chế độ chẩn đoán hạn chế quyền truy cập; việc chuyển sang chế độ này chưa chứng minh dữ liệu đã an toàn.
Tham khảo: Microsoft Learn — Database States
Lưu Đúng Thông Báo 823, 824, 825 Và Lỗi Attach
#| Dấu Hiệu | Thông Tin Nên Giữ | Quyết Định Ban Đầu |
|---|---|---|
| 823 — lỗi I/O do hệ điều hành báo | Mã OS, tên file, offset và thời điểm. | Kiểm tra đường lưu trữ cùng quản trị hạ tầng. |
| 824 — kiểm tra I/O không nhất quán | Page/file và loại kiểm tra thất bại, như checksum. | Đối chiếu cấu trúc database và lớp lưu trữ. |
| 825 — đọc được sau khi thử lại | Số lần thử, lỗi trước đó và sự kiện hệ thống. | Điều tra I/O dù người dùng vẫn đọc được dữ liệu. |
Vuốt ngang để xem bảng trên màn hình nhỏ.
SQL ERRORLOG, Windows Event Log và lịch sử trong msdb.dbo.suspect_pages giúp đối chiếu diễn biến; một nguồn log không thay cho toàn bộ kiểm tra. Nếu gặp 5171, xác minh file được chọn có phải primary data file không. Với 9004, giữ chi tiết lỗi xử lý transaction log. Với lỗi mở file như 5120, giữ cả phần thông báo hệ điều hành. Không sửa file chỉ từ một mã lỗi.
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
Chuẩn Bị Cả Bộ Database Và Bối Cảnh Hạ Tầng
#Một database có thể có MDF, nhiều NDF, một hoặc nhiều LDF và thành phần phụ. MDF/NDF lưu dữ liệu, LDF phục vụ recovery giao dịch; LDF không phải bản sao đầy đủ của dữ liệu. Giữ tên, đường dẫn và quan hệ bộ file để tránh ghép nhầm database hoặc trộn các mốc sao chép.
| Lớp Dữ Liệu | Cần Ghi Nhận |
|---|---|
| HDD/SSD, RAID, NAS/SAN | Cấu hình, tình trạng ổ, volume và sự kiện I/O. |
| Máy ảo | VMDK/VHDX, chuỗi đĩa/snapshot, datastore và file system trong guest. |
| SQL Server | Phiên bản/build, bộ file, container phụ và ứng dụng phụ thuộc. |
Vuốt ngang để xem bảng trên màn hình nhỏ.
VMFS trên datastore VMware và NTFS trong máy ảo là hai lớp khác nhau. Sao chép được MDF từ một bộ đĩa ảo thiếu hoặc volume sai cấu trúc chưa xác nhận file hoàn chỉnh. Về cấu trúc truyền thống, data page SQL Server là 8 KiB với header 96 byte; metadata, bản đồ cấp phát PFS/GAM/SGAM/IAM và dữ liệu LOB cũng ảnh hưởng khả năng diễn giải bản ghi.
Tham khảo: Microsoft Learn — Database Files and Filegroups · Microsoft Learn — The Transaction Log · Microsoft Learn — Page and Extent Architecture Guide · Microsoft Learn — Database Detach and Attach
Còn Backup Hoặc Mất LDF: Cần Đánh Giá Nguồn Nào Trước?
#Trước khi thử sửa, hãy lập danh sách bản sao độc lập, full/differential/log backup và thời điểm của từng nguồn. Một bản backup cũ có thể là nguồn đối chiếu hoặc hướng restore; bản mới nhất chưa chắc sạch hoặc dùng được. Lựa chọn phải gắn với recovery model và mốc dữ liệu doanh nghiệp cần.
RESTORE VERIFYONLY giúp kiểm tra tính đầy đủ và khả năng đọc backup nhưng không thay cho restore thật. Sau restore thử, cần xác định dữ liệu đến đâu và có sử dụng được không. Giữ nguồn khác cho đến khi đánh giá xong; đừng loại bỏ LDF hoặc file còn sót chỉ vì đã thấy một BAK.
Mất LDF không tạo ra công thức “xóa log rồi attach”. FOR ATTACH_REBUILD_LOG yêu cầu database read/write, shutdown sạch và đủ MDF/NDF; thao tác này làm đứt chuỗi log backup. Không được giả định crash hoặc thiếu file đáp ứng các điều kiện đó.
Với snapshot, xác minh loại, nguồn và thời điểm. Database snapshot SQL Server phụ thuộc database gốc và không thay cho backup độc lập. Snapshot máy ảo cần được kiểm tra cùng chuỗi đĩa và trạng thái ứng dụng trước khi xem là nguồn phục hồi.
Tham khảo: Microsoft Learn — Backup Overview · Microsoft Learn — RESTORE VERIFYONLY · Microsoft Learn — CREATE DATABASE: ATTACH_REBUILD_LOG · Microsoft Learn — Database Snapshots
Nếu Nghi Ransomware, Phân Biệt Nguồn Sạch, Giải Mã Và Trích Xuất
#Cần kiểm tra nội dung thật trên mẫu được ủy quyền, thay vì suy luận từ phần mở rộng. Giữ ransom note, file mã hóa và những bản sao trước sự cố; chúng hỗ trợ đánh giá phạm vi, nhưng không tự xác nhận tuyên bố của đối tượng tống tiền.
- Nguồn sạch: đánh giá bản sao chưa bị tác động, khả năng restore và mốc dữ liệu.
- Khóa/decryptor hợp lệ: xác minh đúng biến thể và thử trên bản sao trước khi áp dụng rộng.
- Vùng còn đọc được: đánh giá page, metadata, file phụ và LOB để xác định bản ghi có thể diễn giải.
Mã hóa một phần hoặc không liên tục có thể để lại vùng chưa tác động; điều đó không tương đương một tỷ lệ phục hồi. Nếu toàn bộ nội dung được mã hóa mạnh, không có khóa hoặc nguồn thay thế dùng được, có thể không trích xuất được dữ liệu rõ. Cấu trúc sửa được không thay thế thuật toán giải mã.
TDE là mã hóa hợp lệ của SQL Server. Khi chuyển database dùng TDE bằng chứng thư, cần đúng certificate và private key; EKM cần cơ chế truy cập khóa tương ứng. Bảo quản vật liệu khóa riêng và chuyển qua kênh đã thống nhất. Nếu ransomware tác động thêm, cả lớp TDE và vùng mã hóa mới đều cần được đánh giá.
Tham khảo: Microsoft Learn — Transparent Data Encryption · Microsoft Learn — Move a TDE-Protected Database · Microsoft Learn — Page and Extent Architecture Guide
Bảy Bước Để Thống Nhất Phương Án Phục Hồi
#TRecovery by TUNGTEK 🇻🇳 đề xuất dùng các mốc quyết định dưới đây để chủ dữ liệu và nhóm kỹ thuật thống nhất phạm vi. Đây là quy trình đánh giá, kết quả phụ thuộc nguồn thực tế.
- Xác định ưu tiên
Nêu ứng dụng đang gián đoạn, phân hệ quan trọng và mốc dữ liệu cần dùng; khoanh vùng sự cố với quản trị hệ thống.
- Bảo toàn và ghi nhận
Giữ nguồn, log và thao tác đã thực hiện; tạo bản sao/image phù hợp trước thử nghiệm.
- Kiểm tra tính đầy đủ
Đối chiếu lưu trữ, bộ MDF/NDF/LDF, backup và các container phụ để xác định thành phần thiếu.
- Đánh giá hướng khả thi
Kiểm tra nguồn sạch, lỗi cấu trúc/log, trạng thái SQL và phạm vi mã hóa nếu có.
- Thống nhất cách xử lý
Chọn restore, giải quyết nguyên nhân hạ tầng hoặc trích xuất trên bản làm việc; ghi rõ giới hạn cần kiểm tra.
- Kiểm định với chủ dữ liệu
Đối chiếu kỹ thuật, chứng từ, quan hệ và ứng dụng ở môi trường thử; ghi nhận sai lệch.
- Bàn giao và chuyển vận hành
Bàn giao phạm vi đã xác minh, phần thiếu và hướng dẫn liên quan; triển khai theo kế hoạch đã thống nhất.
Tham khảo: Microsoft Learn — Troubleshoot Database Consistency Errors · Microsoft Learn — DBCC CHECKDB · Microsoft Learn — Backup Overview
Thống Nhất Tiêu Chí Nghiệm Thu Trước Khi Bắt Đầu
#Kết quả cần được mô tả bằng dữ liệu có thể kiểm chứng. Chuyển database ONLINE, attach thành công hoặc mở được giao diện ứng dụng chưa chứng minh mọi chứng từ và giao dịch còn đầy đủ.
| Lớp Nghiệm Thu | Ví Dụ Cần Đối Chiếu |
|---|---|
| Kỹ thuật | DBCC CHECKDB khi phù hợp; table, schema, LOB, key/constraint và phần còn lỗi. |
| Nghiệp vụ | Kỳ dữ liệu, chứng từ, tồn kho/công nợ và quan hệ bảng từ nguồn thực tế. |
| Vận hành | Kết nối, quyền và luồng thao tác ứng dụng trong môi trường riêng. |
Vuốt ngang để xem bảng trên màn hình nhỏ.
DBCC CHECKCONSTRAINTS hỗ trợ kiểm tra FOREIGN KEY/CHECK; vẫn cần đối chiếu các quy tắc nghiệp vụ và nguồn thực tế. Số dòng chỉ có ý nghĩa khi biết mốc so sánh. Nếu một tập dữ liệu được trích xuất riêng, báo cáo cần nêu table/record đã lấy được và điều kiện sử dụng.
REPAIR_ALLOW_DATA_LOSS có thể loại bỏ dữ liệu và để lại sai lệch quan hệ hoặc giao dịch. Microsoft ưu tiên restore từ backup tốt; repair mất dữ liệu là phương án cuối. Chủ dữ liệu cần được giải thích hậu quả cụ thể trước khi quyết định, trên nguồn đã bảo toàn.
Tham khảo: Microsoft Learn — DBCC CHECKDB · Microsoft Learn — DBCC CHECKCONSTRAINTS · Microsoft Learn — Troubleshoot Database Consistency Errors
Checklist Tiếp Nhận Qua Kênh Bảo Mật
#Có thể bắt đầu trao đổi bằng thông tin hệ thống và lỗi, chưa cần gửi toàn bộ database. Chuẩn bị danh sách sau để nhóm kỹ thuật hướng dẫn phạm vi chuyển dữ liệu phù hợp:
- Mã lỗi đầy đủ, ảnh màn hình đã che thông tin nhạy cảm, thời điểm phát hiện và diễn biến trước đó.
- Phiên bản/build SQL Server, recovery model nếu biết và phần mềm đang sử dụng database.
- MDF/NDF/LDF cùng thành phần phụ; BAK/TRN, bản sao và snapshot hiện có, giữ nguyên quan hệ bộ file.
- SQL ERRORLOG, Windows Event Log, lịch sử backup và danh sách thao tác đã thử.
- Cấu hình ổ đĩa/RAID/NAS/SAN/máy ảo, tình trạng nguồn và vị trí dữ liệu.
- Danh sách phân hệ/chứng từ ưu tiên, mốc dữ liệu cần đối chiếu và người phụ trách nghiệm thu.
- Nếu nghi ransomware: ransom note, phần mở rộng, mẫu được ủy quyền; ghi nhận TDE và bảo quản vật liệu khóa riêng.
Không đăng database, mật khẩu, chứng thư/khóa hoặc thông tin khách hàng lên bình luận công khai. Thống nhất người có quyền bàn giao, kênh tiếp nhận và phạm vi truy cập dữ liệu nhạy cảm trước khi chuyển file. Giữ một bản nguồn được bảo toàn cùng nhật ký các lần bàn giao.
Câu Hỏi Thường Gặp Khi Chuẩn Bị Database
#| Câu Hỏi | Trả Lời |
|---|---|
| Chỉ gửi MDF có đủ để đánh giá không? | Có thể giúp kiểm tra ban đầu, nhưng chưa đại diện đầy đủ database. Cần kiểm kê NDF, LDF, container phụ, backup và thông tin hệ thống trước khi xác định hướng xử lý. |
| Database RECOVERY PENDING có cần sửa MDF ngay không? | Chưa nên kết luận. Kiểm tra file, đường dẫn, quyền và tài nguyên bằng thông báo đầy đủ; chỉ đánh giá sửa cấu trúc khi có bằng chứng phù hợp. |
| Đã thử attach hoặc repair rồi có còn đánh giá được không? | Vẫn có thể tiếp nhận để kiểm tra. Cần nói rõ thao tác, thời điểm và bộ file bị thay đổi; tìm bản gốc hoặc bản sao trước thao tác nếu còn. |
| File bị mã hóa ít có nghĩa là cứu được gần hết không? | Không thể suy ra như vậy. Những vùng còn đọc được phải đủ để diễn giải bản ghi và quan hệ; kết quả được xác nhận bằng dữ liệu nghiệp vụ đã đối chiếu. |
| Có BAK thì có thể bỏ qua LDF và các file khác không? | Không nên loại bỏ nguồn trước khi restore và kiểm định. BAK có thể không dùng được hoặc thiếu mốc cần thiết; log và nguồn khác vẫn cần cho đánh giá. |
| Database mở được thì có thể đưa phần mềm chạy ngay không? | Cần kiểm tra cấu trúc, dữ liệu trọng yếu, quyền và thao tác nghiệp vụ trên môi trường thử, rồi chốt kế hoạch chuyển vận hành với đơn vị quản trị. |
Vuốt ngang để xem bảng trên màn hình nhỏ.
Tham khảo: Microsoft Learn — Database Files and Filegroups · Microsoft Learn — Database States · Microsoft Learn — DBCC CHECKDB · Microsoft Learn — Backup Overview
Trao Đổi Để Đánh Giá Trường Hợp Cụ Thể
#TRecovery by TUNGTEK 🇻🇳 tiếp nhận thông tin sự cố SQL Server để đánh giá nguồn và hướng xử lý phù hợp. Hotline/Zalo: 0963 509 115. Nên gửi trước mã lỗi, hạ tầng, bộ file hiện có và tình trạng backup qua kênh tiếp nhận đã thống nhất.
Đọc thêm bài phân tích SQL Server MDF/LDF, trạng thái database và giới hạn trích xuất trên TUNGTEK.com. Với dữ liệu bị ransomware, tham khảo CuuDuLieuMaHoa.com để trao đổi hướng đánh giá chuyên sâu.
🇻🇳 Sự cố dữ liệu? Gọi TUNGTEK.
TRECOVERY BY TUNGTEK 🇻🇳
Trao đổi hiện trạng và dữ liệu ưu tiên
Tài liệu tham khảo
- Microsoft Learn — Database States
- 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 — Database Files and Filegroups
- Microsoft Learn — Page and Extent Architecture Guide
- Microsoft Learn — The Transaction Log
- 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 — Transparent Data Encryption
- Microsoft Learn — Move a TDE-Protected Database
- Microsoft Learn — DBCC CHECKDB
- Microsoft Learn — DBCC CHECKCONSTRAINTS
- Microsoft Learn — Troubleshoot Database Consistency Errors
- Microsoft Learn — Manage the suspect_pages Table