S3 버킷을 백업하기위한 조언이나 모범 사례를 찾고 있습니다.
S3에서 데이터를 백업하는 목적은 다음과 같은 이유로 데이터 손실을 방지하는 것입니다.
몇 가지 조사 후 다음 옵션이 표시됩니다.
어떤 옵션을 선택해야하며 S3에만 데이터를 저장하는 것이 얼마나 안전합니까? 여러분의 의견을 듣고 싶습니다.
유용한 링크 :
답변:
내 블로그에 원래 게시 됨 : http://eladnava.com/backing-up-your-amazon-s3-buckets-to-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 /
편리하게도이 sync명령은 소스 (S3 버킷)에서 누락 된 경우 대상 폴더 (로컬 파일 시스템)의 파일을 삭제하지 않으며 그 반대의 경우도 마찬가지입니다. 이는 S3 백업에 적합합니다. 파일이 버킷에서 삭제 된 경우 다시 동기화해도 로컬에서 삭제되지 않습니다. 로컬 파일을 삭제하는 경우 소스 버킷에서도 삭제되지 않습니다.
먼저 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하면 전체 버킷을 로컬 파일 시스템에 다운로드하기 시작합니다.
버킷의 크기와 인터넷 연결에 따라 몇 초에서 몇 시간까지 걸릴 수 있습니다. 완료되면 버킷의 로컬 사본을 최신 상태로 유지하기 위해 자동 크론 작업을 설정합니다.
계속해서 다음 위치에 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
실제로 작동하는지 확인하기 위해 스크립트를 실행 해 보겠습니다.
$ /home/ubuntu/s3/sync.sh
출력은 다음과 유사해야합니다.
다음으로 crontab다음 명령을 실행하여 현재 사용자를 편집 해 보겠습니다 .
$ crontab -e
를 처음 실행 crontab -e하는 경우 선호하는 편집기를 선택해야합니다. nano초보자가 작업하기 가장 쉬운 방법을 선택 하는 것이 좋습니다 .
crontab명령을 작성하여 스크립트를 실행하는 빈도와 스크립트가 로컬 파일 시스템에있는 위치 를 알려야 합니다. 이 명령의 형식은 다음과 같습니다.
mh dom mon dow 명령
다음 명령 crontab은 sync.sh매시간 스크립트 를 실행하고 (minute : 0 및 hour : * 매개 변수를 통해 지정됨) 스크립트의 출력을 디렉토리 의 sync.log파일로 파이프하도록 구성합니다 s3.
0 * * * * /home/ubuntu/s3/sync.sh> /home/ubuntu/s3/sync.log
이 줄을 crontab편집 중인 파일 의 맨 아래에 추가해야합니다 . 그런 다음 Ctrl + W 를 누른 다음 Enter 키 를 눌러 파일을 디스크에 저장 하십시오 . 그런 다음 Ctrl + Xnano 를 눌러 종료 할 수 있습니다 . 이제 매시간 동기화 작업을 실행합니다.crontab
전문가 팁 : 을 검사
/home/ubuntu/s3/sync.log하고 실행 날짜 및 시간에 대한 내용을 확인하고 로그를 검사하여 동기화 된 새 파일을 확인하여 시간별 크론 작업이 성공적으로 실행되고 있는지 확인할 수 있습니다 .
모든 설정! 이제 S3 버킷이 매시간마다 EC2 서버에 자동으로 동기화되므로 잘 사용할 수 있습니다. 시간이 지남에 따라 S3 버킷이 커지면 새 파일을 수용하기 위해 EC2 서버의 EBS 볼륨 크기를 늘려야 할 수 있습니다. 이 가이드 에 따라 언제든지 EBS 볼륨 크기를 늘릴 수 있습니다 .
awscli에서 aws s3 sync명령 에서 자동으로 동기화를 지원 하지 않는 것 같습니다 . 수동으로 구현해야 할 수 있습니다.
S3의 내구성이 99.999999999 %임을 설명하는 관련 링크를 고려하여 우려 사항 # 1을 삭제하겠습니다. 진지하게.
이제 # 2가 유효한 사용 사례이고 진정한 관심사라면 옵션 # 1 또는 # 3을 확실히 고수 할 것입니다. 그들 중 어느 것입니까? 실제로 몇 가지 질문에 따라 다릅니다.
Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. 괜찮습니까? 스토리지 사용량이 너무 크지 않으면 버킷 버전 관리를 고수 할 것입니다. 이렇게하면 데이터를 Glacier, 다른 버킷 또는 다른 서버에 백업하기 위해 추가 코드 / 워크 플로가 필요하지 않습니다 (진짜 나쁜 선택입니다. IMHO, 잊어 버리세요).
다음 방법을 사용하여 S3 데이터를 백업 할 수 있습니다.
AWS datapipeline을 사용하여 백업 프로세스를 예약합니다. 아래 두 가지 방법으로 수행 할 수 있습니다.
ㅏ. 한 s3 버킷에서 다른 s3 버킷으로 복사 할 수있는 datapipeline의 copyActivity 사용.
비. Datapipeline의 ShellActivity 및 "S3distcp"명령을 사용하여 버킷에서 다른 버킷으로 (병렬로) 재귀 s3 폴더의 재귀 복사를 수행합니다.
S3 버킷 내에서 버전 관리를 사용하여 다른 버전의 데이터 유지
데이터를 백업하는 데 glacier를 사용하십시오 (백업을 원래 버킷으로 빠르게 복원 할 필요가없는 경우 (데이터가 압축 된 형식으로 저장되기 때문에 glacier에서 데이터를 가져 오는 데 시간이 다소 소요됨) 또는 저장하려는 경우 사용하십시오. 백업을 위해 다른 s3 버킷을 사용하는 것을 피함으로써 비용이 발생할 수 있음)이 옵션은 백업을 수행하려는 s3 버킷의 수명주기 규칙을 사용하여 쉽게 설정할 수 있습니다.
옵션 1은 원래 s3 버킷을 실수로 삭제 한 경우를 대비하여 더 많은 보안을 제공 할 수 있으며 또 다른 이점은 백업을 다른 s3 버킷의 datewise 폴더에 저장할 수 있다는 것입니다. 이렇게하면 특정 날짜에 어떤 데이터가 있었는지 알 수 있습니다. 특정 날짜 백업을 복원합니다. 그것은 모두 당신의 사용 사례에 달려 있습니다.
S3 버킷 자체 에서 즉시 사용 가능한 교차 리전 복제 기능을 사용하는 것은 어떻습니까? 다음은 기능에 대한 유용한 기사입니다.
지금 쯤이면 diff 지역에 일종의 증분 백업을 보관하는 더 쉬운 방법이 있다고 생각할 것입니다.
위의 모든 제안은 정말 간단하거나 우아한 솔루션이 아닙니다. 저는 빙하가 백업 솔루션보다 아카이브 솔루션에 더 가깝다고 생각하기 때문에 빙하를 옵션으로 생각하지 않습니다. 백업을 생각할 때 주니어 개발자가 재귀 적으로 버킷을 삭제하거나 s3에서 항목을 삭제하는 악용 또는 버그를 앱에서 삭제하는 재해 복구를 생각합니다.
나에게 가장 좋은 해결책은 하나의 버킷을 다른 지역에 매일, 매주 하나씩 백업하는 스크립트로, 끔찍한 일이 발생하면 지역을 전환 할 수 있습니다. 나는 이와 같은 설정을 가지고 있지 않으며, 이것을 수행하는 데 약간의 노력이 필요할 것이기 때문에 내가 사용할 재고 솔루션이 있었으면 좋겠다고 생각했습니다.
이 질문은 얼마 전에 게시되었지만 다른 솔루션과 함께 MFA 삭제 보호 를 언급하는 것이 중요하다고 생각했습니다 . OP는 실수로 인한 데이터 삭제 를 해결하기 위해 노력하고 있습니다. MFA (다단계 인증)는 여기에 두 가지 다른 시나리오로 나타납니다.
객체 버전 영구 삭제-버킷의 버전 관리에서 MFA 삭제를 활성화합니다.
실수로 버킷 자체 삭제-MFA 인증없이 삭제를 거부하는 버킷 정책을 설정합니다.
지역 간 복제 및 버전 관리 와 결합 하여 데이터 손실 위험을 줄이고 복구 시나리오를 개선합니다.
다음은 이 주제에 대한 자세한 블로그 게시물 입니다.
데이터가 너무 많다면. 이미 버킷이 있다면 처음에는 동기화에 너무 많은 시간이 걸릴 것입니다. 제 경우에는 400GB가있었습니다. 처음에는 3 시간이 걸렸습니다. 따라서 복제본을 S3 버킷 백업에 적합한 솔루션으로 만들 수 있다고 생각합니다.