Kế hoạch backup doanh nghiệp: NAS, Server và SQL

1. Bắt đầu từ công việc doanh nghiệp cần chạy lại

Hãy thử một tình huống giả định: sáng thứ Hai, bộ phận kế toán cần mở phần mềm để chốt số liệu, nhưng máy chủ chưa hoạt động. IT nhìn thấy nhiều bản sao lưu trên kho lưu trữ; người dùng vẫn chưa thể làm việc vì còn thiếu cấu hình ứng dụng, quyền truy cập hoặc một thành phần phụ thuộc.

Khoảng trống ấy là lý do TUNGTEK khuyên doanh nghiệp lập kế hoạch backup theo dịch vụ cần phục hồi. Thay vì chỉ hỏi đã sao lưu bao nhiêu TB, hãy ghi rõ: ai cần dùng hệ thống, dữ liệu nào phải có trước, ai được phép dựng lại và ai xác nhận công việc đã tiếp tục được.

Trong tháng 11, có thể chọn một dịch vụ quan trọng để làm trọn quy trình. Với doanh nghiệp nhỏ, một lần diễn tập phần mềm kế toán hoặc thư mục dự án thường dễ tổ chức và đánh giá hơn việc cố khôi phục mọi thứ cùng lúc.

2. Chốt RPO, RTO cùng người sử dụng

RPO là mục tiêu về khoảng dữ liệu có thể mất, tính theo thời gian. RTO là mục tiêu thời gian đưa dịch vụ trở lại hoạt động. Chủ doanh nghiệp và bộ phận nghiệp vụ cần thống nhất hai con số này trước khi IT chọn lịch sao lưu, dung lượng và phương án khôi phục.

Lịch tạo backup chưa đủ để kết luận đạt RPO. Còn phải tính thời gian chuyển bản sao tới kho được bảo vệ và thời điểm dữ liệu sạch gần nhất có thể dùng. Tương tự, RTO cần bao gồm truy cập kho, dựng môi trường, nạp dữ liệu, kiểm tra ứng dụng và bàn giao; thời gian chép file chỉ là một phần.

3. Lập ma trận backup cho NAS, Server và SQL

Một bảng ngắn giúp nhìn ra phần đang bị bỏ sót. Mỗi dòng cần thêm tên người phụ trách chính, người thay thế, vị trí bản sao và hướng dẫn phục hồi tương ứng.

Đừng đánh đồng sao lưu một thư mục trên NAS với bảo vệ toàn bộ dịch vụ đang dùng NAS đó. Ví dụ, dữ liệu máy ảo nằm trong LUN có thể cần quy trình khác với các file Office trong thư mục chia sẻ. Hãy kiểm tra phạm vi phần mềm backup thực sự hỗ trợ trên cấu hình đang vận hành.

4. Kiểm tra quyền xóa và thời hạn giữ bản sao

Tình huống cần đặt ra là: tài khoản quản trị hệ thống chính đã bị lộ, bản sao nào vẫn còn được bảo vệ? CISA khuyến nghị duy trì backup offline, mã hóa và kiểm tra định kỳ vì ransomware có thể tìm cách xóa những bản sao truy cập được. [1]

• Tách quyền quản trị nguồn và kho backup; giới hạn quyền của tài khoản chạy job.
• Kiểm tra chính sách giữ phiên bản và cơ chế khóa sửa/xóa. Bản ở ngoài văn phòng vẫn cần quyền truy cập phù hợp.
• Lưu catalog, hướng dẫn truy xuất và khóa giải mã backup ở nơi được kiểm soát, có người thay thế tiếp cận được khi cần.
• Đặt người nhận cảnh báo cho job lỗi, thiếu dung lượng và quá lâu không có điểm khôi phục mới.

Với Synology, đối chiếu model và DSM trước khi chọn immutable snapshot. Với QNAP HBS 3, kiểm tra riêng version management và lịch kiểm tra tính toàn vẹn; chức năng có thể khác theo phiên bản và đích lưu trữ. [2] [3] Một nhãn “immutable” cần đi cùng thời hạn bảo vệ đã cấu hình và kết quả kiểm tra quyền thực tế.

