RAID không thay thế backup. RAID tổ chức nhiều ổ đĩa để đáp ứng mục tiêu về khả năng chịu lỗi hoặc hiệu năng tùy cấp và cấu hình. Backup giữ bản dữ liệu phục vụ khôi phục. Khi thuê máy chủ, cần xác nhận riêng cả hai vì chúng xử lý những tình huống khác nhau.
Hoá Đơn Tự Động là đối tác affiliate EZTECH và có thể nhận hoa hồng khi bạn đăng ký qua liên kết. Cấu hình RAID, lịch sao lưu và giá phải được xác nhận cho dịch vụ cụ thể.
RAID bảo vệ trước những gì
Khả năng chịu lỗi ổ đĩa phụ thuộc mức RAID, số ổ và cách triển khai. Không nên gọi chung mọi RAID là bảo vệ dữ liệu như nhau; một số cách tổ chức tập trung vào hiệu năng và không cung cấp khả năng chịu lỗi ổ như mong đợi.
Nếu người dùng xóa nhầm file hoặc ứng dụng ghi dữ liệu sai, RAID không tạo lại phiên bản đúng trước đó. Một lệnh xóa có thể tác động tới dữ liệu trên cả mảng ổ. Rủi ro ở cấp máy, quyền truy cập hay phần mềm cũng cần các lớp bảo vệ khác.
| Tình huống | Lớp cần xem |
|---|---|
| Một ổ lỗi | Thiết kế RAID và thay ổ phù hợp |
| Xóa hoặc sửa nhầm | Bản backup có lịch sử |
| Máy chủ không truy cập được | Bản sao ngoài máy và nơi phục hồi |
| Tài khoản bị chiếm quyền | Kiểm soát truy cập và bảo vệ bản sao |
| Cần quay lại thời điểm trước | Phương án backup phù hợp ứng dụng |
Hỏi dung lượng sau RAID
Tổng dung lượng nhãn ổ không phải dung lượng dùng được. Tùy thiết kế, một phần được dùng cho sao gương, thông tin dự phòng hoặc cấu trúc lưu trữ. Hệ điều hành, log và ứng dụng tiếp tục dùng một phần dung lượng còn lại.
Yêu cầu báo giá ghi số ổ, loại ổ, dung lượng sử dụng sau cấu hình và cơ chế theo dõi lỗi. Hỏi ai nhận cảnh báo, ai thay ổ và hệ thống có thể bị ảnh hưởng thế nào trong lúc khôi phục mảng.
Không chọn cấp RAID chỉ từ một bảng dung lượng. Cần xét đặc tính đọc ghi, ngân sách, thời gian xử lý khi lỗi và khả năng tương thích của nền tảng.
Backup cần độc lập và khôi phục được
Chốt dữ liệu cần bảo vệ, tần suất, thời hạn giữ và nơi lưu bản sao. Mục tiêu là có một bản còn dùng được khi dữ liệu chính gặp vấn đề. Nơi lưu cùng máy không xử lý đầy đủ tình huống mất cả máy.
Với database, phương pháp backup phải phù hợp trạng thái ứng dụng. Không coi việc sao chép thư mục của một database đang hoạt động là phương án hợp lệ cho mọi tình huống. Tham khảo tài liệu chính thức của hệ quản trị và yêu cầu người triển khai giải thích quy trình.
Snapshot giúp lưu trạng thái theo khả năng của nền tảng, nhưng không nên mặc định là bản sao độc lập. Hỏi snapshot nằm ở đâu và còn phục hồi được khi host hoặc nơi lưu trữ gốc hỏng hay không.
Đặt mục tiêu phục hồi trước lịch sao lưu
Doanh nghiệp cần trả lời có thể mất tối đa bao nhiêu dữ liệu và chấp nhận gián đoạn bao lâu. Hệ thống có giao dịch liên tục sẽ có yêu cầu khác kho file ít thay đổi. Hai câu trả lời này quyết định lịch và phương án phục hồi.
Kiểm tra restore nên thực hiện trên môi trường tách biệt, có người xác nhận đủ dữ liệu và ứng dụng chạy đúng. Không chỉ xem thông báo backup thành công. Lưu kết quả kiểm tra và thời gian cần thiết để dùng khi lập kế hoạch sự cố.
Đọc máy chủ database và quản trị máy chủ để phân công người thực hiện.
Thêm yêu cầu backup vào báo giá
Khi xem dịch vụ thuê máy chủ, ghi riêng RAID, backup, phí lưu thêm và phí restore. Nếu dùng VPS, vẫn cần kiểm tra cùng các câu hỏi.
Yêu cầu EZTECH xác nhận cấu hình lưu trữ và phương án backup.
Nguồn: máy chủ EZTECH, RAID trong Linux, backup PostgreSQL.
