Amazon EC2를 사용하여 몇 가지 웹 서버 / DB 서버 설정이 있습니다. 현재 모든 응용 프로그램 파일, DB 파일, 소스 코드 및 DB 백업이 포함 된 모든 시스템 및 EBS 드라이브의 매일 스냅 샷을 작성하고 있습니다. 일정에 따라 백업 생성을 실행하는 콘솔 응용 프로그램이 있습니다. 내 이미지는 EBS 이미지입니다.
며칠 후에 스냅 샷을 삭제하는 작업을하고 있습니다. 내 질문은, 전체 이미지 / EBS 작업도 예약해야합니까? 이 방법으로 서버가 고장 나거나 손상된 경우 최신 이미지를 시작한 다음 최신 스냅 샷을 적용하면됩니다.
백업 전략을 진행하면서 Jungle Disc를 사용하여 데이터 디스크를 백업하고 있습니다.
답변:
내 추천 :
인스턴스를 잃어버린 경우 소프트웨어 설치 및 시스템 구성을 재현 할 수 있도록 항상 각 새 인스턴스의 설정을 문서화 및 / 또는 스크립팅하십시오. 새 인스턴스를 시작하고 절차에 따라이를 테스트하십시오. 설치 시간이 오래 걸리고 인스턴스를 빠르게 시작해야하는 경우 사용자 지정 프라이빗 AMI를 사용할 수 있지만 해당 AMI 자체는 문서화 및 / 또는 스크립팅 된 절차를 사용하여 구축해야합니다.
중요한 데이터는 루트 EBS 볼륨이 아닌 별도의 EBS 볼륨에 보관하십시오. 여기에는 데이터를 새로운 인스턴스 (예 : 다른 AMI 기반)로 쉽게 포팅하고 다른 인스턴스 (예 : 스냅 샷 및 새 볼륨)에서 데이터 사본을보다 쉽게 가져올 수있는 등 많은 이점이 있습니다.
EBS 데이터 볼륨의 정기적 인 스냅 샷을 만듭니다. 가능하거나 적용 가능한 경우, ec2-consistent-snapshot 과 같은 도구를 사용 하여 일관된 파일 시스템 / 데이터베이스의 스냅 샷을 생성 할 가능성을 높이십시오. AWS 계정 자체는 단일 장애 지점이므로 AWS / EC2 외부의 데이터를 백업하십시오.
중요한 인스턴스에서 때때로 루트 EBS 볼륨의 스냅 샷을 만듭니다. 인스턴스 또는 EBS 볼륨 장애 발생시 도움이 될 수 있지만 위의 # 1 및 # 2로 인해 해당 부분이 그렇게 중요하지는 않습니다. 이 작업을 수행하는 주된 이유는 스냅 샷을 생성하면 루트 EBS 볼륨 자체의 장애 위험이 감소하기 때문입니다.
EBS 볼륨의 실패율은 마지막 EBS 스냅 샷 이후 해당 볼륨에서 수정 된 블록 수와 직접 관련이 있습니다.
완전한 이미지 / EBS 작업도 예약해야합니까?
예, 좋습니다. 부팅 디스크를 더 이상 읽을 수없고 최신 스냅 샷에서 부팅 할 때까지 커널 문제로 인해 여러 번 재설정해야했기 때문에 한 번 저를 구했습니다.
관심이 있으시면 연결된 모든 EBS 볼륨을 스냅 샷하고 일정 시간이 지나면 삭제하는 Java 클래스를 작성했습니다. 현재 매주 백업을 수행하고 2 주 후에 세 번째 백업을 삭제합니다.
EBS가 많은 경우에 대비하여 수십 개의 스냅 샷으로 동시에 오버로드되지 않도록 시간당 크론에 배치하기 때문에 스냅 샷 생성 또는 삭제와 같이 실행 당 하나의 작업 만 수행합니다.
우리는 간단하지만 강력한 백업 전략을 사용합니다. EC2 EBS 인스턴스를 하루에 두 번 실행하는 기반으로 새 AMI를 생성하고“오래된”AMI를 삭제합니다. API (CreateImage)를 통해 새 AMI를 생성하는 동안 또는 시스템 raid – ssh를 CreateIImage API 호출 전에 인스턴스로 고정하고 새 커널의 가장 인기있는 파일 시스템에서 "fsfreeze"로 파일 시스템을 정지하거나 xfs_freeze 인 경우 플래그가 인스턴스를 재부팅하지 않도록 설정할 수 있습니다. 이전 커널과 xfs를 사용합니다.
생성 된 "백업"AMI는 생성 된 스냅 샷에 대한 링크를 통해 원래 실행중인 인스턴스 EBS 디스크에 연결된 모든 것을 기억하고 여러 디스크와 함께 소프트웨어 RAID를 사용하는 경우 하나의 API 호출 또는 웹을 통해 모든 AZ에서 새 인스턴스를 복원 할 수 있습니다. -상호 작용.