AWS S3 버킷에 대한 백업 전략

AWS S3 버킷에 대한 백업 전략

---

S3 버킷을 백업하기위한 조언이나 모범 사례를 찾고 있습니다.
S3에서 데이터를 백업하는 목적은 다음과 같은 이유로 데이터 손실을 방지하는 것입니다.

1. S3 문제
2. 실수로 S3에서이 데이터를 삭제하는 문제

몇 가지 조사 후 다음 옵션이 표시됩니다.

1. 버전 관리 http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html 사용
2. AWS SDK를 사용하여 한 S3 버킷에서 다른 버킷으로 복사
3. Amazon Glacier에 백업 http://aws.amazon.com/en/glacier/
4. 자체 백업되는 프로덕션 서버로 백업

어떤 옵션을 선택해야하며 S3에만 데이터를 저장하는 것이 얼마나 안전합니까? 여러분의 의견을 듣고 싶습니다.
유용한 링크 :

• 데이터 보호 문서
• 데이터 보호 FAQ

---

내 블로그에 원래 게시 됨 : http://eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/

주기적으로 S3 버킷을 EC2 서버에 동기화

이는 원격 S3 버킷을 로컬 파일 시스템에 동기화 할 수있는 여러 명령 줄 유틸리티를 사용하여 쉽게 달성 할 수 있습니다.

s3cmd
처음에는 s3cmd매우 유망 해 보였습니다. 그러나 거대한 S3 버킷에서 시도한 후 확장에 실패하여 Segmentation fault. 그래도 작은 양동이에서는 잘 작동했습니다. 거대한 양동이에는 효과가 없었기 때문에 대안을 찾기 시작했습니다.

