부록 C: 백업 및 복구

AWS에서의 장애 복구는 기존 호스팅 환경에 비해 더 신속하고 간편합니다. 예를 들어 하드웨어 장애에 대응하여 몇 분 만에 교체 인스턴스를 시작하거나, 여러 관리형 서비스에서 자동화된 장애 조치를 사용하여 일상적 유지 관리로 인한 재부팅의 영향을 배제할 수 있습니다.

그러나 데이터를 성공적으로 복구하려면 올바른 데이터를 백업하고 있어야 합니다. WordPress 웹 사이트의 가용성을 다시 설정하려면 다음 구성 요소를 복구할 수 있어야 합니다.

• 운영 체제(OS) 및 서비스 설치 및 구성(Apache, MySQL 등)

• WordPress 애플리케이션 코드 및 구성

• WordPress 테마 및 플러그 인

• 업로드(예: 게시물용 미디어 파일)

• 데이터베이스 콘텐츠(게시물, 댓글 등)

AWS는 웹 애플리케이션 데이터 및 자산을 백업하고 복원하는 다양한 방법을 제공합니다.

이 백서에서는 앞서 Lightsail 스냅샷을 사용하여 인스턴스의 로컬 스토리지에 저장된 모든 데이터를 보호하는 방법에 대해 설명했습니다. WordPress 웹 사이트가 Lightsail 인스턴스에서만 실행되는 경우 일반 Lightsail 스냅샷만으로도 WordPress 웹 사이트 전체를 복구할 수 있습니다. 그러나 스냅샷에서 복원하면 마지막 스냅샷을 만든 이후 웹 사이트에 적용된 변경 내용이 손실됩니다.

다중 서버 배포에서는 다른 메커니즘을 사용하여 앞서 설명한 각 구성 요소를 백업해야 합니다. 각 구성 요소마다 백업 빈도 요구 사항이 다를 수 있습니다. 예를 들어 OS 및 WordPress 설치 및 구성은 사용자 생성 콘텐츠보다 훨씬 덜 자주 변경되므로 백업 빈도가 낮아도 데이터 손실 없이 복구할 수가 있습니다

OS 및 서비스 설치 및 구성, WordPress 애플리케이션 코드 및 구성을 백업하기 위해 올바로 구성된 EC2 인스턴스의 AMI를 생성할 수 있습니다. AMI는 인스턴스 상태의 백업 역할과 새 인스턴스를 시작할 때 템플릿 역할을 하는 두 가지 용도로 사용될 수 있습니다.

WordPress 애플리케이션 코드 및 구성을 백업하려면 AMI 외에 Aurora 백업도 사용해야 합니다.

웹 사이트에 설치된 WordPress 테마 및 플러그 인을 백업하려면 해당 항목이 저장된 Amazon S3 버킷 또는 Amazon EFS 파일 시스템을 백업합니다.

• 테마 및 플러그 인이 S3 버킷에 저장된 경우 교차 리전 복제를 활성화하여 기본 버킷에 업로드된 모든 객체가 다른 AWS 리전의 백업 버킷에 자동으로 복제되도록 할 수 있습니다. 교차 리전 복제를 사용하려면 원본 및 대상 버킷 모두에서 버전 관리가 활성화되어야 합니다. 이는 추가로 보호 계층을 제공하며 버킷에 있는 객체를 이전 버전으로 되돌릴 수 있습니다.

• 테마 및 플러그 인이 EFS 파일 시스템에 저장된 경우 Amazon EFS 파일 시스템 백업 설명서 페이지에 설명된 대로 AWS Data Pipeline를 생성하여 프로덕션 EFS 파일 시스템에서 다른 EFS 파일 시스템으로 데이터를 복사할 수 있습니다. 이미 익숙한 백업 애플리케이션을 사용하여 EFS 파일 시스템을 백업할 수도 있습니다.

• 사용자 업로드를 백업하려면 앞서 설명한 WordPress 테마 및 플러그 인 백업 단계를 따라야 합니다.

• 데이터베이스 콘텐츠를 백업하려면 Aurora 백업을 사용해야 합니다. Aurora는 클러스터 볼륨을 자동으로 백업한 후 백업 보존 기간 동안 복구 데이터를 보관합니다. Aurora 백업은 지속적으로 누적되기 때문에 백업 보존 기간만 벗어나지 않는다면 어떤 시점으로든 신속히 복구할 수 있습니다. 백업 데이터를 쓰는 중에도 성능에 미치는 영향이나 데이터베이스 서비스 중단은 일어나지 않습니다. 백업 보존 기간은 1일에서 35일까지 지정할 수 있습니다. 스냅샷은 삭제할 때까지 유지되는 수동 데이터베이스 스냅샷을 생성할 수도 있습니다. 수동 데이터베이스 스냅샷은 장기 백업 및 아카이빙에 유용합니다.