Các chiến lược sao lưu cho nhóm AWS S3


93

Tôi đang tìm kiếm một số lời khuyên hoặc phương pháp hay nhất để sao lưu bộ chứa S3.
Mục đích của việc sao lưu dữ liệu từ S3 là để tránh mất dữ liệu vì những điều sau:

  1. Vấn đề S3
  2. vấn đề mà tôi vô tình xóa dữ liệu này khỏi S3

Sau một số điều tra, tôi thấy các tùy chọn sau:

  1. Sử dụng phiên bản http://docs.aws.amazon.com/AmazonS3/latest/dev/Versinstall.html
  2. Sao chép từ một nhóm S3 sang một nhóm khác bằng AWS SDK
  3. Sao lưu vào Amazon Glacier http://aws.amazon.com/en/glacier/
  4. Sao lưu vào máy chủ sản xuất, chính nó đã được sao lưu

Tôi nên chọn tùy chọn nào và mức độ an toàn khi chỉ lưu trữ dữ liệu trên S3? Muốn nghe ý kiến ​​của bạn.
Một số liên kết hữu ích:


Câu trả lời:


63

Ban đầu được đăng trên blog của tôi: http://eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/

Đồng bộ hóa Nhóm S3 của bạn với Máy chủ EC2 Định kỳ

Điều này có thể dễ dàng đạt được bằng cách sử dụng nhiều tiện ích dòng lệnh để có thể đồng bộ nhóm S3 từ xa với hệ thống tệp cục bộ.

s3cmd
Lúc đầu, s3cmdtrông rất hứa hẹn. Tuy nhiên, sau khi thử nó trên thùng S3 khổng lồ của tôi - nó không thể mở rộng quy mô, lỗi với a Segmentation fault. Tuy nhiên, nó hoạt động tốt trên các thùng nhỏ. Vì nó không hoạt động với những thùng lớn, tôi bắt đầu tìm một giải pháp thay thế.

