ArcGIS Enterprise 배포가 복잡해짐에 따라 재해 복구와 관련하여 추가로 검토해야 합니다. 이러한 검토 사항에는 배포 아키텍처를 형성하는 서로 다른 시스템에 대한 인사이트가 필요합니다. 많은 기술 시나리오에서와 마찬가지로 배포 시 핵심 및 종속 시스템을 모두 백업할 수 있는 접근 방식은 없습니다.
다음은 재해 복구 이벤트 중 복원 성공률을 높이기 위한 프레임워크를 제공합니다. 기관은 이러한 모범 사례를 채택하여 ArcGIS Enterprise 배포 시 재해가 발생할 경우 비즈니스 연속성/재해 복구(BC/DR) 계획의 일부로 표준 운영 절차를 정의할 수 있습니다.
백업 생성에 대한 모범 사례
ArcGIS Enterprise 기관 및 참조된 데이터 원본의 백업을 생성하기 위한 다음 모범 사례를 검토합니다.
ArcGIS Enterprise 백업
ArcGIS Enterprise 기관은 Portal for ArcGIS 사이트, 페더레이션된 모든 ArcGIS Server 사이트 및 관련 데이터, ArcGIS Data Store에 포함된 데이터로 구성됩니다. 컴포넌트는 포함된 웹 GIS 재해 복구(WebGISDR) 도구를 사용하거나 머신 기반 및 이미지 기반 백업을 위한 서드 파티 도구를 사용하여 백업할 수 있습니다.
WebGISDR 도구는 Portal for ArcGIS에 포함된 명령줄 유틸리티로, 기관의 콘텐츠 및 데이터, 페더레이션된 ArcGIS Server 사이트 정보, 관계형 타일 캐시 데이터 저장소에 포함된 데이터를 백업하는 데 사용됩니다. 이 도구는 복구를 수행하기 위해 기능적 배포가 필요하지만 기본 배포의 컴포넌트 및 페더레이션된 추가 사이트의 일관성을 유지하는 데 특히 유용합니다.
WebGISDR 백업 프로세스 이외에 검토해야 할 사항은 다음과 같습니다.
- 페더레이션된 ArcGIS Mission Server 또는 ArcGIS Notebook Server 사이트 - 이 중 하나가 포함된 경우 ArcGIS Mission Server 문서 및 ArcGIS Notebook Server 문서의 지침에 따라 백업을 생성합니다.
- 시공간 빅데이터 스토어, 그래프 스토어, 오브젝트 스토어 백업 — 호스팅 서버에 ArcGIS Data Store 유형 중 하나라도 등록된 경우 ArcGIS Data Store backupdatastore 유틸리티를 사용하여 각각의 백업을 생성합니다.
- ArcGIS GeoEvent Server 사이트 구성 - 백업 구성 파일을 사용하여 ArcGIS GeoEvent Server 구성 백업을 관리합니다.
대부분의 가상화 플랫폼에서는 실행 중인 가상 머신의 스냅샷을 찍어 복구 시간을 단축할 수 있습니다. 이는 유용하기는 하지만 대규모 BC/DR 계획의 일부로 영구 백업으로 간주되지 않습니다.
유지관리 기간 전이나 기간 중에 백업하는 경우 스냅샷을 통한 복구 시간 단축은 사용 가능한 경우 해당 도구를 사용하도록 합니다. 서드 파티 백업을 수행하는 경우 Portal for ArcGIS 및 ArcGIS Data Store의 기본 데이터 계층 컴포넌트는 이러한 방법과 통합되지 않으므로 실행 중인 데이터베이스의 실시간 백업을 수행하는 것과 관련된 위험 수준이 수반됩니다. 이러한 위험을 최소화하려면 실행 중인 ArcGIS Enterprise 컴포넌트에 대한 서비스를 중지한 후 스냅샷 및 이미지 기반 백업을 수행해야 합니다.
파일 공유를 사용하여 ArcGIS Server 사이트에 대한 공유 포털 콘텐츠 디렉터리 또는 구성 저장소 및 루트 디렉터리를 호스팅하는 아키텍처의 경우, 가상 머신 스냅샷 또는 이미지 기반 백업과 같은 서드 파티 백업 도구를 사용할 때 해당 위치의 백업 일관성을 검토하는 것이 중요합니다. 예를 들어 관리자가 스냅샷을 복구하여 Portal for ArcGIS 업그레이드에 실패한 후에 롤백하는 경우, 콘텐츠 디렉터리가 업그레이드 프로세스에 의해 변경되었을 수 있으며 더 이상 복구된 인스턴스의 데이터베이스에 포함된 정보와 일치하지 않을 수 있습니다. 서드 파티 도구를 사용할 때 이러한 영향을 최소화하려면 기관 내에서 콘텐츠가 발행되거나 편집되지 않는 중단 기간 동안 백업을 수행해야 합니다. 여기에는 ArcGIS Enterprise 컴포넌트 및 연관된 파일 공유가 모두 포함됩니다.
ArcGIS Data Store는 다른 컴포넌트와 별도로 백업하여 해당 컴포넌트에 오류가 발생한 경우 데이터 손실을 최소화할 수 있습니다. 관계형 타일 캐시 데이터 저장소의 예약된 백업 실행은 WebGISDR 유틸리티 및 기타 백업 도구의 일정을 벗어나 발생할 수 있습니다.
참조된 데이터 원본 백업
ArcGIS Server는 엔터프라이즈 지오데이터베이스, 등록된 파일 공유, 클라우드 저장소를 포함한 다양한 원본의 콘텐츠를 제공할 수 있습니다. 이러한 외부 데이터 원본은 배포를 위한 재해 복구 계획에 포함되어야 합니다. 백업을 수행하거나 데이터를 다른 위치로 복제하는 경우 공급업체 지침을 따르는 것을 권장합니다.
참조된 서비스에서 제공하는 데이터가 포함된 엔터프라이즈 지오데이터베이스 및 관계형 데이터베이스는 관계형 데이터베이스 공급업체에서 제공한 도구를 사용하여 각 기관의 복구 지점 목표에 따라 백업해야 합니다. 이 데이터는 ArcGIS Server 서비스에서 참조하기 때문에 발행된 서비스가 포함된 사이트와 별도로 데이터베이스 복구를 수행하는 경우 발행된 서비스의 일관성이 백엔드 데이터베이스 테이블과 동기화되지 않을 수 있습니다. 따라서 ArcGIS Enterprise 배포의 모든 컴포넌트에서 백업 일정을 조정하는 것이 중요합니다.
네트워크 파일 공유는 이미지 기반 또는 파일 시스템 기반 백업 도구를 사용하여 데이터를 패키징한 다음 배포의 오류 도메인 외부에 존재하는 영구 스토리지 솔루션으로 전송할 수 있습니다.
클라우드 스토어는 콘텐츠를 복구할 수 있도록 다른 영역에 백업하거나 복제해야 합니다. 복제된 저장소는 아카이브 또는 콜드 저장소를 통해 배포하여 전체 비용을 절감할 수도 있습니다.
백업 시기
백업을 수행하는 빈도는 여러 요인에 따라 달라지며, 그중 가장 중요한 것은 백업을 완료하는 데 소요되는 시간입니다. 백업 프로세스는 시스템 리소스 활용에 영향을 미칠 수 있으므로 전체 백업은 일반적으로 주요 업무 시간 외에 예약됩니다. 다양한 백업 유형의 경우, 시스템의 백업 빈도는 ArcGIS Enterprise 배포에 따라 달라질 수 있습니다.
예를 들어, 프로덕션 엔터프라이즈 지오데이터베이스는 복구 지점을 낮추기 위해 15분마다 증분 백업될 수 있습니다. 잠재적인 데이터 손실량을 줄이기 위해 가장 중요한 데이터는 데이터베이스 인스턴스에 저장해야 합니다. 참조된 서비스 및 정적 콘텐츠가 많은 ArcGIS Enterprise 배포의 경우 백업을 수행할 수 있는 빈도는 매일 또는 매주일 수 있지만, 호스팅 피처 서비스를 많이 활용하고 웹 맵 및 응용프로그램을 자주 생성하는 배포의 경우 백업 간격을 단축해야 합니다.
백업 유효성 검사
백업이 완료되었는지 모니터링하고 오류가 발생한 경우 관리자에게 알려야 합니다. WebGISDR 도구의 경우 스크립트 실행의 종료 코드를 백업이 완료되었는지 여부를 측정하는 데 사용할 수 있습니다. 0은 성공적인 백업을 나타내며 0이 아닌 코드는 실패를 나타냅니다. 백업 무결성을 담당하는 팀에 이메일 또는 SMS 알림을 허용하기 위해 통합할 수 있는 몇 가지 알림 도구가 제공됩니다. 많은 서드 파티 백업 도구는 유사한 기능을 제공하거나 알림을 제공하기 위해 다른 서비스와 통합될 수 있습니다.
기관의 BC/DR 계획을 검증하는 또 다른 중요한 측면은 반정기적인 간격으로 복원 훈련을 실행하는 것입니다. 이를 통해 관리자는 재해 발생 시 기능 백업에서 복원할 준비가 되어 있는지 확인하고 아래에 설명된 복원 계획을 검증할 수 있습니다.
백업 파일 보관 기간
백업 파일 보관 기간은 남아 있는 디스크 여유 공간과 복원 방법에 필요한 유연성에 따라 다릅니다. 마지막 전체 백업 이전 시간으로 복원해야 할 필요가 없다면 마지막 전체 백업과 그때부터 생성된 증분 백업을 보관할 수 있습니다.
WebGISDR 도구로 생성된 증분 백업은 누적되므로 최신 증분 백업을 마지막 전체 백업에 적용할 수 있습니다. 따라서 최소한, 마지막 전체 백업과 해당 전체 백업 시점부터 생성된 최신 증분 백업은 보관해야 합니다.
몇몇 이전 백업 집합을 저장 미디어 등의 다른 위치에 옮길 수도 있습니다. 이렇게 하면 마지막 전체 백업 전에 중요한 데이터 및 서비스가 삭제되었더라도 해당 파일을 계속 유지할 수 있습니다.
비고:
WebGISDR 유틸리티는 백업 생성 시 ArcGIS Enterprise 컴포넌트의 소프트웨어 버전을 기록합니다. 복원될 배포는 백업이 생성되었을 때와 동일한 버전이어야 합니다. 또한 동일한 운영 체제로 복원해야 합니다. 예를 들어 Linux에서 ArcGIS Enterprise 배포의 백업을 생성하여 Windows 머신에 복원할 수 없습니다.
기관 복원을 위한 모범 사례
생성한 백업을 통해 ArcGIS Enterprise 기관을 복원하기 위한 다음 모범 사례를 검토합니다.
복원할 항목
관리자가 여러 백업 유형을 사용할 수 있는 경우 전체 배포를 되돌리는 것보다 더 세분화된 방식으로 컴포넌트를 복원할 수 있습니다. 맵 또는 이미지 서비스의 캐시가 삭제된 경우에는 백업에서 해당 파일만 복구하면 됩니다. 마찬가지로 테이블이 엔터프라이즈 지오데이터베이스에서 실수로 삭제된 경우에는 다른 컴포넌트에 영향을 미치지 않고 해당 데이터베이스를 복구할 수 있습니다.
호스팅 피처 레이어를 잘못 편집하여 데이터를 롤백해야 하는 경우 관리자는 전체 ArcGIS Enterprise 배포를 복원하지 않고 관계형 데이터 저장소만 복원할 수 있습니다. 그러면 복원이 데이터베이스 내에 저장된 다른 데이터에 미치는 영향이 줄어들지만 해당 시간 동안 호스팅 서비스가 생성된 경우 ArcGIS Server 사이트가 복원된 데이터베이스 테이블과 일치하지 않고 영향을 받는 서비스를 수동으로 정리 및 다시 발행해야 할 수 있습니다.
다른 경우, 데이터 센터 또는 클라우드 영역 등에 심각한 중단이 발생하여 전체 ArcGIS Enterprise 배포 및 외부 데이터 원본을 복원해야 할 수 있습니다. 이는 가장 극단적인 예시이며 복원된 환경의 완전한 기능을 보장하기 위한 적절한 계획이 필요합니다.
복원 방법
ArcGIS Enterprise 배포가 광범위하게 중단되는 경우 사용 가능한 백업 유형에 따라 여러 복구 옵션이 제공됩니다. WebGISDR 도구를 사용하여 근접 사이트로 복제하는 것은 배포 복구 시간을 단축하는 가장 중요한 방법이며, 회전 및 복원에 사용할 수 있는 콜드 대기 사이트를 통해 복구 드릴을 용이하게 수행하고 전체 복구 시간을 단축할 수 있습니다.
복구 경로를 결정할 때는 복구 지점 및 시간이 가장 짧은 옵션을 먼저 시도해야 합니다. 그러면 복원 성공 수준에 대한 가장 빠른 피드백이 제공됩니다. 이전에 정기적으로 복원을 테스트하여 백업 전략에 익숙한 관리자가 있는 경우 재해 시나리오에서 복구하는 데 소요되는 시간도 단축할 수 있습니다.
ArcGIS Enterprise에는 내부 및 외부 컴포넌트 전체에 걸쳐 여러 계층이 있으므로 이러한 컴포넌트가 복원되는 순서는 복원 후 배포의 안정성에 영향을 미칩니다. ArcGIS Enterprise 머신 및 컴포넌트를 복원하기 전에 참조된 모든 데이터 원본을 먼저 사용할 수 있어야 하며 데이터베이스 인스턴스 및 외부 파일 공유를 포함하여 ArcGIS Enterprise 환경에서 접근할 수 있는지 확인해야 합니다.
주변 종속성이 설정되면 ArcGIS Enterprise 배포를 일관된 상태로 복원해야 합니다. 이는 호스팅 서버 사이트에 호스팅 피처 서비스가 발행되어 있지만 관계형 데이터 저장소에 종속 데이터 테이블이 누락되었거나 기관에 페더레이션 사이트 중 하나에 더 이상 존재하지 않는 서비스 항목이 있을 수 있는 시나리오를 피하기 위한 것입니다.
복원 후 유효성 검사
복원 작업이 완료되면 비즈니스 크리티컬 데이터 및 ArcGIS Enterprise 배포의 광범위한 기능에 대한 유효성 검사를 수행해야 합니다. 이는 비즈니스 센터 및 부서에서 가장 중요한 콘텐츠를 확인하기 위한 체크리스트를 생성하거나 자동화된 스크립팅을 통해 수행할 수 있습니다. 자동화된 스크립트를 사용하여 이러한 유효성 검사에 접근하면 항목 및 서비스를 수동으로 검증하는 것보다 신속하게 복원할 수 있습니다.
백업 및 복원 작업 자동화
심각한 데이터 손실을 방지하고 중단 시간을 줄이기 위해 백업을 정기적으로 생성하는 것을 권장합니다. 백업 생성 빈도는 허용되는 데이터 손실량을 정의하는 기관의 복구 지점 목표(RPO)에 따라 결정됩니다. 예를 들어 기관에서 12시간 이상의 데이터 손실을 허용할 수 없는 경우 12시간 미만의 간격으로 백업을 생성하는 일정을 정의합니다.
CronJob 또는 기타 예약 소프트웨어를 사용하여 Linux에서 백업 생성 및 복원을 자동화할 수 있습니다. 기관의 데이터 양이 백업을 생성할 수 있는 빈도 및 복원 속도에도 영향을 미칩니다. 다음 시도 전에 백업 또는 복원 작업이 완료되는지 확인하기 위해 예약된 작업을 설정하기 전에 소요 시간을 테스트할 수 있습니다.
또한 백업 또는 복원 작업이 성공했는지 확인해야 합니다. WebGISDR 도구는 작업 결과를 JSON으로 기록하는 결과 파일을 지원하며, 이를 구문 분석하여 백업 위치, 모든 컴포넌트의 실패 여부, 각 컴포넌트의 소요 시간을 확인할 수 있습니다. 해당 파일을 백업 및 복원 로직에 통합하여 관리자에게 오류 또는 작업 항목을 알릴 수 있습니다.