3-2-1, không phải slogan marketing
- 3 bản copy dữ liệu (production + 2 backup).
- 2 loại media khác nhau (disk + object storage chẳng hạn).
- 1 bản offsite (khác rack / khác region).
Nếu bạn chỉ có snapshot trên cùng một cloud account, bạn chưa hoàn thành offsite theo nghĩa rủi ro account compromise.
Snapshot không phải backup nếu bạn không restore được
Snapshot (LVM, ZFS, EBS) rất hữu ích cho điểm phục hồi nhanh trước khi patch. Nhưng:
- Corruption logic trong DB có thể đã ghi đè dữ liệu xấu lên snapshot mới.
- Vendor bug có thể làm mất cả chain snapshot nếu metadata hỏng (hiếm nhưng không phải 0).
Backup theo nghĩa vận hành = bản có thể restore trong thời gian RTO với độ mất dữ liệu RPO chấp nhận được và đã test.
Restore drill: chỉ tính khi đã chạy thử
Quy trình gợi ý (tuỳ chỉnh theo org):
- Chọn một workload không critical hoặc staging clone.
- Xoá / corrupt có chủ đích.
- Restore từ backup đêm hôm trước.
- Đo thời gian và checklist app health.
- Ghi lại gap (secret chưa restore? file permission?).
Nếu chưa từng restore, bạn không biết RTO thực, chỉ biết marketing brochure.
Công cụ backup trên Linux (không chỉ định một thánh war)
restic,borgbackup: mã hoá, dedupe, đẩy lên S3-compatible.rsnapshot/rsync+ hardlinks: đơn giản, cần kỷ luật retention script.- DB:
pg_dump/mysqldump/ physical base backup, khác nhau về consistency; đọc doc engine.
Ops rule: metadata backup (cấu hình /etc, systemctl cat, iptables-save) tách khỏi data volume, giúp rebuild snowflake nhanh hơn.
Playbook incident trên host (một trang)
1) Xác nhận phạm vi: một node hay nhiều node? thay đổi gần đây (deploy/patch)?
2) Reachability: ping/SSH? serial console? cloud “serial log”?
3) Resource: df -h / df -i; free -h; dmesg OOM; load vs D-state.
4) Service: systemctl --failed; journalctl -u <unit> -b;
5) Network local: ss -lntp; nft/iptables-save | head;
6) App: app log path; trace id nếu có;
7) Mitigation vs root-cause: scale out / rollback / disable feature flag;
8) Postmortem trong 48h nếu SEV đủ lớn.
Playbook ngắn in được dán trong wiki tốt hơn một tài liệu 200 trang không ai đọc lúc 3 giờ sáng.
Checklist, máy chủ mới (trước khi gắn production traffic)
- OS patch baseline + automatic security cadence đã quyết định
- Hostname/FQDN + DNS forward/reverse đúng policy
- Time sync OK (
chronyc tracking) - SSH key-only +
PermitRootLoginpolicy - Firewall default deny + rule tối thiểu (IPv4 và IPv6)
-
fail2ban/rate limit nếu policy yêu cầu - Disk layout + journal/logrotate limit
- Monitoring agent + log ship (nếu có)
- Backup job đăng ký + restore test đã lên lịch
- Runbook on-call + escalation
Checklist, sau incident (trước khi “đóng ticket”)
- Nguyên nhân gốc đã xác định hoặc có action mở để theo dõi
- Thay đổi cấu hình đã vào Git/IaC, không chỉ hotfix trên máy
- Monitoring/alert đã bắt được dấu hiệu sớm hơn lần sau
- Secret đã rotate nếu có rủi ro lộ
- Postmortem action items có owner + deadline
Linux, quyền kiểm soát và trách nhiệm trong team
Linux cho ta quyền kiểm soát sâu, đó là lý do nhiều dev/DevOps gắn bó. Khi phần mềm đi qua nhiều môi trường, kiểm soát đi kèm tái lập được (reproducibility) và kể chuyện bằng log + playbook để người khác không phải đoán mò lúc 3 giờ sáng.
Mười hai bài này nối tầng dùng máy hằng ngày (FHS, shell, quyền, systemd, log) với những chỗ chạm tới vận hành (patch, firewall, SSH, backup, incident), đủ rộng cho vòng đời phần mềm, không ép bạn thành sysadmin chuyên nghiệp.
Đọc lại toàn loạt
→ Mục lục loạt Linux thực dụng (Dev & DevOps)
Câu hỏi hay gặp
1. “RPO/RTO là gì?”
RPO: mất tối đa bao nhiêu dữ liệu (khoảng cách giữa các backup). RTO: downtime tối đa chấp nhận để phục hồi.
2. “Immutable infrastructure có cần backup OS không?”
Ít, nhưng data và secret vẫn cần; đôi khi cần backup state của control plane.
3. “Tôi nên lưu backup ở cùng region để nhanh?”
Có, cho restore nhanh; nhưng hãy có bản xa hơn cho disaster account-level.