5. Diễn tập SQL Server đến bước người dùng xác nhận

Trong kế hoạch backup SQL Server, hãy tách ba việc: tạo được bản sao, phục hồi được database và sử dụng được ứng dụng. Mỗi việc cần một tiêu chí kiểm tra.

RESTORE VERIFYONLY hỗ trợ kiểm tra bộ backup đầy đủ và đọc được, nhưng không thực hiện restore và không kiểm tra toàn bộ cấu trúc dữ liệu bên trong. Vì vậy, không dùng kết quả lệnh này làm bằng chứng duy nhất để nghiệm thu. [4]

1. Chuẩn bị SQL Server thử nghiệm phù hợp phiên bản, đủ dung lượng và được cô lập khỏi hệ thống đang dùng.
2. Chọn bản full, differential nếu có và các log cần thiết. Với log backup, kiểm tra recovery model và tính liên tục của chuỗi; Simple không hỗ trợ log backup. [5]
3. Restore thành database riêng, kiểm tra bằng DBCC CHECKDB phù hợp phạm vi và ghi lại kết quả. Đây là kiểm tra tính nhất quán kỹ thuật, cần bổ sung xác nhận nghiệp vụ. [6]
4. Cho người phụ trách ứng dụng mở báo cáo, đối chiếu kỳ dữ liệu và thử nghiệp vụ đại diện trên môi trường test.

Ghi cả những thứ thường nằm ngoài file backup database: login, SQL Agent job, cấu hình kết nối và chứng thư/khóa nếu hệ thống có mã hóa. Không thử ghi đè database đang phục vụ người dùng để chứng minh bản sao hoạt động.

6. Bốn chặng công việc tới ngày 30.11

Đây là lịch gợi ý cho tháng 11/2026. Có thể thu hẹp phạm vi theo nguồn lực, nhưng mỗi chặng nên có đầu ra và người nhận trách nhiệm.

Ngân sách nên tính cả nơi chạy lại ứng dụng, dung lượng tạm, băng thông lấy dữ liệu từ xa và công kiểm tra. Một kho backup nhiều dung lượng chưa trả lời được hệ thống sẽ chạy ở đâu khi máy chủ chính không còn sử dụng được.

7. Một phiếu nghiệm thu cho mỗi lần restore

Có thể đưa các trường dưới đây vào ticket nội bộ. Phiếu giúp ca trực sau hiểu được đã thử những gì và điều gì vẫn còn thiếu.

Với diễn tập ransomware, bổ sung bước đánh giá điểm phục hồi và môi trường sạch trước khi nối lại hệ thống. Bản sao có ngày cũ hơn thời điểm mã hóa vẫn cần được xem xét về nguy cơ tồn tại dấu vết xâm nhập.

8. Mang bài toán thực tế tới VIET NAM Backup Day 30.11

TUNGTEK mời anh chị em IT, quản trị NAS/Server, DBA và người phụ trách doanh nghiệp cùng trao đổi tại nhóm VIET NAM Backup Day 30.11. Mốc 30.11 là tên hoạt động cộng đồng được giới thiệu trong bài TEKLink224.

Một chia sẻ hữu ích có thể rất ngắn: hệ thống gì, cần phục hồi điều gì, đang vướng ở đâu và đã thử được đến bước nào. Có thể trao đổi cách giữ phiên bản trên Synology/QNAP, chuẩn bị nơi dựng máy ảo hoặc kiểm tra restore SQL. Khi chia sẻ, dùng sơ đồ và số liệu đã ẩn thông tin nhạy cảm, tránh đưa mật khẩu, khóa hay dữ liệu khách hàng lên nhóm.

Nếu cần chuẩn bị phương án cho doanh nghiệp, hãy mang theo bảng phạm vi và phiếu diễn tập. Đó cũng là đầu vào để TUNGTEK trao đổi nhu cầu IT, Cloud và TBackup sát với hệ thống thực tế hơn.