스냅샷과 AMI를 사용한 Amazon EC2 백업 및 복구

Amazon Machine Image(AMI)를 사용하여 EC2 인스턴스의 전체 백업을 생성해야 하는지 아니면 개별 볼륨의 스냅샷을 생성해야 하는지 고려해 보십시오.

AMI 또는 Amazon EBS 스냅샷을 백업에 사용

AMI는 다음을 포함합니다.

• 하나 이상의 스냅샷 I nstance-store-backed AMI에는 인스턴스의 루트 볼륨 (예: 운영 체제, 애플리케이션 서버, 애플리케이션) 을 위한 템플릿이 포함되어 있습니다.

• AMI를 사용하여 인스턴스를 시작할 수 있는 AWS 계정을 제어하는 시작 권한.

• 시작될 때 인스턴스에 연결할 볼륨을 지정하는 블록 디바이스 매핑

AMI를 사용하여 미리 구성된 소프트웨어 및 데이터로 새 인스턴스를 시작할 수 있습니다. 더 많은 인스턴스를 시작하기 위한 재사용 가능한 구성이 되는 기준을 설정하려는 경우 AMI를 생성할 수 있습니다. 기존 EC2 인스턴스의 AMI를 생성하면 인스턴스에 연결된 모든 볼륨의 스냅샷이 생성됩니다. 스냅샷에는 디바이스 매핑이 포함됩니다.

스냅샷을 사용하여 새 인스턴스를 시작할 수는 없지만 기존 인스턴스의 볼륨을 대체하는 데는 스냅샷을 사용할 수 있습니다. 데이터 손상이나 볼륨 장애가 발생하는 경우, 생성한 스냅샷으로 볼륨을 생성하고 이전 볼륨을 교체할 수 있습니다. 스냅샷을 사용하여 새 볼륨을 프로비저닝하고 새 인스턴스 시작 중에 연결할 수도 있습니다.

에서 유지 AWS 관리하거나 에서 게시한 플랫폼 및 애플리케이션 AMI를 사용하는 경우 데이터에 대해 별도의 볼륨을 유지하는 것이 좋습니다. AWS Marketplace 데이터 볼륨을 운영 체제 및 애플리케이션 볼륨과 분리된 스냅샷으로 백업할 수 있습니다. 그런 다음 에서 AWS 게시하거나 에서 게시한 새로 업데이트된 AMI와 함께 데이터 볼륨 스냅샷을 사용하십시오. AWS Marketplace 이 방법을 사용하려면 새로 게시된 AMI에서 구성 정보를 포함한 모든 사용자 지정 데이터를 백업하고 복원하기 위한 신중한 테스트와 계획이 필요합니다.

복원 프로세스는 AMI 백업과 스냅샷 백업 중에서 어떤 것을 선택하느냐에 영향을 받습니다. 인스턴스 백업으로 사용할 AMI를 생성하는 경우 복원 프로세스의 일부로 AMI에서 EC2 인스턴스를 시작해야 합니다. 잠재적 충돌을 방지하기 위해 기존 인스턴스를 종료해야 할 수도 있습니다. 잠재적 충돌의 예로는 도메인에 가입된 Windows 인스턴스의 SID(보안 식별자)를 들 수 있습니다. 스냅샷의 복원 프로세스에서는 기존 볼륨을 분리하고 새로 복원된 볼륨을 연결해야 할 수 있습니다. 또는 애플리케이션이 새로 연결된 볼륨을 가리키도록 구성을 변경해야 할 수도 있습니다.

AWS Backup AMI로서의 인스턴스 수준 백업과 별도의 스냅샷으로서의 볼륨 수준 백업을 모두 지원합니다.

• 인스턴스의 모든 EBS 볼륨을 전체 백업하려면 Linux 또는 Windows에서 실행되는 EC2 인스턴스의 AMI를 생성하십시오. 롤백하려면 인스턴스 시작 마법사를 사용하여 인스턴스를 생성하십시오. 인스턴스 시작 마법사에서 My AMI를 선택합니다.

• 개별 볼륨을 백업하려면 스냅샷을 생성하십시오. 스냅샷을 복원하려면 스냅샷에서 볼륨 만들기를 참조하십시오. AWS Management Console 또는 AWS Command Line Interface (AWS CLI) 를 사용할 수 있습니다.

인스턴스 AMI의 비용은 인스턴스에 있는 모든 볼륨의 스토리지이지만 메타데이터는 아닙니다. EBS 스냅샷 비용은 개별 볼륨의 스토리지입니다. 볼륨 스토리지 비용에 대한 자세한 내용은 Amazon EBS 요금 페이지를 참조하십시오.

서버 볼륨

