#TEKLink208 | Link.TUNGTEK.com/208
Khi database kế toán, ERP hoặc kho không mở được, áp lực lớn nhất thường là đưa công việc trở lại nhanh. Nhưng thao tác tiếp theo có thể ảnh hưởng chính bộ dữ liệu đang cần giữ. Trước khi thử attach, rebuild log hay repair, nên xác định nguồn gốc nào đã được bảo toàn và đang có những bản sao nào.
Bài này dành cho người quản trị và chủ hệ thống muốn chuẩn bị một cuộc trao đổi kỹ thuật có căn cứ. Ba câu hỏi xuyên suốt là: nguồn nào còn có thể sử dụng, hướng xử lý nào cần kiểm thử, và dữ liệu nào phải được đối chiếu trước khi đưa vào vận hành.
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.
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.
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?
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.
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.
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á.
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.
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 đủ.
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.
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.
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.
Chuẩn bị đúng nguồn giúp đánh giá có căn cứ; tiêu chí nghiệm thu giúp biết kết quả có phục vụ công việc hay không. Với dữ liệu bị ransomware, RFC — Ransomware Fast Check — cần gắn với mẫu và phạm vi được kiểm tra. Kết quả trên mẫu chưa xác nhận khả năng phục hồi cả hệ thống.
Bài Hướng Dẫn Và Checklist Đầy Đủ
Đọc bộ hướng dẫn SQL Server qua liên kết gốc của chiến dịch: Link.TUNGTEK.com/208 · #TEKLink208.
Bản này được biên tập lại từ bài gốc của TUNGTEK/TRecovery: https://cuudulieu.top/blog/phuc-hoi-sql-server-mdf-ldf/.
Tài Liệu Tham Khảo
Tùng TEK · TRecovery by TUNGTEK 🇻🇳 · Hotline/Zalo: 0963 509 115.
🇻🇳 Sự cố dữ liệu? Gọi TUNGTEK.
#TEKLink208 #SQLServer #MDF #LDF #Ransomware #TRecovery