기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# EBS 볼륨을 사용하는 Amazon EC2의 백업 및 복구
AWS 는 Amazon EC2 인스턴스를 백업하는 여러 방법을 제공합니다. 이 섹션에서는 Amazon Elastic Block Store(Amazon EBS) 볼륨 또는 스토리지용 인스턴스 저장소 볼륨을 백업하는 데 있어서의 다양한 측면을 다룹니다. 요구 사항을 충족하는 AWS 경우에서 백업을 관리하기 위한 첫 번째 선택 AWS Backup 으로를 고려하세요. 백업은 원래 기능으로 복원할 수 있는 경우에만 유효하다는 점을 기억하세요. 복원 및 복구 기능을 정기적으로 테스트하여 이를 확인해야 합니다.
다음 다이어그램의 솔루션 아키텍처는 Amazon EC2를 기반으로 하는 대부분의 아키텍처와 AWS 함께 완전히에 존재하는 워크로드 환경을 설명합니다. 다음 그림에서 볼 수 있듯이 시나리오에는 웹 서버, 애플리케이션 서버, 모니터링 서버, 데이터베이스, Active Directory 및 재해 복구(DR) 복제가 포함됩니다.
![\[두 개의 가용 영역, 프라이빗 서브넷의 프라이빗 및 복제 데이터베이스, 재해 복구 복제가 있는 예제 환경의 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/backup-recovery/images/workload-environment-aws.png)
AWS 는 인스턴스 및 스토리지를 생성, 프로비저닝, 백업, 복원 및 최적화하는 차별화되지 않은 작업을 수행하기 위해이 아키텍처에 표시된 많은 Amazon EC2 서버에 대해 많은 완전한 기능을 갖춘 서비스를 제공합니다. 이러한 서비스가 아키텍처에서 복잡성과 관리를 줄이기에 적합한지 고려합니다. AWS 또한는 Amazon EC2 기반 아키텍처의 가용성을 개선하기 위한 서비스를 제공합니다. 특히 Amazon EC2의 워크로드를 보완하기 위해 Amazon EC2 Auto Scaling 및 Elastic Load Balancing을 고려해 보세요. 이러한 서비스를 사용하면 아키텍처의 가용성과 내결함성을 개선하고 사용자에게 미치는 영향을 최소화하면서 손상된 인스턴스를 복원할 수 있습니다.
EC2 인스턴스는 영구 스토리지용 Amazon EBS 볼륨을 주로 사용합니다. Amazon EBS는 이 섹션에서 자세히 설명하는 다양한 백업 및 복구 기능을 제공합니다.
**Topics**
+ [스냅샷과 AMI를 사용한 Amazon EC2 백업 및 복구](ec2-backup.md)
+ [AMI와 EBS 스냅샷을 사용하여 EBS 볼륨 백업 생성](new-ebs-volume-backups.md)
+ [Amazon EBS 볼륨 또는 EC2 인스턴스 복원](restore.md)
# 스냅샷과 AMI를 사용한 Amazon EC2 백업 및 복구
Amazon Machine Image(AMI)를 사용하여 EC2 인스턴스의 전체 백업을 생성해야 하는지 아니면 개별 볼륨의 스냅샷을 생성해야 하는지 고려해 보세요.
## AMI 또는 Amazon EBS 스냅샷을 백업에 사용
AMI는 다음을 포함합니다.
+ 하나 이상의 스냅샷 인스턴스 저장소 지원 AMI에는 인스턴스의 루트 볼륨(예: 운영 체제, 애플리케이션 서버 및 애플리케이션)에 대한 템플릿이 포함되어 있습니다.
+ AMI를 사용하여 인스턴스를 시작할 수 있는 AWS 계정을 제어하는 시작 권한입니다.
+ 시작될 때 인스턴스에 연결할 볼륨을 지정하는 블록 디바이스 매핑
**참고**
대부분의 경우 Windows, Red Hat, SUSE 및 SQL Server용 AMI를 사용하려면 AMI에 올바른 라이선스 정보가 있어야 합니다. 자세한 내용은 [AMI 청구 정보 이해](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-billing-info.html)를 참조하세요. 스냅샷에서 AMI를 생성할 때 `RegisterImage` 작업은 스냅샷의 메타데이터에서 올바른 결제 정보를 가져오지만, 이를 위해서는 적절한 메타데이터가 있어야 합니다. 올바른 결제 정보가 적용되었는지 확인하려면 새 AMI의 **플랫폼 세부 정보** 필드를 확인합니다. 필드가 비어 있거나 예상 운영 체제 코드(예: Windows, Red Hat, SUSE 또는 SQL)와 일치하지 않는 경우 AMI 생성에 실패한 것이므로 AMI를 삭제하고 [인스턴스에서 AMI 생성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami)의 지침을 따라야 합니다.
AMI를 사용하여 미리 구성된 소프트웨어 및 데이터로 새 인스턴스를 시작할 수 있습니다. 더 많은 인스턴스를 시작하기 위한 재사용 가능한 구성이 되는 기준을 설정하려는 경우 AMI를 생성할 수 있습니다. 기존 EC2 인스턴스의 AMI를 생성하면 인스턴스에 연결된 모든 볼륨의 스냅샷이 생성됩니다. 스냅샷에는 디바이스 매핑이 포함됩니다.
스냅샷을 사용하여 새 인스턴스를 시작할 수는 없지만 기존 인스턴스의 볼륨을 대체하는 데는 스냅샷을 사용할 수 있습니다. 데이터 손상이나 볼륨 장애가 발생하는 경우, 생성한 스냅샷으로 볼륨을 생성하고 이전 볼륨을 교체할 수 있습니다. 스냅샷을 사용하여 새 볼륨을 프로비저닝하고 새 인스턴스 시작 중에 연결할 수도 있습니다.
에서 유지 관리하고 게시하는 AWS 플랫폼 및 애플리케이션 AMIs를 사용하는 경우 데이터에 대해 별도의 볼륨을 유지하는 것이 AWS Marketplace좋습니다. 데이터 볼륨을 운영 체제 및 애플리케이션 볼륨과 분리된 스냅샷으로 백업할 수 있습니다. 그런 다음에서 AWS 또는에서 게시한 새로 업데이트된 AMIs 함께 데이터 볼륨 스냅샷을 사용합니다 AWS Marketplace. 이 방법을 사용하려면 새로 게시된 AMI에서 구성 정보를 포함한 모든 사용자 지정 데이터를 백업하고 복원하기 위한 신중한 테스트와 계획이 필요합니다.
복원 프로세스는 AMI 백업과 스냅샷 백업 중에서 어떤 것을 선택하느냐에 영향을 받습니다. 인스턴스 백업으로 사용할 AMI를 생성하는 경우 복원 프로세스의 일부로 AMI에서 EC2 인스턴스를 시작해야 합니다. 잠재적 충돌을 방지하기 위해 기존 인스턴스를 종료해야 할 수도 있습니다. 잠재적 충돌의 예로는 도메인에 가입된 Windows 인스턴스의 SID(보안 식별자)를 들 수 있습니다. 스냅샷의 복원 프로세스에서는 기존 볼륨을 분리하고 새로 복원된 볼륨을 연결해야 할 수 있습니다. 또는 애플리케이션이 새로 연결된 볼륨을 가리키도록 구성을 변경해야 할 수도 있습니다.
AWS Backup 는 인스턴스 수준 백업을 AMIs로 지원하고 볼륨 수준 백업을 별도의 스냅샷으로 지원합니다.
+ 인스턴스의 모든 EBS 볼륨을 완전히 백업하려면 [ EC2 인스턴스의 AMI를 생성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html)합니다. 롤백하려면 인스턴스 시작 마법사를 사용하여 인스턴스를 생성합니다. 인스턴스 시작 마법사에서 **내 AMI**를 선택합니다.
+ 개별 볼륨을 백업하려면 [스냅샷을 생성](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html)합니다. 스냅샷을 복원하려면 [스냅샷에서 볼륨 생성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot)을 참조하세요. 또는 AWS Command Line Interface ()를 사용할 AWS Management Console 수 있습니다AWS CLI.
인스턴스 AMI의 비용은 인스턴스의 모든 볼륨 스토리지에 해당하며, 메타데이터는 포함되지 않습니다. EBS 스냅샷 비용은 개별 볼륨의 스토리지에 해당합니다. 볼륨 스토리지 비용에 대한 자세한 내용은 [Amazon EBS 요금 페이지](https://aws.amazon.com/ebs/pricing/)를 참조하세요.
## 서버 볼륨
EBS 볼륨은 Amazon EC2의 기본 영구 스토리지 옵션입니다. 이 블록 스토리지는 데이터베이스와 같은 정형 데이터나 볼륨의 파일 시스템에 있는 파일과 같은 비정형 데이터에 사용할 수 있습니다.
EBS 볼륨은 특정 사용 가능 영역에 배치됩니다. 볼륨은 여러 서버에 복제되어 단일 구성 요소의 장애로 인한 데이터 손실을 방지합니다. 장애란 볼륨의 크기와 성능에 따라 볼륨이 완전히 또는 부분적으로 손실되는 것을 말합니다.
EBS 볼륨은 0.1\$10.2% 의 AFR(연간 고장률)을 제공하도록 설계되었습니다. 따라서 EBS 볼륨의 안정성은 약 4%의 AFR로 실패하는 일반적인 상용 디스크 드라이브보다 20배 더 안정적입니다. 예를 들어, 1년 동안 1,000개의 EBS 볼륨을 실행한다면 한두 개의 볼륨에서 장애가 발생할 것으로 예상해야 합니다.
Amazon EBS는 데이터의 특정 시점 백업을 위한 스냅샷 기능도 지원합니다. 모든 EBS 볼륨 유형은 내구적 스냅샷 기능을 제공하고 99.999% 가용성으로 설계되었습니다. 자세한 내용은 [Amazon 컴퓨팅 서비스 수준 계약](https://aws.amazon.com/ec2/sla/)을 참조하세요.
Amazon EBS는 모든 EBS 볼륨의 스냅샷(백업)을 생성할 수 있는 기능을 제공합니다. 스냅샷은 EBS 볼륨의 백업을 생성하기 위한 기본 기능입니다. 스냅샷은 EBS 볼륨의 사본을 복수 가용 영역에 중복 저장되는 Amazon S3에 저장합니다. 초기 스냅샷은 볼륨의 전체 사본이며, 진행 중인 스냅샷은 블록 수준의 증분 변경 사항만 저장합니다. Amazon EBS 스냅샷을 생성하는 방법에 대한 자세한 내용은 [Amazon EBS 설명서](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html)를 참조하세요.
스냅샷을 촬영한 동일한 리전의 [Amazon EC2 콘솔에서](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html) 복원 작업을 수행하거나, 스냅샷을 삭제하거나, 스냅샷과 관련된 스냅샷 메타데이터(예: 태그)를 업데이트할 수 있습니다.
스냅샷을 복원하면 전체 볼륨 데이터가 포함된 새 Amazon EBS 볼륨이 생성됩니다. 부분 복원만 필요한 경우 다른 디바이스 이름으로 실행 중인 인스턴스에 볼륨을 연결할 수 있습니다. 그런 다음 마운트하고 운영 체제 복사 명령을 사용하여 백업 볼륨의 데이터를 프로덕션 볼륨으로 복사합니다.
Amazon EBS 설명서에 설명된 대로 Amazon EBS 스냅샷 복사 기능을 사용하여 AWS 리전 간에 Amazon EBS 스냅샷을 복사할 수도 있습니다. [https://docs.aws.amazon.com/ebs/latest/userguide/ebs-copy-snapshot.html](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-copy-snapshot.html) 이 기능을 사용하면 기본 복제 기술을 관리할 필요 없이 백업을 다른 리전에 저장할 수 있습니다.
## 별도의 서버 볼륨 설정
운영 체제, 로그, 애플리케이션 및 데이터에 대해 별도의 표준 볼륨 세트를 이미 사용하고 있을 수 있습니다. 별도의 서버 볼륨을 설정하면 디스크 공간 소진으로 인한 애플리케이션 또는 플랫폼 장애 발생 시 영향 범위를 줄일 수 있습니다. 물리적 하드 드라이브는 볼륨을 빠르게 확장할 수 있는 유연성이 없기 때문에 일반적으로 이러한 위험은 더 큽니다. 물리적 드라이브의 경우 새 드라이브를 구입하여 데이터를 백업한 다음 새 드라이브에 데이터를 복원해야 합니다. 를 사용하면 Amazon EBS를 사용하여 프로비저닝된 볼륨을 확장할 수 있으므로 AWS이 위험이 크게 줄어듭니다. 자세한 내용은 [AWS 설명서](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/modify-volume-requirements.html)를 참조하세요.
애플리케이션 데이터, 사용자 데이터, 로그 및 스왑 파일을 위한 별도의 볼륨을 유지하여 이러한 리소스에 대해 별도의 백업 및 복원 정책을 사용할 수 있습니다. 데이터의 볼륨을 분리하여 데이터의 성능 및 스토리지 요구 사항에 따라 다양한 볼륨 유형을 사용할 수도 있습니다. 그런 다음 다양한 워크로드에 맞게 비용을 최적화하고 세밀하게 조정할 수 있습니다.
## 인스턴스 저장소 볼륨에 대한 고려 사항
인스턴스 저장소는 인스턴스에 임시 블록 스토리지를 제공합니다. 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치합니다. 인스턴스 저장소는 버퍼, 캐시, 스크래치 데이터, 기타 임시 콘텐츠와 같이 자주 변경되는 정보의 임시 저장에 적합합니다. 또한 로드 밸런싱된 웹 서버 풀과 같은 인스턴스 플릿 전체에 복제되는 데이터에도 적합합니다.
인스턴스 저장소의 데이터는 관련 인스턴스의 수명 기간 동안만 지속됩니다. 인스턴스가 재부팅(의도적 또는 의도적이지 않게)되면 인스턴스 저장소의 데이터는 유지됩니다. 그러나 다음 상황에서는 인스턴스 저장소의 데이터가 손실됩니다.
+ 기본 드라이브 오류
+ 인스턴스가 중지됩니다.
+ 인스턴스가 종료됩니다.
그러므로 중요한 장기 데이터의 경우 인스턴스 저장소에 의존하지 마세요. 오히려 Amazon S3, Amazon EBS 또는 Amazon EFS 등 내구성이 뛰어난 데이터 스토리지를 사용하는 것이 좋습니다.
인스턴스 저장소 볼륨의 일반적인 전략은 목표 복구 시점(RPO) 및 목표 복구 시간(RTO)을 기반으로 필요에 따라 필요한 데이터를 Amazon S3에 정기적으로 보관하는 것입니다. 그러면 새 인스턴스가 시작될 때 Amazon S3에서 인스턴스 저장소로 데이터를 다운로드할 수 있습니다. 인스턴스가 중지되기 전에 Amazon S3에 데이터를 업로드할 수도 있습니다. 지속성을 위해 EBS 볼륨을 생성하여 인스턴스에 연결하고 인스턴스 저장소 볼륨의 데이터를 주기적으로 EBS 볼륨으로 복사하세요. 자세한 정보는 [AWS 지식 센터](https://aws.amazon.com/premiumsupport/knowledge-center/back-up-instance-store-ebs/)를 참조하세요.
## EBS 스냅샷 및 AMI에 대한 태그 지정 및 표준 적용
모든 AWS 리소스에 태그를 지정하는 것은 비용 할당, 감사, 문제 해결 및 알림에 중요한 관행입니다. EBS 볼륨에서는 볼륨을 관리하고 복원하는 데 필요한 관련 정보가 표시되도록 하기 위해 태그를 지정하는 것이 중요합니다. 태그는 EC2 인스턴스에서 AMI로 또는 소스 볼륨에서 스냅샷으로 자동으로 복사되지 않습니다. 백업 프로세스에 이러한 소스의 관련 태그가 포함되어 있는지 확인하세요. 그러면 액세스 정책, 연결 정보, 비용 할당 등의 스냅샷 메타데이터를 설정하여 나중에 이러한 백업을 사용하는 데 도움이 됩니다. AWS 리소스 태그 지정에 대한 자세한 내용은 [태그 지정 모범 사례 기술 문서를](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf) 참조하세요.
모든 AWS 리소스에 사용하는 태그 외에도 다음 백업별 태그를 사용합니다.
+ 소스 인스턴스 ID
+ 소스 볼륨 ID(스냅샷용)
+ 복구 시점 설명
AWS Config 규칙 및 IAM 권한을 사용하여 태그 지정 정책을 적용할 수 있습니다. IAM은 강제 태그 사용을 지원하므로 Amazon EBS 스냅샷에서 작업할 때 특정 태그의 사용을 의무화하는 IAM 정책을 작성할 수 있습니다. IAM 권한 정책에 정의된 태그에 권한을 부여하지 않고 `CreateSnapshot` 작업을 시도하면 액세스가 거부되면서 스냅샷 생성이 실패합니다. 자세한 내용은 [Amazon EBS 스냅샷 생성 시 태그 지정 및 더 강력한 보안 정책 구현에 관한 블로그 게시물](https://aws.amazon.com/blogs/compute/tag-amazon-ebs-snapshots-on-creation-and-implement-stronger-security-policies/)을 참조하세요.
AWS Config 규칙을 사용하여 리소스의 구성 설정을 자동으로 평가할 수 있습니다 AWS . 시작하는 데 도움이 되도록는 관리형 규칙이라고 하는 사용자 지정 가능한 사전 정의된 규칙을 AWS Config 제공합니다. 고유의 사용자 지정 규칙을 만들 수도 있습니다. 는 리소스 간의 구성 변경을 AWS Config 지속적으로 추적하지만 이러한 변경 사항이 규칙의 조건을 위반하는지 확인합니다. 리소스가 규칙을 위반하는 경우는 리소스와 규칙을 *규정 미준수*로 AWS Config 표시합니다. [필수 태그](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html) 관리형 규칙은 현재 스냅샷과 AMI를 지원하지 않습니다.
# AMI와 EBS 스냅샷을 사용하여 EBS 볼륨 백업 생성
AWS 는 AMIs 및 스냅샷을 생성하고 관리하기 위한 다양한 옵션을 제공합니다. 사용자는 필요에 맞는 접근 방식을 사용할 수 있습니다. 많은 고객이 직면하는 일반적인 문제는 스냅샷 수명 주기를 관리하고 용도, 보존 정책 등에 따라 스냅샷을 명확하게 정렬하는 것입니다. 적절한 태그를 지정하지 않으면 스냅샷이 실수로 또는 자동화된 클린업 프로세스의 일부로 삭제될 위험이 있습니다. 또한 더 이상 사용되지 않는 스냅샷이 여전히 필요한지 여부를 명확하게 파악할 수 없기 때문에 보관된 스냅샷에 대해 비용을 지불해야 할 수도 있습니다.
## 스냅샷 또는 AMI를 생성하기 전의 EBS 볼륨 준비
스냅샷을 만들거나 AMI를 생성하기 전에 EBS 볼륨에 필요한 준비를 하세요. AMI를 생성하면 인스턴스에 연결된 각 EBS 볼륨에 대한 새 스냅샷이 생성되므로 이러한 준비는 AMI에도 적용됩니다.
구동되는 EC2 인스턴스에서 사용 중인 연결된 EBS 볼륨의 스냅샷을 생성할 수 있습니다. 하지만 스냅샷은 snapshot 명령을 실행할 때 EBS 볼륨에 기록된 데이터만 캡처합니다. 이때 애플리케이션이나 운영 체제에 의해 캐시된 데이터가 제외될 수 있습니다. 시스템에서 I/O를 수행하지 않는 상태를 유지하는 것이 가장 좋습니다. 시스템이 트래픽을 수신하지 않고 중지된 상태에 있는 것이 이상적이지만, 연중무휴 IT 운영이 일반화되면서 이러한 경우는 드뭅니다. 시스템 메모리의 모든 데이터를 애플리케이션에서 사용 중인 디스크로 플러시하고 스냅샷을 만들기에 충분한 시간 동안 볼륨에 대한 파일 쓰기 작업을 일시 중지할 수 있는 경우 스냅샷이 완전해야 합니다.
클린 백업을 만들려면 데이터베이스 또는 파일 시스템을 중단해야 합니다. 이 작업을 수행하는 방법은 데이터베이스 또는 파일 시스템에 따라 다릅니다.
데이터베이스 프로세스는 다음과 같습니다.
1. 가능하면 데이터베이스를 핫 백업 모드로 전환합니다.
1. Amazon EBS 스냅샷 명령을 실행합니다.
1. 데이터베이스를 핫 백업 모드에서 해제하거나 읽기 전용 복제본을 사용하는 경우 읽기 전용 복제본 인스턴스를 종료합니다.
파일 시스템의 프로세스는 비슷하지만 운영 체제 또는 파일 시스템의 기능에 따라 다릅니다. 예를 들어, XFS는 일관적 백업을 위해 데이터를 플러시할 수 있는 파일 시스템입니다. 자세한 내용은 [xfs\$1freeze](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/xfsfreeze)를 참조하세요. 또는 I/O 정지를 지원하는 논리 볼륨 관리자를 사용하여 이 프로세스를 용이하게 할 수 있습니다.
하지만 볼륨에 대한 모든 파일 쓰기를 플러시하거나 일시 중지할 수 없는 경우 다음을 수행하세요.
1. 운영 체제에서의 볼륨 마운트를 해제합니다.
1. 스냅샷 명령을 실행합니다.
1. 일관되고 완전한 스냅샷을 만들려면 볼륨을 다시 마운트합니다. 스냅샷 상태가 대기 중인 상태에서 볼륨을 다시 마운트하고 사용할 수 있습니다.
스냅샷 프로세스는 배경에서 계속되며 스냅샷 생성은 빠르며 특정 시점을 캡처합니다. 백업하는 볼륨은 단 몇 초 만에 마운트 해제됩니다. 운영 중단이 예상되고 클라이언트가 정상적으로 처리하는 짧은 백업 기간을 예약할 수 있습니다.
루트 디바이스 역할을 하는 EBS 볼륨의 스냅샷을 생성할 때는 인스턴스를 중지한 후 스냅샷을 생성해야 합니다. Windows는 애플리케이션 일관성 스냅샷을 생성하는 데 도움이 되는 Volume Shadow Copy Service(VSS)를 제공합니다.는 VSS 인식 애플리케이션의 이미지 수준 백업을 수행하기 위해 실행할 수 있는 Systems Manager 문서를 AWS 제공합니다. 스냅샷에는 이러한 애플리케이션과 디스크 간에 대기 중인 트랜잭션의 데이터가 포함됩니다. 연결된 볼륨을 모두 백업하는 경우 인스턴스를 종료하거나 연결을 해제할 필요가 없습니다. 자세한 내용은 [AWS 설명서](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html)를 참조하십시오.
**참고**
다른 유사한 인스턴스를 배포할 수 있도록 Windows AMI를 생성하는 경우 [EC2Config 또는 EC2Launch](https://aws.amazon.com/premiumsupport/knowledge-center/sysprep-create-install-ec2-windows-amis/)를 사용하여 인스턴스를 [Sysprep](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--system-preparation--overview)하세요. 그런 다음, 중지된 인스턴스에서 AMI를 생성합니다. Sysprep은 SID, 컴퓨터 이름 및 드라이버 등의 Amazon EC2 Windows 인스턴스에서 고유한 정보를 제거합니다. SID가 중복되면 Active Directory, Windows 서버 업데이트 서비스(WSUS), 로그인 문제, Windows 볼륨 키 활성화, Microsoft Office 및 타사 제품에 문제가 발생할 수 있습니다. AMI가 백업용이고 모든 고유 정보를 그대로 유지한 상태로 동일한 인스턴스를 복원하려는 경우 인스턴스에 Sysprep을 사용하지 마세요.
## 콘솔에서 수동으로 EBS 볼륨 스냅샷 생성
인스턴스에서 완전히 테스트되지 않은 주요 변경 사항을 적용하기 전에 적절한 볼륨 또는 전체 인스턴스의 스냅샷을 생성하세요. 예를 들어, 인스턴스의 애플리케이션 또는 시스템 소프트웨어를 업그레이드하거나 패치를 적용하기 전에 스냅샷을 생성해야 합니다.
콘솔에서 수동으로 스냅샷을 생성할 수 있습니다. Amazon EC2 콘솔의 **Elastic Block Store 볼륨** 페이지에서 백업하려는 볼륨을 선택합니다. 그런 다음 **작업** 메뉴에서 **스냅샷 생성**을 선택합니다. 필터 상자에 인스턴스 ID를 입력하여 특정 인스턴스에 연결된 볼륨을 검색할 수 있습니다.
설명을 입력하고 적절한 태그를 추가합니다. 나중에 볼륨을 더 쉽게 찾을 수 있도록 `Name` 태그를 추가합니다. 태그 지정 전략에 따라 다른 적절한 태그를 추가합니다.
## AMI 생성
AMI는 인스턴스를 시작하는 데 필요한 정보를 제공합니다. AMI에는 이미지 생성 시 인스턴스에 연결된 EBS 볼륨의 루트 볼륨과 스냅샷이 포함됩니다. EBS 스냅샷만으로는 새 인스턴스를 시작할 수 없으며 AMI에서 새 인스턴스를 시작해야 합니다.
AMI를 생성하면 사용 중인 계정 및 리전에 생성됩니다. AMI 생성 프로세스는 인스턴스에 연결된 각 볼륨에 대해 Amazon EBS 스냅샷을 생성하고, AMI는 이러한 Amazon EBS 스냅샷을 참조합니다. 이러한 스냅샷은 Amazon S3에 있으며 내구성이 뛰어납니다.
EC2 인스턴스의 AMI를 생성한 후 이 AMI를 사용하여 인스턴스를 다시 생성하거나 인스턴스의 추가 사본을 시작할 수 있습니다. 애플리케이션 마이그레이션 또는 DR을 위해 한 리전에서 다른 리전으로 AMI를 복사할 수도 있습니다.
![\[이미지 생성, 인스턴스로 이미지 시작, 이미지 사본 생성.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/backup-recovery/images/ami-process.png)
VMWARE 가상 머신과 같은 가상 머신을 로 마이그레이션하지 않는 한 EC2 인스턴스에서 AMI를 생성해야 합니다 AWS. Amazon EC2 콘솔에서 AMI를 생성하려면 인스턴스를 선택하고 **작업**, **이미지**, **이미지 생성**을 차례로 선택합니다.
## Amazon Data Lifecycle Manager
[Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-lifecycle.html)를 사용하여 Amazon EBS 스냅샷의 생성, 보존 및 삭제를 자동화할 수 있습니다. 스냅샷 관리를 자동화하여 다음과 같은 이점을 누려 보세요.
+ 정기적인 백업 일정을 실행하여 중요한 데이터를 보호합니다.
+ 감사 기관이나 내부 규정 준수 부서에서 요구하는 백업을 보관합니다.
+ 오래된 백업을 삭제하여 스토리지 비용을 절감합니다.
Amazon Data Lifecycle Manager를 사용하면 EC2 인스턴스(및 연결된 EBS 볼륨) 또는 개별 EBS 볼륨에 대한 스냅샷 관리 프로세스를 자동화할 수 있습니다. 교차 리전 복사와 같은 옵션을 지원하므로 스냅샷을 다른 AWS 리전에 자동으로 복사할 수 있습니다. 대체 리전에 스냅샷을 복사하는 것은 대체 리전의 DR 노력과 복원 옵션을 지원하는 한 가지 방법입니다. 또한 Amazon Data Lifecycle Manager를 사용하여 [빠른 스냅샷 복원](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html)을 지원하는 스냅샷 수명 주기 정책을 생성할 수 있습니다.
Amazon Data Lifecycle Manager는 Amazon EC2와 Amazon EBS에 포함된 기능입니다. Amazon Data Lifecycle Manager에는 요금이 부과되지 않습니다.
## AWS Backup
AWS Backup 는 Amazon Data Lifecycle Manager에서 고유합니다. 여러 AWS 서비스의 리소스를 포함하는 백업 계획을 생성할 수 있기 때문입니다. 리소스 백업을 개별적으로 조정하는 대신 함께 사용하는 리소스를 포함하도록 백업을 조정할 수 있습니다.
AWS Backup 에는 완료된 백업의 복구 시점에 대한 액세스를 제한할 수 있는 백업 볼트 개념도 포함되어 있습니다. 각 개별 리소스로 진행하고 생성된 백업을 복원하는 AWS Backup 대신에서 복원 작업을 시작할 수 있습니다. AWS Backup 에는 감사 관리 및 보고와 같은 추가 기능도 포함되어 있습니다. 자세한 내용은 이 설명서의 [AWS Backup을 사용하여 백업 및 복구[AWS Backup을 사용하여 백업 및 복구](aws-backup.md)](aws-backup.md) 섹션을 참조하세요.
## 다중 볼륨 백업 수행
스냅샷을 사용하여 RAID 배열의 EBS 볼륨에 데이터를 백업하려는 경우 스냅샷이 일관되어야 합니다. 이러한 볼륨의 스냅샷은 독립적으로 생성되기 때문입니다. 동기화되지 않은 스냅샷을 사용하여 RAID 배열의 EBS 볼륨을 복원할 경우 배열의 무결성이 손상됩니다.
RAID 배열을 위한 일관된 스냅샷 세트를 생성하려면 [CreateSnapshots](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSnapshots.html) API 작업을 사용하거나 Amazon EC2 콘솔에 로그인하여 **Elastic Block Store**, **스냅샷**, **스냅샷 생성**을 선택합니다.
![\[다중 볼륨 스냅샷을 생성하기 위한 스냅샷 생성 화면.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/backup-recovery/images/multi-volume-snapshot.png)
RAID 구성에서 여러 볼륨이 연결된 인스턴스의 스냅샷은 일괄적으로 다중 볼륨 스냅샷으로 촬영됩니다. 다중 볼륨 스냅샷을 통해 EC2 인스턴스에 연결된 여러 EBS 볼륨에서 특정 시점, 데이터 조정 및 충돌 일치 스냅샷을 생성할 수 있습니다. 스냅샷은 여러 EBS 볼륨에서 자동으로 생성되기 때문에 일관성을 유지하기 위해 인스턴스를 중지하여 볼륨 간을 조정할 필요가 없습니다. 볼륨의 스냅샷이 시작된 후(보통 1\$12초) 파일 시스템은 작업을 계속할 수 있습니다.
스냅샷이 생성된 후 각 스냅샷은 개별 스냅샷으로 처리됩니다. 단일 볼륨 스냅샷과 마찬가지로, 복원, 삭제, 교차 리전 및 계정 복사 등의 모든 스냅샷 작업을 수행할 수 있습니다. 또한 단일 볼륨 스냅샷과 마찬가지로 다중 볼륨 스냅샷에도 태그를 지정할 수 있습니다. 복원, 복사 또는 보존 중에 한꺼번에 관리할 수 있도록 다중 볼륨 스냅샷에 태그를 지정하는 것이 좋습니다. 자세한 내용은 [AWS 설명서](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html)를 참조하세요.
논리 볼륨 관리자나 파일 시스템 수준 백업에서 이러한 백업을 수행할 수도 있습니다. 이러한 경우 기존 백업 에이전트를 사용하면 네트워크를 통해 데이터를 백업할 수 있습니다. 인터넷과 [AWS Marketplace](https://aws.amazon.com/marketplace/)에서 다양한 에이전트 기반 백업 솔루션을 사용할 수 있습니다.
또 다른 방법은 하나의 큰 볼륨에 있는 기본 시스템 볼륨의 복제본을 만드는 것입니다. 이렇게 하면 하나의 큰 볼륨만 백업해야 하고 기본 시스템에서는 백업이 수행되지 않으므로 백업 프로세스가 간소화됩니다. 그러나 먼저 단일 볼륨이 백업 중에 충분한 성능을 발휘할 수 있는지 여부와 최대 볼륨 크기가 애플리케이션에 적합한지 여부를 결정해야 합니다.
## Amazon EC2 백업 보호
백업의 보안을 고려하고 백업이 우발적이거나 악의적으로 삭제되는 것을 방지하는 것이 중요합니다. 여러 접근 방식을 일괄적으로 사용하여 이 작업을 수행할 수 있습니다. 보안 위반으로 인해 중요한 백업이 손실되는 것을 방지하려면 백업을 다른 AWS 계정에 복사하는 것이 좋습니다. AWS 계정이 여러 개인 경우 별도의 계정을 다른 모든 계정이 백업을 복사할 수 있는 아카이브 계정으로 지정할 수 있습니다. 예를 들어, [AWS Backup에서 계정 간 백업](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html)을 사용하여 이 작업을 수행할 수 있습니다.
재해 복구 계획에서는 리전별 장애 AWS 리전 발생 시 다른에서 EC2 인스턴스를 재현해야 할 수도 있습니다. 백업을 동일한 계정 내의 다른 리전에 복사하여 이 목표를 달성할 수 있습니다. 이렇게 하면 실수로 인한 삭제 방지 계층을 추가로 제공할 수 있을 뿐만 아니라 재해 복구(DR) 목표를 지원할 수 있습니다. AWS Backup 는 [교차 리전 백업](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html)을 지원합니다.
[ec2:DeleteSnapshot](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteSnapshot.html) 및 [ec2:DeregisterImage](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeregisterImage.html) 작업에 대한 IAM 권한을 차단하는 것을 고려해 보세요. 대신 보존 정책 및 메서드로 EBS 스냅샷과 Amazon EC2 AMI의 수명 주기를 관리하도록 할 수 있습니다. 삭제 작업을 차단하는 것은 EBS 스냅샷에 대한 WORM(Write-Once, Read-Many) 전략을 구현하는 한 가지 방법입니다. EBS 스냅샷 및 기타 AWS 리소스를 지원하는 [AWS Backup 볼트 잠금](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)을 사용할 수도 있습니다.
또한 [ec2:ModifyImageAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyImageAttribute.html) 및 [ec2:ModifySnapshotAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html) IAM 작업을 차단하여 사용자가 AMI와 EBS 스냅샷을 공유하는 기능을 차단하는 것도 고려해 보세요. 이렇게 AMIs 및 스냅샷이 조직 외부의 AWS 계정과 공유되지 않습니다. 를 사용하는 경우 사용자가 백업 볼트에서 유사한 작업을 수행하지 못하도록 AWS Backup제한합니다. 자세한 내용은 이 설명서의 [AWS Backup을 사용하여 백업 및 복구](aws-backup.md) 섹션을 참조하세요.
Amazon EBS에는 실수로 삭제된 EBS 스냅샷을 복원하는 데 도움이 되는 [휴지통 기능](https://docs.aws.amazon.com/ebs/latest/userguide/recycle-bin.html)이 포함되어 있습니다. 사용자가 스냅샷을 삭제하도록 허용하는 경우 필요한 스냅샷이 영구적으로 삭제되지 않도록 이 기능을 활성화하세요. Amazon EC2 콘솔에서는 한 번에 여러 스냅샷을 선택하여 삭제할 수 있으므로 사용자는 여러 스냅샷을 삭제할 때 특히 주의해야 합니다. 또한 클린업 스크립트와 자동화를 사용할 때는 필요한 스냅샷을 실수로 삭제하지 않도록 주의하세요. 휴지통 기능은 이러한 유형의 상황으로부터 보호하는 데 도움이 됩니다.
## EBS 스냅샷 아카이브
[EBS 스냅샷 아카이브](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html)는 90일 이상 복원할 계획이 없는 참조 목적으로 볼륨 사본을 보관하는 비용 효율적인 방법이 될 수 있습니다. 이는 EBS 볼륨의 모든 관련 스냅샷을 영구 삭제하기 전에 좋은 중간 단계가 될 수 있습니다. 예를 들어, 더 이상 사용되지 않는 EBS 볼륨의 수명 주기 종료 단계로 스냅샷 아카이브를 고려할 수 있습니다. 삭제보다는 아카이브하는 것이 휴지통을 사용하는 것보다 더 비용 효율적인 삭제 보존 방법일 수도 있습니다.
## Systems Manager, 및 AWS SDKs를 사용하여 스냅샷 AWS CLI및 AMI 생성 자동화
백업 접근 방식에는 스냅샷 또는 AMI를 생성하기 전후에 작업이 필요할 수 있습니다. 예를 들어, 파일 시스템을 중단하려면 서비스를 중지한 후 다시 시작해야 할 수 있습니다. 또는 AMI 생성 중에 인스턴스를 중지한 후 다시 시작해야 할 수도 있습니다. 또한 아키텍처에 있는 여러 구성 요소의 백업을 일괄적으로 생성해야 할 수도 있으며, 각 구성 요소에는 별도의 사전 생성 및 사후 생성 단계가 있습니다.
프로세스를 자동화하고 백업 프로세스가 일관되게 적용되는지 확인하여 백업의 유지 관리 기간을 줄일 수 있습니다. 사용자 지정 사전 생성 및 사후 생성 작업을 자동화하려면 AWS CLI 및 SDK를 사용하여 백업 프로세스를 스크립팅합니다.
자동화는 요청 시 또는 Systems Manager 유지 관리 기간 중에 실행할 수 있는 Systems Manager 런북에서 정의할 수 있습니다. Amazon EC2를 방해하는 명령에 대한 권한을 부여할 필요 없이 사용자에게 Systems Manager 런북을 실행할 수 있는 액세스 권한을 부여할 수 있습니다. 또한 이를 통해 백업 프로세스와 태그가 사용자에 의해 일관되게 적용되는지 확인할 수 있습니다. [AWS-CreateSnapshot](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-createsnapshot.html) 및 [AWS-CreateImage](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-createimage.html) 런북을 사용하여 스냅샷 및 AMIs를 생성하거나 다른 사용자에게 사용할 수 있는 권한을 부여할 수 있습니다. Systems Manager에는 AMI 패치 및 AMI 생성을 자동화하기 위한 [AWS-UpdateLinuxAmi](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-updatelinuxami.html) 및 [AWS-UpdateWindowsAmi](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-updatewindowsami.html) 런북도 포함되어 있습니다.
AWS CLI 및를 사용하여 스냅샷 및 AMI 생성 프로세스를 자동화[AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/)할 수도 있습니다. [aws ec2 create-snapshot](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-snapshot.html) AWS CLI 명령을 사용하여 자동화의 한 단계로 EBS 볼륨의 스냅샷을 생성할 수 있습니다. [aws ec2 create-snapshots](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-snapshots.html) 명령을 사용하여 EC2 인스턴스에 연결된 모든 볼륨의 충돌 시에도 일관되고 동기화된 스냅샷을 생성할 수 있습니다.
AWS CLI를 사용하여 새 AMIs. [aws ec2 register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) 명령을 사용하여 EC2 인스턴스용 새 이미지를 생성할 수 있습니다. [인스턴스의 종료, 이미지 생성 및 재시작을 자동화하려면 이 명령을 [aws ec2 stop-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/stop-instances.html) 및 aws ec2 start-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/start-instances.html) 명령과 함께 사용하세요.
# Amazon EBS 볼륨 또는 EC2 인스턴스 복원
EC2 인스턴스에 연결된 단일 볼륨만 복원해야 하는 경우 해당 볼륨을 별도로 복원하고 기존 볼륨을 분리한 다음 복원된 볼륨을 EC2 인스턴스에 연결할 수 있습니다. 모든 관련 볼륨을 포함하여 전체 EC2 인스턴스를 복원해야 하는 경우 인스턴스의 Amazon Machine Image(AMI) 백업을 사용해야 합니다.
복구 시간을 줄이고 종속 애플리케이션 및 프로세스에 미치는 영향을 줄이려면 복원 프로세스에서 대체하는 리소스를 고려해야 합니다. 최상의 결과를 얻으려면 낮은 환경(예: 비 프로덕션 환경)에서 정기적으로 복원 프로세스를 테스트하여 프로세스가 목표 복구 시점(RPO) 및 목표 복구 시간(RTO)을 충족하는지와 복원 프로세스가 예상대로 작동하는지 확인하세요. 복원 프로세스가 복원 중인 인스턴스에 의존하는 애플리케이션과 서비스에 어떤 영향을 미칠지 생각해 본 다음 필요에 따라 복원을 조정하세요. 복원 프로세스를 최대한 자동화하고 테스트하여 복원 프로세스가 실패하거나 일관되지 않게 구현될 위험을 줄이세요.
트래픽을 처리하는 여러 인스턴스와 함께 Elastic Load Balancing을 사용하는 경우 장애가 발생하거나 손상된 인스턴스의 서비스 중단시킬 수 있습니다. 그러면 다른 인스턴스가 사용자에게 영향을 주지 않고 트래픽을 계속 서비스하는 동안 새 인스턴스를 복원하여 이를 대체할 수 있습니다.
설명된 다음 복원 프로세스는 Elastic Load Balancing을 사용하지 않는 인스턴스를 위한 것입니다.
+ EBS 스냅샷에서 개별 파일 및 디렉터리 복원
+ Amazon EBS 스냅샷에서 EBS 볼륨 복원
+ EBS 스냅샷에서 EC2 인스턴스 생성 또는 복원
+ AMI에서 실행 중인 인스턴스 복원
## EBS 스냅샷에서 파일 및 디렉터리 복원
[EBS 스냅샷](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html)은 스냅샷을 생성하는 데 사용된 원본 볼륨의 정확한 특정 시점 복제본을 제공합니다. 개별 파일 또는 디렉터리를 복원하려면 다음을 수행해야 합니다.
1. [먼저, 파일 또는 디렉터리가 포함된 EBS 스냅샷에서 볼륨을 복원합니다.](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html#restore-snapshot)
1. 파일을 복원하려는 EC2 인스턴스에 볼륨을 연결합니다.
1. 복원된 볼륨의 파일을 EC2 인스턴스 볼륨으로 복사합니다.
1. 복원된 볼륨을 분리하고 삭제합니다.
## Amazon EBS 스냅샷에서 EBS 볼륨 복원
스냅샷에서 볼륨을 생성하고 인스턴스에 연결하여 기존 EC2 인스턴스에 연결된 볼륨을 복원할 수 있습니다. 콘솔, AWS CLI또는 API 작업을 사용하여 기존 스냅샷에서 볼륨을 생성할 수 있습니다. 그런 다음 운영 체제를 사용하여 인스턴스에 볼륨을 마운트할 수 있습니다.
Amazon EBS 스냅샷의 데이터는 비동기적으로 EBS 볼륨에 로드된다는 점에 유의하세요. 애플리케이션이 데이터가 로드되지 않는 볼륨에 액세스하는 경우 Amazon S3에서 데이터를 로드하는 동안 지연 시간이 평소보다 길어집니다. 지연 시간에 민감한 애플리케이션에 이러한 영향을 미치지 않도록 하려면 다음 두 가지 옵션이 있습니다.
+ [EBS 볼륨을 초기화](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-initialize.html)할 수 있습니다.
+ Amazon EBS는 추가 비용을 지불하면 [빠른 스냅샷 복원](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html)을 지원하므로 볼륨을 초기화할 필요가 없습니다.
동일한 마운트 지점을 사용해야 하는 볼륨을 교체하는 경우, 새 볼륨을 제자리에 마운트할 수 있도록 해당 볼륨을 마운트 해제하세요. 볼륨을 마운트 해제하려면 먼저 해당 볼륨을 사용하는 모든 프로세스를 중지합니다. 루트 볼륨을 교체하는 경우 루트 볼륨을 분리하기 전에 인스턴스를 먼저 중지해야 합니다.
예를 들어, 콘솔을 사용하여 볼륨을 이전 특정 시점 백업으로 복원하려면 다음 단계를 따르세요.
1. Amazon EC2 콘솔의 **Elastic Block Store** 메뉴에서 **스냅샷**을 선택합니다.
1. 복원할 스냅샷을 검색하고 선택합니다.
1. **작업**, **볼륨 생성**을 차례대로 선택합니다.
1. EC2 인스턴스와 동일한 가용 영역에서 새 볼륨을 생성합니다.
1. Amazon EC2 콘솔에서 인스턴스를 선택합니다.
1. 인스턴스 세부 정보에서 **루트 디바이스** 항목 또는 **블록 디바이스** 항목의 교체하려는 디바이스 이름을 기록해 둡니다.
1. 볼륨을 연결합니다. 프로세스는 루트 볼륨과 비루트 볼륨에 따라 다릅니다.
루트 볼륨의 경우:
1. EC2 인스턴스를 중지합니다.
1. **EC2 Elastic Block Store 볼륨** 메뉴에서 교체하려는 루트 볼륨을 선택합니다.
1. **작업**을 선택한 후 **볼륨 분리**를 선택합니다.
1. **EC2 Elastic Block Store 볼륨** 메뉴에서 새 볼륨을 선택합니다.
1. **작업**을 선택한 후 **볼륨 연결**을 선택합니다.
1. 볼륨을 연결할 인스턴스를 선택하고 앞서 언급한 것과 동일한 디바이스 이름을 사용합니다.
비루트 볼륨의 경우:
1. **EC2 Elastic Block Store 볼륨** 메뉴에서 교체하려는 비루트 볼륨을 선택합니다.
1. **작업**을 선택한 후 **볼륨 분리**를 선택합니다.
1. **EC2 Elastic Block Store 볼륨** 메뉴에서 새 볼륨을 선택한 다음 **작업**, **볼륨 연결**을 선택하여 새 볼륨을 연결합니다. 연결할 인스턴스를 선택한 다음 사용 가능한 디바이스 이름을 선택합니다.
1. 인스턴스의 운영 체제를 사용하여 기존 볼륨을 마운트 해제한 다음 새 볼륨을 제자리에 마운트합니다.
Linux에서 `umount` 명령을 사용할 수 있습니다. Windows에서는 디스크 관리 시스템 유틸리티와 같은 LVM(논리 볼륨 관리자)을 사용할 수 있습니다.
1. **EC2 Elastic Block Store 볼륨** 메뉴에서 이전 볼륨을 선택한 다음 **작업**, **볼륨 분리**를 선택하여 교체할 이전 볼륨을 분리합니다.
를 운영 체제 명령과 AWS CLI 함께 사용하여 이러한 단계를 자동화할 수도 있습니다.
## EBS 스냅샷에서 EC2 인스턴스 생성 또는 복원
전체 EC2 인스턴스를 복원하는 데 사용할 백업을 생성하려면 Amazon Machine Image(AMI)를 생성하는 것이 좋습니다. AMI는 가상화 유형과 같은 머신 정보를 캡처합니다. 또한 디바이스 매핑을 포함하여 EC2 인스턴스에 연결된 각 볼륨에 대한 스냅샷을 생성하므로 동일한 구성으로 복원할 수 있습니다.
**참고**
대부분의 경우 Windows, Red Hat, SUSE 및 SQL Server용 AMI를 사용하려면 AMI에 올바른 라이선스 정보가 있어야 합니다. 자세한 내용은 [AMI 청구 정보 이해](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-billing-info.html)를 참조하세요. 스냅샷에서 AMI를 생성할 때 `RegisterImage` 작업은 스냅샷의 메타데이터에서 올바른 결제 정보를 가져오지만, 이를 위해서는 적절한 메타데이터가 있어야 합니다. 올바른 결제 정보가 적용되었는지 확인하려면 새 AMI의 **플랫폼 세부 정보** 필드를 확인합니다. 필드가 비어 있거나 예상 운영 체제 코드(예: Windows, Red Hat, SUSE 또는 SQL)와 일치하지 않는 경우 AMI 생성에 실패한 것이므로 AMI를 삭제하고 [인스턴스에서 AMI 생성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami)의 지침을 따라야 합니다.
EBS 스냅샷을 사용하여 인스턴스를 복원해야 하는 경우 먼저 새 EC2 인스턴스의 루트 볼륨이 될 EBS 스냅샷에서 AMI를 생성하세요.
1. Amazon EC2 콘솔의 **Elastic Block Store** 메뉴에서 **스냅샷**을 선택합니다.
1. 새 EC2 인스턴스의 루트 볼륨을 생성하는 데 사용할 스냅샷을 검색하고 선택합니다.
1. **작업**을 선택한 후 **스냅샷에서 이미지 생성**을 선택합니다.
1. 이미지 이름(예:`YYYYMMDD-restore-for-i-012345678998765de`)을 입력하고 새 이미지에 적합한 옵션을 선택합니다.
1. (Windows, Red Hat, SUSE, SQL Server 전용) 올바른 결제 정보가 적용되었는지 확인하려면 새 AMI의 **플랫폼 세부 정보** 필드를 확인합니다. 필드가 비어 있거나 예상 운영 체제 코드(예: **Windows** 또는 **Red Hat**)와 일치하지 않는 경우 AMI 생성에 실패한 것이므로 AMI를 삭제하고 [인스턴스에서 AMI 생성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami)의 지침을 따라야 합니다.
이미지를 생성하여 사용할 수 있게 되면 해당 EBS 스냅샷을 루트 볼륨에 사용할 새 EC2 인스턴스를 시작할 수 있습니다.
## AMI에서 실행 중인 인스턴스 복원
AMI 백업에서 새 인스턴스를 가져와서 실행 중인 기존 인스턴스를 대체할 수 있습니다. 한 가지 접근 방식은 기존 인스턴스를 중지하고 AMI에서 새 인스턴스를 시작하는 동안 오프라인 상태로 유지하면서 필요한 업데이트를 수행하는 것입니다. 이러한 접근 방식을 사용하면 두 인스턴스가 동시에 실행될 때 충돌이 발생할 위험이 줄어듭니다. 인스턴스가 제공하는 서비스가 중단되거나 유지 관리 기간 중에 복원을 수행하는 경우 적합한 접근 방식입니다. 새 인스턴스를 테스트한 후 이전 인스턴스에 할당되었던 탄력적 IP 주소를 재할당할 수 있습니다. 그런 다음 새 인스턴스를 가리키도록 모든 도메인 이름 시스템(DNS) 레코드를 업데이트할 수 있습니다.
그러나 복원 중에 서비스 중인 인스턴스의 가동 중지 시간을 최소화해야 하는 경우 AMI 백업에서 새 인스턴스를 시작하고 테스트해 보세요. 그런 다음 기존 인스턴스를 새 인스턴스로 교체합니다.
두 인스턴스가 모두 실행 중일 때는 새 인스턴스가 플랫폼 수준 또는 애플리케이션 수준 충돌을 일으키지 않도록 해야 합니다. 예를 들어, 동일한 SID와 컴퓨터 이름으로 실행되는 도메인에 가입된 Windows 인스턴스에서 문제가 발생할 수 있습니다. 고유 식별자가 필요한 네트워크 애플리케이션 및 서비스에서도 비슷한 문제가 발생할 수 있습니다.
준비가 되기 전에 다른 서버 및 서비스가 새 인스턴스에 연결하지 못하도록 하려면 보안 그룹을 사용하여 액세스 및 테스트용 자체 IP 주소를 제외한 새 인스턴스의 모든 인바운드 연결을 일시적으로 차단하세요. 또한 새 인스턴스의 아웃바운드 연결을 일시적으로 차단하여 서비스와 애플리케이션이 다른 리소스에 대한 연결이나 업데이트를 시작하지 못하게 할 수 있습니다. 새 인스턴스가 준비되면 기존 인스턴스를 중지하고 새 인스턴스에서 서비스와 프로세스를 시작한 다음 구현한 인바운드 또는 아웃바운드 네트워크 연결의 차단을 해제하세요.