s4cmd
Giải pháp thay thế mới hơn, đa luồng cho s3cmd. Tuy nhiên, trông có vẻ hứa hẹn hơn, tôi nhận thấy rằng nó liên tục tải xuống lại các tệp đã có trên hệ thống tệp cục bộ. Đó không phải là loại hành vi mà tôi mong đợi từ lệnh đồng bộ. Nó sẽ kiểm tra xem tệp từ xa đã tồn tại cục bộ hay chưa (kiểm tra kích thước băm / tệp sẽ gọn gàng) và bỏ qua nó trong lần chạy đồng bộ tiếp theo trên cùng một thư mục đích. Tôi đã mở một vấn đề ( bloomreach / s4cmd / # 46 ) để báo cáo hành vi kỳ lạ này. Trong khi chờ đợi, tôi bắt đầu tìm một giải pháp thay thế khác.

awscli
Và sau đó tôi tìm thấy awscli. Đây là giao diện dòng lệnh chính thức của Amazon để tương tác với các dịch vụ đám mây khác nhau của họ, bao gồm S3.

AWSCLI

Nó cung cấp một lệnh đồng bộ hữu ích giúp tải các tệp nhóm từ xa xuống hệ thống tệp cục bộ của bạn một cách nhanh chóng và dễ dàng .

$ aws s3 sync s3: // your-bucket-name / home / ubuntu / s3 / your-bucket-name /

Những lợi ích:

  • Có thể mở rộng - hỗ trợ nhóm S3 khổng lồ
  • Đa luồng - đồng bộ hóa các tệp nhanh hơn bằng cách sử dụng nhiều luồng
  • Thông minh - chỉ đồng bộ hóa các tệp mới hoặc cập nhật
  • Nhanh chóng - nhờ tính chất đa luồng và thuật toán đồng bộ thông minh

Xóa do tình cờ

Thuận tiện, synclệnh sẽ không xóa các tệp trong thư mục đích (hệ thống tệp cục bộ) nếu chúng bị thiếu trong nguồn (nhóm S3) và ngược lại. Điều này là hoàn hảo để sao lưu S3 - trong trường hợp các tệp bị xóa khỏi thùng, việc đồng bộ hóa lại sẽ không xóa chúng cục bộ. Và trong trường hợp bạn xóa một tệp cục bộ, nó cũng sẽ không bị xóa khỏi nhóm nguồn.

Thiết lập awscli trên Ubuntu 14.04 LTS

Hãy bắt đầu bằng cách cài đặt awscli. Có một số cách để thực hiện việc này, tuy nhiên, tôi thấy dễ nhất là cài đặt nó qua apt-get.

$ sudo apt-get cài đặt awscli

Cấu hình

Tiếp theo, chúng ta cần định cấu hình awsclivới ID Khóa truy cập & Khóa bí mật mà bạn phải lấy từ IAM , bằng cách tạo người dùng và đính kèm chính sách AmazonS3ReadOnlyAccess . Điều này cũng sẽ ngăn bạn hoặc bất kỳ ai có quyền truy cập vào các thông tin xác thực này xóa các tệp S3 của bạn. Đảm bảo nhập vùng S3 của bạn, chẳng hạn như us-east-1.

cấu hình $ aws

aws cấu hình

Sự chuẩn bị

Hãy chuẩn bị thư mục sao lưu S3 cục bộ, tốt nhất là trong /home/ubuntu/s3/{BUCKET_NAME}. Đảm bảo thay thế {BUCKET_NAME}bằng tên nhóm thực của bạn.

$ mkdir -p / home / ubuntu / s3 / {BUCKET_NAME}

Đồng bộ ban đầu

Hãy tiếp tục và đồng bộ hóa nhóm lần đầu tiên với lệnh sau:

$ aws s3 sync s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

Giả sử nhóm tồn tại, thông tin đăng nhập AWS và khu vực là chính xác và thư mục đích hợp lệ, awsclisẽ bắt đầu tải toàn bộ nhóm xuống hệ thống tệp cục bộ.

Tùy thuộc vào kích thước của nhóm và kết nối Internet của bạn, có thể mất từ ​​vài giây đến hàng giờ. Khi việc đó hoàn tất, chúng tôi sẽ tiếp tục và thiết lập cron job tự động để cập nhật bản sao cục bộ của nhóm.

Thiết lập công việc Cron

Hãy tiếp tục và tạo một sync.shtệp trong /home/ubuntu/s3:

$ nano /home/ubuntu/s3/sync.sh

Sao chép và dán mã sau vào sync.sh:

#! / bin / sh

# Gọi ngày và giờ hiện tại

echo '-----------------------------'
ngày
echo '-----------------------------'
echo ''

# Khởi tạo tập lệnh Echo
echo 'Đang đồng bộ hóa bộ chứa S3 từ xa ...'

# Trên thực tế, hãy chạy lệnh đồng bộ hóa (thay thế {BUCKET_NAME} bằng tên nhóm S3 của bạn)
/ usr / bin / aws s3 sync s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

# Hoàn thành tập lệnh Echo
echo 'Hoàn tất đồng bộ hóa'

Đảm bảo thay thế {BUCKET_NAME} bằng tên nhóm S3 của bạn, hai lần trong suốt tập lệnh.

Mẹo chuyên nghiệp: Bạn nên sử dụng /usr/bin/awsđể liên kết với awstệp nhị phân, vì crontabthực thi các lệnh trong môi trường trình bao hạn chế và sẽ không thể tự tìm thấy tệp thực thi.

Tiếp theo, hãy đảm bảo chmodtập lệnh để nó có thể được thực thi bởi crontab.

$ sudo chmod + x /home/ubuntu/s3/sync.sh

Hãy thử chạy tập lệnh để đảm bảo rằng nó thực sự hoạt động:

$ /home/ubuntu/s3/sync.sh

Đầu ra phải tương tự như sau:

đầu ra sync.sh

Tiếp theo, hãy chỉnh sửa người dùng hiện tại crontabbằng cách thực hiện lệnh sau:

$ crontab -e

Nếu đây là lần đầu tiên bạn thực thi crontab -e, bạn sẽ cần chọn một trình soạn thảo ưa thích. Tôi khuyên bạn nên chọn nanovì nó là dễ dàng nhất cho người mới bắt đầu làm việc.

Tần số đồng bộ hóa

Chúng ta cần cho biết crontabtần suất chạy tập lệnh của mình và nơi tập lệnh nằm trên hệ thống tệp cục bộ bằng cách viết lệnh. Định dạng cho lệnh này như sau:

lệnh mh dom mon dow

Lệnh sau định cấu hình crontabđể chạy sync.shtập lệnh mỗi giờ (được chỉ định thông qua tham số phút: 0 và giờ: *) và để nó chuyển đầu ra của tập lệnh vào một sync.logtệp trong s3thư mục của chúng tôi :

0 * * * * /home/ubuntu/s3/sync.sh> /home/ubuntu/s3/sync.log

Bạn nên thêm dòng này vào cuối crontabtệp bạn đang chỉnh sửa. Sau đó, hãy tiếp tục và lưu tệp vào đĩa bằng cách nhấn Ctrl + W rồi nhấn Enter . Sau đó bạn có thể thoát ra nanobằng cách nhấn tổ hợp phím Ctrl + X . crontabbây giờ sẽ chạy tác vụ đồng bộ mỗi giờ.

Mẹo chuyên nghiệp: Bạn có thể xác minh rằng công việc cron hàng giờ đang được thực hiện thành công bằng cách kiểm tra /home/ubuntu/s3/sync.log, kiểm tra nội dung của nó để biết ngày và giờ thực hiện và kiểm tra nhật ký để xem tệp mới nào đã được đồng bộ hóa.

Tất cả các thiết lập! Nhóm S3 của bạn giờ đây sẽ tự động được đồng bộ hóa với máy chủ EC2 của bạn mỗi giờ và bạn nên thực hiện. Xin lưu ý rằng theo thời gian, khi bộ chứa S3 của bạn lớn hơn, bạn có thể phải tăng kích thước âm lượng EBS của máy chủ EC2 để chứa các tệp mới. Bạn luôn có thể tăng kích thước khối lượng EBS của mình bằng cách làm theo hướng dẫn này .


Tôi đã để lại một câu hỏi trên blog của bạn, nhưng tôi tự hỏi liệu có cách nào để đồng bộ hóa siêu dữ liệu không?
Devology Ltd

@Devology Ltd, Rất tiếc, tôi chưa có cơ hội làm việc với siêu dữ liệu đối tượng S3. Từ một tìm kiếm nhanh trên Google, có vẻ như không awsclihỗ trợ tự động đồng bộ hóa điều này trong aws s3 synclệnh. Có vẻ như bạn có thể phải thực hiện điều này theo cách thủ công.
Elad Nava

Cảm ơn @Ekad Nava - Tôi đánh giá cao việc bạn xác nhận những gì tôi tin là đúng như vậy.
Devology Ltd

1
Đây là điều tuyệt vời @EladNava cảm ơn bạn đã chia sẻ, vẫn còn phù hợp vào năm 2020!
dùng1130176

câu trả lời này không phù hợp, khi bạn có hàng triệu tệp trong đó. Nó trở nên rất tốn kém, chậm và đôi khi không thể thực hiện được - do giới hạn về hệ thống tập tin.
Psychozoic

30

Có tính đến liên kết liên quan, giải thích rằng S3 có độ bền 99,999999999%, tôi sẽ loại bỏ mối quan tâm số 1 của bạn. Nghiêm túc.

Bây giờ, nếu # 2 là trường hợp sử dụng hợp lệ và là mối quan tâm thực sự của bạn, tôi chắc chắn sẽ gắn bó với các tùy chọn # 1 hoặc # 3. Mà một trong số họ? Nó thực sự phụ thuộc vào một số câu hỏi:

  • Bạn có cần bất kỳ tính năng tạo phiên bản nào khác không hay chỉ để tránh ghi đè / xóa ngẫu nhiên?
  • Chi phí bổ sung được áp đặt bằng cách tạo phiên bản có phải chăng?
  • Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. Điều này có ổn cho bạn không?

Trừ khi việc sử dụng bộ nhớ của bạn thực sự lớn, tôi sẽ gắn bó với việc tạo phiên bản nhóm. Bằng cách này, bạn sẽ không cần thêm bất kỳ mã / quy trình công việc nào để sao lưu dữ liệu vào Glacier, vào các nhóm khác hoặc thậm chí vào bất kỳ máy chủ nào khác (đó thực sự là một lựa chọn tồi IMHO, hãy quên nó đi).


4
@SergeyAlekseev Nếu Glacier là thứ phù hợp với bạn, thì rất nhanh chóng để thiết lập quy tắc vòng đời trên một thùng tự động lưu trữ tệp của bạn vào sông băng. Chúng sẽ vẫn xuất hiện trong một thùng (trong giao diện người dùng web) nhưng lớp lưu trữ sẽ thay đổi từ tiêu chuẩn sang sông băng. Tôi di chuyển các tệp đã xử lý từ nhóm chính của mình sang nhóm "hoàn thành" và nhóm đã hoàn thành có quy tắc vòng đời trên đó để lưu trữ bất kỳ thứ gì lớn hơn 1 ngày tuổi. Đây là những tệp dữ liệu mà có lẽ tôi sẽ không bao giờ đụng đến nữa, nhưng cần giữ lại cho khách hàng.
Dan

28
Tôi không nghĩ 99,999999999% là lý do chính đáng để có đầy đủ ngăn xếp aws trên bộ nhớ / sao lưu. Tôi không nói về 0,0000000001% còn lại, nhưng nhiều hơn nữa nếu có điều gì đó rất bất ngờ xảy ra, thật khó xử khi toàn bộ doanh nghiệp của bạn nằm ở đâu đó. Bất ngờ thay, đó có thể là Hoa Kỳ sắp tham chiến với một quốc gia cụ thể, Amazon bị tấn công hoàn toàn (xem Sony), v.v.
Augustin Riedinger

11
Tôi sẽ quay lại @AugustinRiedinger về vấn đề này: "Vấn đề S3" theo định nghĩa có thể là một cái gì đó mà bạn không biết (ví dụ: các vấn đề của chính phủ) có thể làm mất hiệu lực các giả thuyết mà các số S3 SLA như 99,99 ... được dựa trên. Khi thực hiện bất kỳ điều gì dài hạn bao gồm sao lưu dữ liệu của bạn, đa dạng hóa là một phương pháp hay, nếu không phải là điều kiện tiên quyết
lajarre

2
Tôi chắc chắn đồng ý rằng điểm của bạn là hợp lệ. Nhưng dựa trên các tùy chọn do OP đưa ra (khá nhiều trong số chúng bao gồm các lựa chọn thay thế AWS cho vấn đề), tôi không nghĩ rằng "vấn đề S3" sẽ rộng như các bạn đang mở rộng. Tuy nhiên, tốt khi thấy một số suy nghĩ rộng hơn.
Viccari

4
Câu trả lời cũ, nhưng tôi cảm thấy như thể tôi cần đề cập đến các sự kiện (-ish) gần đây. "Ngày hôm Amazon đã phá vỡ web", một công nghệ vô tình xóa một khổng lồ phần của máy chủ S3 của họ. Ngay cả trong 24 giờ đó, vấn đề là khả năng tiếp cận. Không mất dữ liệu. Có hoàn toàn không mất dữ liệu, thậm chí đưa ra số lượng lớn các máy chủ đang được gỡ bỏ, và họ vẫn quản lý để đi tốt trong SLA của họ
Oberst

14

Bạn có thể sao lưu dữ liệu S3 của mình bằng các phương pháp sau

  1. Lên lịch quá trình sao lưu bằng cách sử dụng đường dẫn dữ liệu AWS, nó có thể được thực hiện theo 2 cách được đề cập bên dưới:

    a. Sử dụng copyActivity của datapipeline mà bạn có thể sao chép từ một nhóm s3 sang một nhóm s3 khác.

    b. Sử dụng ShellActivity của datapipeline và lệnh "S3distcp" để thực hiện sao chép đệ quy của các thư mục s3 đệ quy từ thùng sang thùng khác (song song).

  2. Sử dụng lập phiên bản bên trong nhóm S3 để duy trì phiên bản dữ liệu khác nhau

  3. Sử dụng glacier để sao lưu dữ liệu của bạn (sử dụng nó khi bạn không cần khôi phục nhanh bản sao lưu về nhóm ban đầu (mất một thời gian để lấy lại dữ liệu từ glacier vì dữ liệu được lưu trữ ở định dạng nén) hoặc khi bạn muốn lưu một số chi phí bằng cách tránh sử dụng một bản sao lưu thùng s3 khác), tùy chọn này có thể dễ dàng được đặt bằng cách sử dụng quy tắc vòng đời trên thùng s3 mà bạn muốn sao lưu.

Tùy chọn 1 có thể cung cấp cho bạn khả năng bảo mật cao hơn, giả sử trong trường hợp bạn vô tình xóa nhóm s3 ban đầu của mình và một lợi ích khác là bạn có thể lưu trữ bản sao lưu của mình trong các thư mục datewise trong nhóm s3 khác, bằng cách này bạn biết bạn có dữ liệu gì vào một ngày cụ thể và có thể khôi phục bản sao lưu ngày cụ thể. Tất cả phụ thuộc vào trường hợp sử dụng của bạn.


@David: Như david đã đề xuất trong giải pháp của mình bên dưới, rằng có thể có một tập lệnh sao lưu thùng s3 hàng ngày hoặc hàng tuần, Điều này có thể dễ dàng đạt được ở điểm đầu tiên của tôi (AWS datapipeline- cung cấp cho bạn khả năng lên lịch quá trình sao lưu-hàng ngày , hàng tuần, v.v.). Tôi khuyên bạn nên tra cứu trên đường dữ liệu aws.
Varun

Điều này cho thấy một số hứa hẹn, bởi vì nó không dựa trên các phương pháp tiếp cận đã lỗi thời không xuất sắc trong việc tận dụng tối đa đám mây (đọc: crons). Data Pipeline cũng có các thử nghiệm tự động và là một dịch vụ được quản lý (không có máy chủ).
Felipe Alvarez

13

Làm thế nào về việc sử dụng tính năng Nhân rộng Vùng có sẵn trên chính các nhóm S3? Dưới đây là một số bài viết hữu ích về tính năng


Điều gì sẽ xảy ra nếu bạn xóa một tệp trong một khu vực không được sao chép trong một khu vực khác?
michelem

S3 không tái tạo các thao tác xóa, hãy xem liên kết này docs.aws.amazon.com/AmazonS3/latest/dev/… .
ᐅ devrimbaris

9

Bạn sẽ nghĩ rằng sẽ có một cách dễ dàng hơn bây giờ để chỉ giữ một số loại sao lưu gia tăng trên một khu vực khác nhau.

Tất cả những gợi ý trên không thực sự là những giải pháp đơn giản hay thanh lịch. Tôi không thực sự coi sông băng là một lựa chọn vì tôi nghĩ rằng nó giống một giải pháp lưu trữ hơn là một giải pháp sao lưu. Khi tôi nghĩ đến việc sao lưu, tôi nghĩ rằng khôi phục thảm họa từ một nhà phát triển cơ sở sẽ xóa một cách đệ quy một nhóm hoặc có thể là một khai thác hoặc lỗi trong ứng dụng của bạn xóa nội dung khỏi s3.

Đối với tôi, giải pháp tốt nhất sẽ là một tập lệnh sao lưu một nhóm sang một khu vực khác, hàng ngày và hàng tuần để nếu có điều gì đó khủng khiếp xảy ra, bạn có thể chuyển đổi khu vực. Tôi không có một thiết lập như thế này, tôi đã xem xét chỉ là chưa thực hiện được vì sẽ mất một chút công sức để thực hiện việc này, đó là lý do tại sao tôi ước có một số giải pháp cổ phần để sử dụng.


Đã đồng ý. Thật thú vị khi bạn đào sâu vào S3 (thậm chí cả CRR - được xây dựng trong bản sao) có những lỗ hổng lớn để khắc phục thảm họa. Ví dụ: bạn không thể khôi phục một nhóm, lịch sử phiên bản tệp, siêu dữ liệu (đặc biệt là ngày sửa đổi lần cuối), v.v. Tất cả các trường hợp khôi phục hiện có đều là khôi phục một phần.
Paul Jowett

7

Trong khi câu hỏi này đã được đăng cách đây một thời gian, tôi nghĩ rằng điều quan trọng là phải đề cập đến bảo vệ xóa MFA với các giải pháp khác. OP đang cố gắng giải quyết việc vô tình xóa dữ liệu. Xác thực đa yếu tố (MFA) biểu hiện trong hai trường hợp khác nhau ở đây -

  1. Xóa vĩnh viễn phiên bản đối tượng - Bật xóa MFA trên lập phiên bản của nhóm.

  2. Vô tình xóa chính nhóm - Thiết lập chính sách nhóm từ chối xóa mà không cần xác thực MFA.

Kết hợp với nhân rộng và lập phiên bản xuyên khu vực để giảm nguy cơ mất dữ liệu và cải thiện các tình huống khôi phục.

Đây là một bài blog về chủ đề này với nhiều chi tiết hơn.


0

Nếu, Chúng tôi có quá nhiều dữ liệu. Nếu bạn đã có một thùng thì lần đầu tiên Đồng bộ hóa sẽ mất quá nhiều thời gian, Trong trường hợp của tôi, tôi đã có 400GB. Lần đầu tiên phải mất 3 giờ. Vì vậy, tôi nghĩ rằng chúng ta có thể tạo bản sao là một giải pháp tốt để sao lưu S3 Bucket.


Tôi sắp chuyển khoảng 7TB vào một thùng và đang cố gắng tìm ra lựa chọn tốt nhất ... Tôi nghĩ mình cần thứ gì đó tốt hơn là đồng bộ hóa. Tôi đang tự hỏi liệu việc sử dụng đường dẫn để sao chép dữ liệu sang phiên bản GCS của sông băng có thể mang lại sự an toàn tổng thể tốt nhất không?
Brendon Whateley

AWS DataSync có thể là một tùy chọn ở đây.
Felipe Alvarez
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.