Sau hướng dẫn này
Bạn phân biệt rollback app với restore dữ liệu và biết cách kiểm chứng một bản sao lưu dùng được.
Cần giữ những gì?
MySQL giữ dữ liệu chính, nhưng tính bền vững không thay thế bản sao lưu. Redis nên chứa dữ liệu có thể tạo lại, trừ khi bạn đã xác nhận cơ chế lưu/khôi phục phù hợp. File người dùng tải lên cũng cần nơi lưu bền vững và kế hoạch backup riêng; không mặc định file trong runtime còn sau redeploy.
Lưu mã nguồn, phiên bản migration và cấu hình cần tái tạo app. Cất secrets và bản sao dữ liệu ở nơi có kiểm soát truy cập, tách khỏi tài nguyên gốc.
Lập kế hoạch sao lưu
- Xác định có thể mất tối đa bao nhiêu dữ liệu (ví dụ các thay đổi từ lần sao lưu gần nhất) và app có thể dừng bao lâu.
- Kiểm tra plan hoặc hỏi hỗ trợ về backup, lịch chạy, thời gian lưu và thủ tục restore. Chưa xác nhận thì chưa coi là đã có backup.
- Nếu cần tự xuất MySQL, dùng công cụ phù hợp phiên bản và quyền tài khoản; xác nhận tính nhất quán của bản xuất khi app đang ghi dữ liệu. Không đưa mật khẩu vào lịch sử lệnh.
- Lưu bản sao được bảo vệ ở vị trí độc lập, theo dõi kết quả mỗi lần sao lưu. Sao lưu trước migration có nguy cơ mất dữ liệu.
Diễn tập khôi phục
Rollback Flash Deploy chỉ đổi phiên bản app. Nếu migration đã xóa cột hoặc thay đổi dữ liệu, bản app cũ có thể không còn tương thích. Kiểm tra schema trước khi rollback và dùng kế hoạch phục hồi dữ liệu riêng.
- Chọn bản sao có thời điểm rõ ràng và tạo đích thử nghiệm riêng, không ghi đè database production.
- Khôi phục bằng quy trình được hỗ trợ; đối chiếu bảng, số bản ghi và một vài dữ liệu nghiệp vụ.
- Trỏ bản app thử nghiệm vào dữ liệu phục hồi; thử đăng nhập, đọc và ghi dữ liệu. Ghi lại thời gian khôi phục thực tế.
- Khi sự cố thật xảy ra, thống nhất thời điểm phục hồi và cách xử lý dữ liệu mới phát sinh trước khi đổi endpoint hoặc ghi đè dữ liệu.