posgresql 데이터베이스를 EC2로 이동할 준비가되었지만 최선의 백업 및 복구 전략에 대해 조금 분명하지 않습니다. 원래 계획은 EBS 백업 서버를 구축하고 WAL 보관 및 기본 백업을 처리하도록 WAL-E를 설정하는 것이 었습니다. 인스턴스가 손상된 경우 최종 생산 서버 볼륨의 스냅 샷을 사용하여 사용합니다. 많은 사람들이 복구 목적으로 EBS의 스냅 샷을 자주 수행하는 것을 볼 수 있습니다.EC2의 PostgreSQL 용 EBS 스냅 샷 대 WAL-E
권장 전략은 무엇입니까? WAL 및 예약 된 EBS 스냅 샷을 사용하여 보관해야하는 이유가 있습니까?
EBS 스냅 샷은 WAL-E 백업보다 약간 다른 백업 유형을 제공합니다. EBS는 전체 드라이브를 백업합니다. 즉, EC2 Virt가 다운되면 마지막 EBS 스냅 샷으로 virt를 재시작 할 수 있고 마지막으로 스냅 샷을 찍은 부분이 바로 픽업됩니다.
EBS 스냅 샷의 빈도는 데이터베이스 백업이 얼마나 좋은지를 정의합니다.
WAL-E에 대한 매력적인 점은 "지속적인 보관"입니다. 모든 DB 트랜잭션을 백업해야한다면 WAL-E가 올바른 선택입니다. 내가 상상할 수있는 Manys 앱은 거래를 잃을 여유가 없어 매우 신중한 선택 인 것 같습니다.
나는 프로덕션 볼륨을 기준으로 스냅 샷을 작성한 다음 WAL-E를 사용하여 데이터베이스를 지속적으로 아카이빙하는 것이 매우 합리적이라고 생각합니다. 개인적으로 나는 정기적 인 스냅 샷 (하루에 한 번?)을 계획에 추가하여 엄격한 기준선을 설정하고 복구 프로세스를 좀 더 쉽게 만들 수 있습니다.
"복구 계획을 테스트하십시오!"라는 일반적인주의 사항 여기에 적용됩니다. 많은 기술 (EC2, EBS, Postgres, Snapshots, S3, WAL-E)을 혼합하여 실제로 복구 할 수 있는지 확인하는 것이 중요합니다.
EBS 스냅 샷은 전체 디스크의 이미지를 저장하므로 서버에있는 모든 디스크를 백업하고 데이터 손실이나 재해 발생시 전체적으로 복구 할 수 있습니다. 그 외에도 EBS 스냅 샷의 블록 수준 속성을 사용하면 즉각적인 복구가 가능하며 1TB 데이터베이스를 복원하여 몇 분 내에 실행할 수 있습니다. WAL-E와 같은 파일 기반 솔루션을 사용하여 1TB 데이터베이스를 처음부터 복구하려면 S3에서 데이터를 먼저 복사해야합니다.이 프로세스는 몇 시간이 걸립니다. WAL 파일을 복구에 사용하는 것은 좋은 방법입니다. 트랜잭션으로 언제든지 되돌아 갈 수 있지만 전체 서버 스냅 샷에는 WAL 파일도 포함되므로이 옵션을 사용할 수 있습니다. EBS 스냅 샷을 사용한 백업 및 신속 복구 프로세스는 스크립트 또는 EC2 백업 솔루션 (예 : Backup solutions for AWS EC2 instances)을 사용하여 자동화 할 수 있습니다.