s4cmd
에 새로운 멀티 스레드 대안을 s3cmd. 더 유망 해 보였지만 이미 로컬 파일 시스템에있는 파일을 계속 다시 다운로드하는 것으로 나타났습니다. 그것은 내가 sync 명령에서 기대했던 종류의 행동이 아닙니다. 원격 파일이 이미 로컬에 있는지 확인하고 (해시 / 파일 크기 확인은 깔끔 할 것임) 동일한 대상 디렉터리에서 다음 동기화 실행시이를 건너 뜁니다. 이 이상한 동작을보고하기 위해 문제 ( bloomreach / s4cmd / # 46 )를 열었습니다 . 그 동안 나는 다른 대안을 찾기 시작했습니다.

awscli
그리고 나는 awscli. 이것은 S3가 포함 된 다양한 클라우드 서비스와 상호 작용하기위한 Amazon의 공식 명령 줄 인터페이스입니다.

원격 버킷 파일을 로컬 파일 시스템에 빠르고 쉽게 다운로드 하는 유용한 동기화 명령을 제공합니다 .

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

혜택:

• 확장 가능-거대한 S3 버킷 지원
• 다중 스레드-다중 스레드를 활용하여 파일을 더 빠르게 동기화합니다.
• 스마트-새 파일 또는 업데이트 된 파일 만 동기화
• 빠름-다중 스레드 특성과 스마트 동기화 알고리즘 덕분에

실수로 인한 삭제

편리하게도이 sync명령은 소스 (S3 버킷)에서 누락 된 경우 대상 폴더 (로컬 파일 시스템)의 파일을 삭제하지 않으며 그 반대의 경우도 마찬가지입니다. 이는 S3 백업에 적합합니다. 파일이 버킷에서 삭제 된 경우 다시 동기화해도 로컬에서 삭제되지 않습니다. 로컬 파일을 삭제하는 경우 소스 버킷에서도 삭제되지 않습니다.

Ubuntu 14.04 LTS에서 awscli 설정

를 설치하여 시작하겠습니다 awscli. 이를 수행 하는 방법 에는 여러 가지 가 있지만을 통해 설치하는 것이 가장 쉽다는 것을 알았습니다 apt-get.

$ sudo apt-get install awscli

구성

다음 으로 사용자를 생성하고 AmazonS3ReadOnlyAccess 정책을 연결하여 IAM 에서 awscli가져와야하는 액세스 키 ID 및 비밀 키로 구성 해야합니다 . 이렇게하면 이러한 자격 증명에 액세스 할 수있는 사용자 나 다른 사람이 S3 파일을 삭제하는 것을 방지 할 수 있습니다. 같은 S3 지역을 입력해야합니다 .us-east-1

$ aws 구성

예비

로컬 S3 백업 디렉터리 (가급적 /home/ubuntu/s3/{BUCKET_NAME}. {BUCKET_NAME}실제 버킷 이름 으로 바꾸십시오 .

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

초기 동기화

계속해서 다음 명령을 사용하여 처음으로 버킷을 동기화 해 보겠습니다.

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

버킷이 존재하고 AWS 자격 증명 및 리전이 올 바르고 대상 폴더가 유효하다고 가정 awscli하면 전체 버킷을 로컬 파일 시스템에 다운로드하기 시작합니다.

버킷의 크기와 인터넷 연결에 따라 몇 초에서 몇 시간까지 걸릴 수 있습니다. 완료되면 버킷의 로컬 사본을 최신 상태로 유지하기 위해 자동 크론 작업을 설정합니다.

Cron 작업 설정

계속해서 다음 위치에 sync.sh파일을 만듭니다 /home/ubuntu/s3.

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

다음 코드를 복사하여에 붙여 넣으십시오 sync.sh.

#! / bin / sh

# 현재 날짜와 시간을 에코

에코 '-----------------------------'
데이트
에코 '-----------------------------'
에코 ''

# 에코 스크립트 초기화
echo '원격 S3 버킷 동기화 중 ...'

# 실제로 sync 명령을 실행합니다 ({BUCKET_NAME}을 S3 버킷 이름으로 대체)
/ usr / bin / aws s3 sync s3 : // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

# 에코 스크립트 완성
echo '동기화 완료'

스크립트 전체에서 {BUCKET_NAME} 을 S3 버킷 이름으로 두 번 바꿔야 합니다.

전문가 팁 : 제한된 셸 환경에서 명령을 실행하고 자체적으로 실행 파일을 찾을 수 없으므로 바이너리 /usr/bin/aws에 연결 하려면 을 사용해야 합니다 .awscrontab

다음으로 chmod스크립트를 확인하여 crontab.

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

Let's try running the script to make sure it actually works:

$ /home/ubuntu/s3/sync.sh

The output should be similar to this:

Next, let's edit the current user's crontab by executing the following command:

$ crontab -e

If this is your first time executing crontab -e, you'll need to select a preferred editor. I'd recommend selecting nano as it's the easiest for beginners to work with.

Sync Frequency

We need to tell crontab how often to run our script and where the script resides on the local filesystem by writing a command. The format for this command is as follows:

m h  dom mon dow   command

The following command configures crontab to run the sync.sh script every hour (specified via the minute:0 and hour:* parameters) and to have it pipe the script's output to a sync.log file in our s3 directory:

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

You should add this line to the bottom of the crontab file you are editing. Then, go ahead and save the file to disk by pressing Ctrl + W and then Enter. You can then exit nano by pressing Ctrl + X. crontab will now run the sync task every hour.

Pro tip: You can verify that the hourly cron job is being executed successfully by inspecting /home/ubuntu/s3/sync.log, checking its contents for the execution date & time, and inspecting the logs to see which new files have been synced.

All set! Your S3 bucket will now get synced to your EC2 server every hour automatically, and you should be good to go. Do note that over time, as your S3 bucket gets bigger, you may have to increase your EC2 server's EBS volume size to accommodate new files. You can always increase your EBS volume size by following this guide.

---

Taking into account the related link, which explains that S3 has 99.999999999% durability, I would discard your concern #1. Seriously.

Now, if #2 is a valid use case and a real concern for you, I would definitely stick with options #1 or #3. Which one of them? It really depends on some questions:

• Do you need any other of the versioning features or is it only to avoid accidental overwrites/deletes?
• Is the extra cost imposed by versioning affordable?
• Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. Is this OK for you?

Unless your storage use is really huge, I would stick with bucket versioning. This way, you won't need any extra code/workflow to backup data to Glacier, to other buckets, or even to any other server (which is really a bad choice IMHO, please forget about it).

---

How about using the readily available Cross Region Replication feature on the S3 buckets itself? Here are some useful articles about the feature

• https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/
• http://docs.aws.amazon.com/AmazonS3/latest/UG/cross-region-replication.html

---

You'd think there would be an easier way by now to just hold some sort of incremental backups on a diff region.

All the suggestions above are not really simple or elegant solutions. I don't really consider glacier an option as I think thats more of an archival solution then a backup solution. When I think backup I think disaster recovery from a junior developer recursively deleting a bucket or perhaps an exploit or bug in your app that deletes stuff from s3.

To me, the best solution would be a script that just backs up one bucket to another region, one daily and one weekly so that if something terrible happens you can just switch regions. I don't have a setup like this, I've looked into just haven't gotten around to doing it cause it would take a bit of effort to do this which is why I wish there was some stock solution to use.

---

You can backup your S3 data using the following methods

1. Schedule backup process using AWS datapipeline ,it can be done in 2 ways mentioned below:

   a. Using copyActivity of datapipeline using which you can copy from one s3 bucket to another s3 bucket.

   b. Using ShellActivity of datapipeline and "S3distcp" commands to do the recursive copy of recursive s3 folders from bucket to another (in parallel).

2. Use versioning inside the S3 bucket to maintain different version of data

3. Use glacier for backup your data ( use it when you don't need to restore the backup fast to the original buckets(it take some time to get back the data from glacier as data is stored in compressed format) or when you want to save some cost by avoiding to use another s3 bucket fro backup), this option can easily be set using the lifecycle rule on the s3 bucket fro which you want to take backup.

Option 1 can give you more security let say in case you accidentally delete your original s3 bucket and another benefit is that you can store your backup in datewise folders in another s3 bucket, this way you know what data you had on a particular date and can restore a specific date backup . It all depends on you use case.

---

While this question was posted some time ago, I thought it important to mention MFA delete protection with the other solutions. The OP is trying to solve for the accidental deletion of data. Multi-factor authentication (MFA) manifests in two different scenarios here -

1. Permanently deleting object versions - Enable MFA delete on the bucket's versioning.

2. Accidentally deleting the bucket itself - Set up a bucket policy denying delete without MFA authentication.

Couple with cross-region replication and versioning to reduce the risk of data loss and improve the recovery scenarios.

Here is a blog post on this topic with more detail.

참고 URL : https://stackoverflow.com/questions/17832860/backup-strategies-for-aws-s3-bucket