Hosting Minecraft 6 phút đọc

Sao lưu dữ liệu lên S3 thất bại: 5 sai lầm phổ biến và cách sửa

Tác giả riodo83 Đội ngũ hỗ trợ PIKAMC

Sao lưu S3 của bạn có đang "chết yểu" không?

Làm vận hành mà, ai cũng hiểu cảm giác căng thẳng khi một dịch vụ quan trọng không hoạt động như mong đợi. Đặc biệt là backup. Bạn cấu hình rồi, tưởng đâu ngon lành. Đến lúc cần thì mới tá hỏa: "Ủa, sao cái backup S3 này nó cứ báo lỗi 'Access Denied' miết vậy?" Có khi là "Completed with issues" nhưng file restore lại thiếu. Đúng là muốn "đập bàn phím" luôn!

Tôi từng thấy một trường hợp, một admin cứ luẩn quẩn với thống kê kiểu này: 168 completed jobs, nhưng hết 112 failed jobs riêng cho S3. Tức là tỉ lệ thất bại quá cao, mà nguyên nhân cứ lờ mờ. Đau đầu lắm chứ không đùa.

Hôm nay, tôi sẽ chia sẻ 5 cái "bẫy" thường gặp nhất khi sao lưu lên S3, mà đa phần đều liên quan đến những thứ nhỏ nhặt nhưng lại cực kỳ chí mạng. Đọc xong hy vọng bạn sẽ tự tin hơn khi "chữa bệnh" cho hệ thống backup của mình.

1. Quyền IAM như mớ bòng bong: Lỗi "Access Denied" là chuyện thường

Nói thật, đây là thủ phạm số một, lúc nào cũng vậy. "Access Denied", nghe quen đúng không? Nhiều khi bạn nghĩ: "Ủa, tôi đã gán cái role XYZ rồi mà?" Vâng, nhưng quyền trong AWS phức tạp hơn bạn nghĩ một chút. Đặc biệt là cái gọi là explicit deny.

Cái "explicit deny" là gì mà đáng sợ vậy?

Hãy hình dung thế này: bạn có một chìa khóa (IAM Role) để vào nhà (S3 bucket). Chìa khóa đó nói: "Tao được phép vào". Nhưng ngay trên cửa nhà, có một tấm biển (Bucket Policy) to đùng ghi: "CẤM TẤT CẢ NHỮNG AI ĐẾN TỪ VÙNG XYZ ĐƯỢC VÀO!". Và không may, bạn lại đến từ vùng XYZ. Thế là bạn tạch.

Cái explicit deny trong Bucket Policy, dù chỉ là một dòng nhỏ, nó có thể ghi đè (override) tất cả các quyền "cho phép" (allow) mà bạn đã cấp trong IAM Role. Kết quả là:

backup job failed to create a recovery point for resource arn:aws:s3:::test due to missing permissions on role arn:aws:iam::111111111111:role/service-role/AWSBackupDefaultServiceRole.

Bạn thấy không? Rõ ràng là có role, nhưng vẫn "missing permissions". Đắng lòng!

Sửa chữa cho mục này

Cách xử lý là bạn phải kiểm tra cả hai nơi:

  1. IAM Role của dịch vụ backup: Đảm bảo nó có đủ quyền S3. Nếu dùng AWS Backup mặc định, cái role AWSBackupDefaultServiceRole nhiều khi chỉ có quyền cho EC2/EBS mà thiếu S3. Bạn cần attach thêm policy AWSBackupServiceRolePolicyForS3Backup. Đây là lệnh CLI thần thánh cứu vãn tình hình:

    aws iam attach-role-policy --role-name AWSBackupDefaultServiceRole --policy-arn arn:aws:iam::aws:policy/AWSBackupServiceRolePolicyForS3Backup

    Các quyền S3 tối thiểu cần có cho backup thường bao gồm:

    • s3:GetObject
    • s3:ListBucket
    • s3:GetBucketVersioning
    • s3:PutBucketNotification
  2. Bucket Policy của S3 bucket: Xem có dòng Deny nào không. Nếu có, hãy thêm điều kiện để loại trừ role backup của bạn ra. Ví dụ, dùng ArnNotLike để nói rằng: "Deny tất cả, TRỪ thằng này ra". Điều này đảm bảo role backup của bạn không bị ảnh hưởng bởi những chính sách Deny chung chung.

2. S3 Versioning? Có khi quên bật, có khi chưa hiểu

Nghe có vẻ nhỏ nhặt, nhưng S3 Versioning là một yếu tố bắt buộc nếu bạn muốn backup lên S3. Dịch vụ backup như AWS Backup cần nó để tạo ra các điểm khôi phục (recovery points) một cách hiệu quả. Nếu bạn quên bật, hệ thống sẽ trả về lỗi ngay:

"Versioning is not enabled on test-bucket"

Thế đấy, đơn giản mà lại làm mọi thứ "đổ sông đổ biển". Mà cái này còn có một cái bẫy nữa:

À, một cái nhiều bạn hay quên là khi bật Versioning rồi, nếu không cấu hình các quy tắc vòng đời (lifecycle rules) phù hợp, các phiên bản cũ của file sẽ cứ tích tụ mãi. Đến một ngày đẹp trời, dung lượng S3 của bạn sẽ phình to, và bạn sẽ phải trả tiền kha khá cho đống dữ liệu mà có khi bạn không cần truy cập thường xuyên nữa.

Lời khuyên:

Luôn bật Versioning cho các S3 bucket dùng làm đích đến của backup. Đồng thời, cấu hình lifecycle rules để tự động xóa hoặc chuyển các phiên bản cũ vào tầng lưu trữ rẻ hơn (như Glacier) sau một khoảng thời gian nhất định.

3. Sự cố thông báo sự kiện S3: Backup không biết đường mà lần

Một số dịch vụ backup, chẳng hạn như AWS Backup, dùng cơ chế thông báo sự kiện (event notifications) của S3 để "biết" khi nào có thay đổi trong bucket và kích hoạt quá trình backup. Điều này đòi hỏi quyền s3:PutBucketNotification.

Nếu bạn cấu hình điểm đến của thông báo sự kiện bị sai, hoặc Bucket Policy của bạn lại vô tình Deny luôn quyền s3:PutBucketNotification này, thì backup của bạn sẽ "tịt". Dịch vụ backup không nhận được "tín hiệu" thay đổi, thế là thôi, coi như không có gì xảy ra cả.

Kiểm tra gì đây?

  • Cấu hình Event Notifications: Đảm bảo điểm đến (ví dụ: SNS topic, SQS queue, Lambda function) là chính xác và có thể nhận được thông báo.
  • Bucket Policy và SCPs: Xem lại kỹ các chính sách này, đảm bảo không có dòng nào "cứng rắn" Deny quyền s3:PutBucketNotification cho role backup của bạn.

4. Đã backup mà sao restore lại thiếu file? Bực mình thật!

Cảm giác còn tệ hơn cả backup thất bại ngay từ đầu: backup báo "Completed with issues", đến lúc restore lại thiếu file. Kiểu như bạn đã có áo mưa rồi, đến lúc mưa lại thủng lỗ chỗ vậy. Bực mình lắm!

Nguyên nhân có thể là:

  • Quyền trên từng object: Đôi khi, quyền backup có thể ok ở cấp độ bucket, nhưng có những object (file) cụ thể lại có quyền riêng, chặn dịch vụ backup đọc chúng.
  • Lỗi tạm thời của dịch vụ: "AWS Backup Transient Errors" – nghe sang chảnh nhưng thật ra là lỗi vặt, lỗi mạng hoặc lỗi dịch vụ tức thời ảnh hưởng đến một vài object trong quá trình sao lưu.

Làm gì để "khỏi đứt ruột"?

Với lỗi quyền object, không có cách nào khác là rà soát lại các quyền truy cập trên các file cụ thể trong S3. Với lỗi tạm thời, cách duy nhất là thử lại quá trình backup hoặc restore. Đôi khi sự kiên nhẫn cũng là một kỹ năng của người làm vận hành.

Tóm lại, muốn backup S3 "ngon lành" thì phải nhớ...

Để tránh rơi vào tình cảnh như người admin tội nghiệp với 112 failed jobs, hay đơn giản là không phải "đau tim" mỗi khi cần restore, bạn nên ghi nhớ mấy điều sau:

  • Kiểm tra Quyền IAM thật kỹ: Luôn nghĩ đến cả IAM Role VÀ Bucket Policy. Nhớ vụ explicit deny nhé.
  • Bật S3 Versioning: Đây là điều kiện tiên quyết, không có thì không chạy đâu.
  • Thông báo sự kiện: Đảm bảo đường đi nước bước của các notification luôn thông suốt.
  • Đừng quên Restore: Backup mà không restore được thì vô nghĩa. Thỉnh thoảng tập dượt restore, kiểm tra file xem có thiếu sót gì không.

Sao lưu là một công việc quan trọng, nhưng cũng đầy rẫy những cái "bẫy" ngầm. Hiểu rõ cơ chế, kiểm tra kỹ từng bước, và đừng quên thực hành restore. Chúc bạn luôn có những bản backup "chắc cú"!