EBS 볼륨은 Amazon EC2의 기본 영구 스토리지 옵션입니다. 이 블록 스토리지는 데이터베이스와 같은 정형 데이터나 볼륨의 파일 시스템에 있는 파일과 같은 비정형 데이터에 사용할 수 있습니다.

EBS 볼륨은 특정 사용 가능 영역에 배치됩니다. 볼륨은 여러 서버에 복제되어 단일 구성 요소의 장애로 인한 데이터 손실을 방지합니다. 장애란 볼륨의 크기와 성능에 따라 볼륨이 완전히 또는 부분적으로 손실되는 것을 말합니다.

EBS 볼륨은 0.1~0.2% 의 AFR(연간 고장률)을 제공하도록 설계되었습니다. 따라서 EBS 볼륨의 안정성은 약 4%의 AFR로 실패하는 일반적인 상용 디스크 드라이브보다 20배 더 안정적입니다. 예를 들어, 1년 동안 1,000개의 EBS 볼륨을 실행한다면 한두 개의 볼륨에서 장애가 발생할 것으로 예상해야 합니다.

Amazon EBS는 데이터 point-in-time 백업을 위한 스냅샷 기능도 지원합니다. 모든 EBS 볼륨 유형은 내구적 스냅샷 기능을 제공하고 99.999% 가용성으로 설계되었습니다. 자세한 내용은 Amazon 컴퓨팅 서비스 수준 계약을 참조하십시오.

Amazon EBS는 모든 EBS 볼륨의 스냅샷(백업)을 생성할 수 있는 기능을 제공합니다. 스냅샷은 EBS 볼륨의 백업을 생성하기 위한 기본 기능입니다. 스냅샷은 EBS 볼륨의 사본을 복수 가용 영역에 중복 저장되는 Amazon S3에 저장합니다. 초기 스냅샷은 볼륨의 전체 사본이며, 진행 중인 스냅샷은 블록 수준의 증분 변경 사항만 저장합니다. Amazon EBS 스냅샷을 생성하는 방법에 대한 자세한 내용은 Amazon EC2 설명서를 참조하십시오.

스냅샷을 촬영한 동일한 리전의 Amazon EC2 콘솔에서 복원 작업을 수행하거나, 스냅샷을 삭제하거나, 스냅샷과 관련된 스냅샷 메타데이터(예: 태그)를 업데이트할 수 있습니다.

스냅샷을 복원하면 전체 볼륨 데이터가 포함된 새 Amazon EBS 볼륨이 생성됩니다. 부분 복원만 필요한 경우 다른 디바이스 이름으로 실행 중인 인스턴스에 볼륨을 연결할 수 있습니다. 그런 다음 마운트하고 운영 체제 복사 명령을 사용하여 백업 볼륨의 데이터를 프로덕션 볼륨으로 복사합니다.

Amazon EC2 설명서에 설명된 대로 Amazon EBS 스냅샷 복사 기능을 사용하여 AWS 지역 간에 Amazon EBS 스냅샷을 복사할 수도 있습니다. 이 기능을 사용하면 기본 복제 기술을 관리할 필요 없이 백업을 다른 리전에 저장할 수 있습니다.

별도의 서버 볼륨 설정

운영 체제, 로그, 애플리케이션 및 데이터에 대해 별도의 표준 볼륨 세트를 이미 사용하고 있을 수 있습니다. 별도의 서버 볼륨을 설정하면 디스크 공간 소진으로 인한 애플리케이션 또는 플랫폼 장애 발생 시 영향 범위를 줄일 수 있습니다. 물리적 하드 드라이브는 볼륨을 빠르게 확장할 수 있는 유연성이 없기 때문에 일반적으로 이러한 위험은 더 큽니다. 물리적 드라이브의 경우 새 드라이브를 구입하여 데이터를 백업한 다음 새 드라이브에 데이터를 복원해야 합니다. 를 사용하면 AWS Amazon EBS를 사용하여 프로비저닝된 볼륨을 확장할 수 있으므로 이러한 위험이 크게 줄어듭니다. 자세한 내용은 AWS 설명서를 참조하십시오.

애플리케이션 데이터, 사용자 데이터, 로그 및 스왑 파일을 위한 별도의 볼륨을 유지하여 이러한 리소스에 대해 별도의 백업 및 복원 정책을 사용할 수 있습니다. 데이터의 볼륨을 분리하여 데이터의 성능 및 스토리지 요구 사항에 따라 다양한 볼륨 유형을 사용할 수도 있습니다. 그런 다음 다양한 워크로드에 맞게 비용을 최적화하고 세밀하게 조정할 수 있습니다.

인스턴스 스토어 볼륨에 대한 고려 사항

