34. Backup và restore database cơ bản

1. Vì sao backup database là việc không được phép “làm cho có”?

Trong vận hành hệ thống, backup database thường bị hiểu sai:

• “Có file backup là được”

• “Chưa cần restore bao giờ”

• “Lúc cần thì làm cũng kịp”

Thực tế:

• Sự cố không báo trước

• Restore luôn mất thời gian hơn tưởng tượng

• Backup không restore được = không có backup

Nguyên tắc:

Backup chỉ có giá trị khi đã từng restore thành công.

2. Mục tiêu của backup database trong production

Một hệ thống backup tốt cần đảm bảo:

1. Không ảnh hưởng hiệu năng website

2. Không cần thao tác thủ công hằng ngày

3. Có thể phục hồi nhanh khi cần

4. Không phụ thuộc vào một cá nhân

5. Có kiểm tra định kỳ

3. Các hình thức backup database phổ biến

3.1. Logical backup (khuyến nghị cơ bản)

• Dùng mysqldump

• Backup ra file .sql

• Dễ restore

• Phù hợp hệ thống vừa và nhỏ

Đây là hình thức được dùng trong bài này.

3.2. Physical backup (chỉ nhắc, chưa triển khai)

• Copy file dữ liệu trực tiếp

• Phức tạp hơn

• Phù hợp hệ thống lớn

Sẽ đề cập ở mức nâng cao sau.

4. Backup database thủ công bằng mysqldump

4.1. Backup một database

Ưu điểm:

• Dễ hiểu

• Dễ kiểm tra

• Dễ restore

4.2. Backup có charset và transaction an toàn

Đây là ví dụ chỉ backup 1 database là cntt_it_user. Thực tế sẽ cần backup TẤT CẢ database hoặc HÀNG LOẠT các database có thay đổi/cần backup. Sẽ viết trong bài khác.

Khuyến nghị cho production:

Giải thích:

• --single-transaction: không khóa bảng

• --routines, --triggers: đầy đủ cấu trúc

5. Backup nhiều database (khi cần)

Chỉ dùng khi:

• Có lý do rõ ràng

• Hiểu rõ dữ liệu bên trong

6. Nén file backup để tiết kiệm dung lượng

Sau khi backup:

File:

Khuyến nghị:

Luôn nén file backup trước khi lưu trữ lâu dài.

7. Vị trí lưu trữ backup (rất quan trọng)

Không nên:

• Lưu backup chung thư mục web

• Lưu trên cùng partition dữ liệu duy nhất

Khuyến nghị backup để trong ổ cứng khác (HDD backup):

Quyền thư mục:

Nguyên tắc:

Backup phải an toàn hơn dữ liệu đang chạy.

8. Restore database – bước phải làm thử ít nhất một lần

8.1. Restore vào database mới (khuyến nghị)

Nếu file nén:

8.2. Restore không được làm trực tiếp trên production khi chưa test

Nguyên tắc:

Restore phải test trên staging hoặc database khác trước.

9. Các lỗi thường gặp khi restore

9.1. Lỗi quyền

• User không có quyền CREATE/DROP
  → Cấp quyền tạm thời rồi thu hồi

9.2. Lỗi charset

• Database charset không khớp
  → Tạo database đúng charset trước khi restore

9.3. Restore chậm hoặc treo

• Database lớn

• Server yếu

Giải pháp:

• Restore ngoài giờ cao điểm

• Theo dõi log

10. Tự động hóa backup cơ bản bằng cron

10.1. Script backup đơn giản

Ví dụ file:

Nội dung:

Phân quyền:

10.2. Lên lịch cron

Ví dụ backup mỗi đêm:

11. Dọn dẹp backup cũ

Không dọn:

• Ổ đĩa sẽ đầy

• Gây sự cố toàn hệ thống

Ví dụ giữ 7 ngày:

12. Checklist backup & restore database

•  Có backup định kỳ

•  File backup được nén

•  Lưu trữ an toàn

•  Đã từng restore test

•  Có dọn backup cũ

•  Không lưu password lộ ra ngoài

13. Bài tiếp theo

Trong Bài 35, chúng ta sẽ mở rộng:

Chiến lược backup nâng cao và phục hồi khi thảm họa

Bài này sẽ đề cập:

• Offsite backup

• Snapshot

• Kịch bản mất toàn bộ server