Chào anh chị em,
Trước khi bàn đến phần mềm backup nào tốt hơn, mình muốn bắt đầu bằng một tình huống: hệ thống chính ngừng hoạt động, tài khoản quản trị không còn đáng tin cậy, còn công việc thì vẫn phải tiếp tục.
Lúc đó, câu hỏi đầu tiên sẽ là: bản dữ liệu sạch gần nhất ở đâu, ai lấy được nó và bao lâu nữa ứng dụng mới chạy lại?
Đó cũng là điều mình muốn cùng mọi người trao đổi trong VIET NAM Backup Day 30.11. Bài viết này phát triển từ TEKLink224 trên Ransomware.VN, với một góc nhìn gần việc vận hành hằng ngày hơn: biến “đã backup” thành một quy trình có thể kiểm chứng.
Hãy bắt đầu từ công việc cần chạy lại
Một doanh nghiệp có thể lưu hợp đồng trên NAS, chạy phần mềm kế toán trên SQL Server và đặt máy ảo trên VMware hoặc Hyper-V. Sao lưu đủ terabyte mới giải quyết một phần câu chuyện. Cần biết hệ thống nào phải trở lại trước và nó cần những thành phần gì để hoạt động.
Hãy thống nhất hai mục tiêu: RPO là mức mất dữ liệu theo thời gian có thể chấp nhận; RTO là thời gian mục tiêu để khôi phục dịch vụ. Sau đó, dùng diễn tập để kiểm tra kế hoạch có đạt được hai mục tiêu ấy không.
Ví dụ minh họa: nếu bộ phận kế toán cần hệ thống hoạt động lại trong bốn giờ, một bản sao đầy đủ nhưng mất hai ngày để tải về vẫn chưa đáp ứng nhu cầu. Đây là ví dụ để lập kế hoạch, không phải cam kết thời gian phục hồi cho mọi hệ thống.
Bản sao cần sống sót qua sự cố của hệ thống chính
RAID giúp chịu lỗi ổ đĩa theo cấu hình. Snapshot hỗ trợ quay lại trạng thái trước đó. Đồng bộ giúp dữ liệu hiện diện ở nhiều nơi. Mỗi cơ chế đều có giá trị, nhưng cần xét tiếp tình huống tệp đã bị mã hóa, lịch sử bị xóa hoặc quyền quản trị bị lộ.
Một snapshot thông thường có thể bị xóa bởi tài khoản có đủ quyền. Một tác vụ đồng bộ có thể chuyển cả dữ liệu đã mã hóa sang nơi nhận. Một ổ sao lưu luôn kết nối cũng cần được kiểm tra quyền ghi/xóa từ máy nguồn.
Vì vậy, mình xem 3-2-1-1-0 như một khung rà soát: ba bản dữ liệu, hai loại phương tiện, một bản ngoài địa điểm, một bản offline hoặc bất biến, cùng kiểm tra phục hồi để phát hiện và xử lý lỗi. Số 0 là mục tiêu kiểm tra, không phải bảo đảm an toàn tuyệt đối.
Điểm đáng kiểm tra nhất là quyền quản trị thực tế. Hãy tách quyền nguồn và đích, xem lại chính sách giữ phiên bản, thời hạn bất biến và cách truy cập khi hạ tầng chính không sử dụng được.
Với NAS: kiểm kê đủ dữ liệu, đủ đường phục hồi
Trên Synology, QNAP hay nền tảng khác, dữ liệu có thể nằm ở shared folder, LUN iSCSI hoặc trong máy ảo dùng lưu trữ NAS. Cấu hình, quyền truy cập và thông tin cần để dựng lại dịch vụ cũng cần được đưa vào kế hoạch.
Hãy kiểm tra từng phạm vi sao lưu thay vì suy luận rằng một job chạy thành công đã bao phủ tất cả. Kết hợp snapshot, backup nhiều phiên bản và bản sao ở hệ thống độc lập theo khả năng thiết bị.
Immutable snapshot cần đúng model, hệ điều hành và cấu hình được nhà sản xuất hỗ trợ. Tính bất biến trong một khoảng thời gian cũng cần đi cùng kế hoạch cho hỏng thiết bị, thiếu dung lượng hoặc sự cố tại cùng địa điểm.
Với Server và máy ảo: phục hồi cả dịch vụ
Windows Server, Linux, ESXi và Hyper-V thường kéo theo nhiều phụ thuộc: cấu hình mạng, danh tính, cơ sở dữ liệu và ứng dụng. Một máy ảo bật lên được là dấu hiệu tốt; kết quả cuối cùng cần được xác nhận bằng chức năng mà người dùng thực sự sử dụng.
Thử trong môi trường riêng, kiểm tra tính nhất quán phù hợp với ứng dụng và ghi lại những gì cần để phục hồi. Giữ an toàn catalog, cấu hình, khóa mã hóa và thông tin truy cập cần thiết. Với Cloud hoặc Object Storage, kiểm tra điều kiện versioning, retention, khóa chống xóa và thời gian lấy dữ liệu về.
Với SQL Server: xác nhận chuỗi backup dùng được
Sao chép MDF/LDF của database đang hoạt động không thay thế quy trình backup nhất quán. Hãy dùng backup SQL Server hoặc giải pháp hỗ trợ ứng dụng phù hợp, rồi thử restore riêng.
Chọn lịch Full, Differential và Transaction Log Backup theo mục tiêu phục hồi. Log Backup áp dụng cho Full/Bulk-logged; Simple không hỗ trợ. Để khôi phục theo thời điểm, cần recovery model và chuỗi backup phù hợp; Bulk-logged có giới hạn khi log chứa thao tác bulk.
Buổi kiểm tra nên đi hết từ full, differential phù hợp và các log cần thiết đến dữ liệu trên ứng dụng. File .bak tồn tại là điểm bắt đầu để kiểm tra.
Một việc có thể làm ngay tuần này
Chọn một dịch vụ quan trọng và thống nhất tiêu chí “hoạt động trở lại”.
Tìm điểm khôi phục dự kiến; ghi rõ vị trí backup, người phụ trách và cách truy cập độc lập.
Restore trong môi trường riêng, kiểm tra tệp/database và thao tác nghiệp vụ mẫu.
Đo thời gian, ghi nhận khoảng dữ liệu bị thiếu, lỗi và phụ thuộc còn thiếu.
Phân công xử lý, hẹn kiểm tra lại và lưu một hướng dẫn đủ để người thay ca làm theo.
Với dữ liệu lớn, nên đo cả băng thông, tốc độ đọc backup, dung lượng nơi nhận và chi phí truyền tải. Kết quả đo giúp mình biết nên đầu tư vào đâu tiếp theo.
Mời mọi người cùng học tại VIET NAM Backup Day 30.11
Mình mong nhóm trở thành nơi anh chị em IT, System Administrator, DBA, bảo mật và đơn vị triển khai chia sẻ kinh nghiệm có thể áp dụng: NAS Synology/QNAP, Server, VMware/Hyper-V, SQL Server, Cloud, Offline Backup và Immutable Backup.
Người mới có thể mang tới một câu hỏi. Người đã vận hành lâu năm có thể chia sẻ một lỗi, một cấu hình hoặc một lần diễn tập. Những chi tiết ấy giúp cộng đồng chuẩn bị tốt hơn trước sự cố.
Tham gia nhóm Zalo VIET NAM Backup Day 30.11
Nếu muốn bắt đầu bằng một câu hỏi, hãy chia sẻ: “Lần gần nhất mình thử restore là khi nào, mất bao lâu và còn vướng điều gì?”
Chúc mọi người luôn có một đường phục hồi đã được kiểm tra.
Tùng TEK · TBackup by TUNGTEK
TEKLink224 · Link.TUNGTEK.com/224
Bản biên tập riêng cho TEKPost, có hỗ trợ AI, từ bài gốc trên Ransomware.VN. Ảnh và QR từ tài nguyên TUNGTEK.