인스턴스 스토어는 인스턴스에 블록 수준의 임시 스토리지를 제공합니다. 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치합니다. 인스턴스 스토어는 버퍼, 캐시, 스크래치 데이터, 기타 임시 콘텐츠와 같이 자주 변경되는 정보의 임시 저장에 적합합니다. 또한 로드 밸런싱된 웹 서버 풀과 같은 인스턴스 플릿 전체에 복제되는 데이터에도 적합합니다.

인스턴스 스토리지의 데이터는 관련 인스턴스의 수명 기간 동안만 지속됩니다. 인스턴스가 재부팅(의도적 또는 의도적이지 않게)되면 인스턴스 스토어의 데이터는 유지됩니다. 그러나 다음 상황에서는 인스턴스 스토어의 데이터가 손실됩니다.

• 기본 드라이브 오류

• 인스턴스가 중지됩니다.

• 인스턴스가 종료됩니다.

그러므로 중요한 장기 데이터의 경우 인스턴스 스토어에 의존하지 마십시오. 오히려 Amazon S3, Amazon EBS 또는 Amazon EFS 등 내구성이 뛰어난 데이터 스토리지를 사용하는 것이 좋습니다.

인스턴스 스토어 볼륨의 일반적인 전략은 RPO(복구 시점 목표) 및 RTO(복구 시간 목표)를 기반으로 필요에 따라 필요한 데이터를 Amazon S3에 정기적으로 보관하는 것입니다. 그러면 새 인스턴스가 시작될 때 Amazon S3에서 인스턴스 스토어로 데이터를 다운로드할 수 있습니다. 인스턴스가 중지되기 전에 Amazon S3에 데이터를 업로드할 수도 있습니다. 지속성을 위해 EBS 볼륨을 생성하여 인스턴스에 연결하고 인스턴스 스토어 볼륨의 데이터를 주기적으로 EBS 볼륨으로 복사하십시오. 자세한 정보는 AWS 지식 센터를 참조하십시오.

EBS 스냅샷 및 AMI에 대한 태그 지정 및 표준 적용

모든 AWS 리소스에 태그를 지정하는 것은 비용 할당, 감사, 문제 해결 및 알림을 위한 중요한 관행입니다. EBS 볼륨에서는 볼륨을 관리하고 복원하는 데 필요한 관련 정보가 표시되도록 하기 위해 태그를 지정하는 것이 중요합니다. 태그는 EC2 인스턴스에서 AMI로 또는 소스 볼륨에서 스냅샷으로 자동으로 복사되지 않습니다. 백업 프로세스에 이러한 소스의 관련 태그가 포함되어 있는지 확인하십시오. 그러면 액세스 정책, 연결 정보, 비용 할당 등의 스냅샷 메타데이터를 설정하여 나중에 이러한 백업을 사용하는 데 도움이 됩니다. AWS 리소스에 태그를 지정하는 방법에 대한 자세한 내용은 태깅 모범 사례 기술 문서를 참조하십시오.

모든 AWS 리소스에 사용하는 태그 외에도 다음과 같은 백업별 태그를 사용하십시오.

• 소스 인스턴스 ID

• 소스 볼륨 ID(스냅샷용)

• 복구 시점 설명

규칙 및 IAM 권한을 사용하여 AWS Config 태깅 정책을 적용할 수 있습니다. IAM은 강제 태그 사용을 지원하므로 Amazon EBS 스냅샷에서 작업할 때 특정 태그의 사용을 의무화하는 IAM 정책을 작성할 수 있습니다. IAM 권한 정책에 정의된 태그에 권한을 부여하지 않고 CreateSnapshot 작업을 시도하면 액세스가 거부되면서 스냅샷 생성이 실패합니다. 자세한 내용은 Amazon EBS 스냅샷 생성 시 태그 지정 및 더 강력한 보안 정책 구현에 관한 블로그 게시물을 참조하십시오.

AWS Config 규칙을 사용하여 리소스의 구성 설정을 자동으로 평가할 수 AWS 있습니다. 시작하는 데 도움이 되도록 관리형 규칙이라는 사용자 지정 가능하고 사전 정의된 규칙을 AWS Config 제공합니다. 고유의 사용자 지정 규칙을 만들 수도 있습니다. 리소스 간의 구성 변경을 AWS Config 지속적으로 추적하면서 이러한 변경이 규칙의 조건을 위반하는지 확인합니다. 리소스가 규칙을 위반하는 경우 해당 리소스와 규칙을 준수하지 않는 것으로 AWS Config 플래그를 지정합니다. 필수 태그 관리형 규칙은 현재 스냅샷과 AMI를 지원하지 않습니다.