위키원
"백업사이트"의 두 판 사이의 차이
| 1번째 줄: | 1번째 줄: | ||
| − | '''백업사이트'''<!--백업사이트, 백업 사이트-->(backup site)<!--(backup site, backupsite, Backup Site, BACKUP SITE, Backup site)-->는 지진, 홍수, 테러리스트의 | + | '''백업사이트'''<!--백업사이트, 백업 사이트-->(backup site)<!--(backup site, backupsite, Backup Site, BACKUP SITE, Backup site)-->는 지진, 홍수, 테러리스트의 공격과 같은 비상시를 위해 복제된 시스템의 예비 컴퓨터 등을 갖추어 놓은 곳을 말한다. 재해 복구 계획과 더 넓은 업무 연속성 계획의 중요한 부분이다. |
==개요== | ==개요== | ||
| − | + | 백업사이트 또는 작업 영역 복구 사이트는 화재, 홍수, 테러 위협 또는 기타 파괴적인 이벤트와 같은 재해 발생 후 조직이 이전할 수 있는 위치이다. 이는 재해 복구 계획의 필수적인 부분이며 조직의 광범위한 [[비즈니스 연속성]] 계획이다. 백업 또는 대체 사이트는 조직에서 운영하거나 재해 복구 서비스를 전문으로 하는 회사를 통해 계약된 다른 데이터센터 위치일 수 있다. 경우에 따라 한 조직에서 공동 백업사이트를 운영하기 위해 두 번째 조직과 계약을 체결한다. 또한 조직은 각 데이터 센터에 웜사이트를 설정하는 다른 조직과 상호 계약을 맺을 수 있다. [[콜드사이트]], [[웜사이트]] 및 [[핫사이트]]를 포함하여 세 가지 유형의 백업사이트가 있다. 형식 간의 차이점은 각 형식을 구현하는 데 필요한 비용과 노력에 의해 결정된다. | |
==특징== | ==특징== | ||
===데이터 백업 및 복구=== | ===데이터 백업 및 복구=== | ||
| − | 데이터 백업과 복구는 데이터 손실 발생 시 해당 데이터를 백업하고 보안 시스템을 설정하는 프로세스로, 결과적으로 데이터를 복구할 수 있게 | + | 데이터 백업과 복구는 데이터 손실 발생 시 해당 데이터를 백업하고 보안 시스템을 설정하는 프로세스로, 결과적으로 데이터를 복구할 수 있게 한다. 데이터 백업에는 데이터 손상 또는 삭제 시에도 데이터에 액세스할 수 있도록 시스템 데이터를 복사하여 아카이빙하는 것이 필요하다. 데이터를 백업한 경우 해당 시점의 데이터만 복구할 수 있다. 데이터 백업은 일종의 재해 복구로, 합리적인 재해 복구 계획의 중요한 부분을 구성한다. 데이터 백업이 항상 시스템의 모든 데이터와 설정을 복원할 수 있는 것은 아니다. 예를 들어, 시스템 클러스터나 데이터베이스 서버, 활성 디렉터리 서버의 경우 백업 및 복구로 이들을 완전히 재구성하지 못할 수 있으므로 다른 유형의 재해 복구를 추가해야 할 수 있다. 현재는 클라우드 스토리지를 사용하여 상당한 양의 데이터를 백업할 수 있으므로 로컬 시스템의 하드 드라이브나 외부 스토리지에 데이터를 아카이빙할 필요가 없다. 또한 클라우드 기술을 사용하여 모바일 디바이스를 설정해 자동으로 데이터가 복구되도록 할 수 있다. |
| − | 백업과 복구의 주된 차이점은 백업이 데이터베이스 장애 시 사용할 수 있는 원본 데이터의 카피본인 반면, 복구는 장애 발생 시 데이터베이스를 원래의 상태로 복원하는 프로세스를 | + | 백업과 복구의 주된 차이점은 백업이 데이터베이스 장애 시 사용할 수 있는 원본 데이터의 카피본인 반면, 복구는 장애 발생 시 데이터베이스를 원래의 상태로 복원하는 프로세스를 의미한다. 앞서 설명한 바와 같이 백업은 데이터의 대표 카피본을 가리키는 것으로, 데이터 파일과 제어 파일 같은 데이터베이스의 필수 요소가 여기에 포함된다. 예기치 않은 데이터베이스 고장을 피할 수 없기 때문에, 전체 데이터베이스 백업이 반드시 필요하다. 다음의 두 가지 주요 백업 유형이 있다. |
| − | * 물리적 백업 : 데이터, 제어 파일, 로그 파일, 아카이빙된 재실행 로그 등 실제 데이터베이스 파일의 카피본을 | + | * 물리적 백업 : 데이터, 제어 파일, 로그 파일, 아카이빙된 재실행 로그 등 실제 데이터베이스 파일의 카피본을 말한다. 다른 위치에 데이터베이스 정보를 저장하는 파일의 카피본으로, 데이터베이스 복구 메커니즘의 기초를 형성한다. |
| − | * 논리적 백업 : 여기에는 데이터베이스로부터 추출한 논리적 데이터가 포함되며 테이블, 프로시저, 뷰, 함수 등으로 | + | * 논리적 백업 : 여기에는 데이터베이스로부터 추출한 논리적 데이터가 포함되며 테이블, 프로시저, 뷰, 함수 등으로 구성된다. 하지만 논리적 백업만 유지하는 것은 구조적 정보만 제공한다는 점에서 권장되거나 유용하지 않을 수 있다. 반면, 복구는 장애 발생 시 온전한 상태로 데이터베이스를 복원하도록 돕는 역할을 한다. 갑작스런 장애 이후 데이터베이스를 일관된 상태로 복구할 수 있게 하므로 데이터베이스의 안정성을 향상시키는 것이다. 로그 기반 복구를 사용하여 데이터베이스를 온전히 복구할 수 있도록 한다. 로그는 트랜잭션 레코드가 포함된 레코드 시퀀스로, 안정적인 스토리지에 저장될 때 모든 트랜잭션을 기록한 로그를 통해 장애 이후 데이터베이스를 복구할 수 있게 된다. 여기에는 실행할 트랜잭션과 트랜잭션 상태, 수정된 값 등에 대한 정보가 포함된다. 이러한 정보는 모두 실행 순서에 따라 저장되어 있다.<ref>데이터 백업 및 복구: 기업을 위한 필수 가이드 베리타스 - https://www.veritas.com/ko/kr/information-center/data-backup-and-recovery</ref> |
===종류=== | ===종류=== | ||
| − | *''' | + | *'''[[콜드사이트]]'''(cold site) : 간단한 언어로, 콜드사이트는 고층, 에어컨, 전원 및 통신 라인 등과 같은 기본 시설이 있는 빈 운영 공간이다. 사고가 발생하고 운영이 약간의 가동 중지 시간으로 수행 할 수있는 경우 콜드사이트에 대체 시설을 가져와 운영을 재개한다. 콜드사이트는 조직이 작동할 수 있는 가장 비용이 많이 드는 유형의 백업사이트이다. 조직의 원래 위치에서 데이터 및 정보의 백업된 복사본을 포함하지 않으며 이미 설정된 하드웨어도 포함하지 않는다. [[프로비저닝]]된 하드웨어의 부족은 콜드사이트의 최소한의 시작 비용에 기여하지만 재해 발생 후 추가 시간이 필요하므로 재해 이전에 가까운 용량에서 작업을 실행해야 한다. 경우에 따라 냉장 사이트에는 장비를 사용할 수 있지만 작동하지 않는다. 콜드사이트의 장점은 간단하다. 재해 이전에 장비가 반입되지 않아 냉장 사이트를 운영하기 위해 더 적은 리소스가 필요하다. 일부 조직에서는 이전 버전의 하드웨어를 중앙에 저장할 수 있다. 이는 많은 경우에 오래된 하드웨어를 사용할 수 있는 서버 팜 환경에서 적합할 수 있다. 콜드사이트의 단점은 콜드사이트를 효과적으로 만들기 위해 발생해야 할 잠재적 비용이다. 매우 짧은 시간에 장비를 구입하는 비용이 높을 수 있으며 재해로 인해 장비를 얻기가 어려울 수 있다. 데이터만 원격지에 보관하고 서비스를 위한 정보 자원은 확보하지 않거나 장소 등 최소한으로만 확보하고 있다가 재해 시에 데이터를 근간으로 필요한 정보자원을 조달하여 복구하는 방식이다. 주 센터의 데이터는 주기적으로 원격지에 백업한다. 구축 및 유지보수 비용이 가장 저렴하나 복구 소요시간이 매우 길고 복구의 신뢰성이 낮다. |
| − | *''' | + | *'''[[핫사이트]]'''(Hot Site) : 핫사이트는 전체 컴퓨터 시스템과 사용자 데이터의 거의 완전한 백업이 있는 조직의 원래 사이트의 복제본이다. 두 사이트 간의 실시간 동기화는 광역 네트워크 링크 및 특수 소프트웨어를 사용하여 원래 사이트의 데이터 환경을 완전히 미러링하는 데 사용될 수 있다. 원래 사이트가 중단된 후 핫사이트가 존재하므로 조직이 최소한의 손실로 짧은 복구 시간에 정상 작업으로 이전할 수 있다. 이상적으로, 핫사이트는 몇 시간 이내에 실행된다. 인력은 핫사이트로 이동해야 할 수 있지만 직원이 이전하기 전에 핫사이트가 데이터 처리 관점에서 작동할 수 있다. 핫사이트의 용량은 조직의 요구 사항에 따라 원래 사이트의 용량과 일치하거나 일치하지 않을 수 있다. 이러한 유형의 백업사이트는 운영 비용이 가장 많이 든다. 핫사이트는 금융 기관, 정부 기관 및 전자 상거래 제공 업체와 같은 실시간 프로세스를 운영하는 조직에서 인기가 있다. 핫사이트에서 제공하는 가장 중요한 기능은 프로덕션 환경이 주 데이터 센터와 동시에 실행된다는 것이다. 이 동기화를 통해 비즈니스 운영에 미치는 영향과 가동 중지 시간을 최소화할 수 있다. 중대한 정전이 발생했을 때, 핫사이트는 즉시 영향을 받은 사이트를 대신할 수 있다. 그러나 이러한 중복 수준은 저렴하지 않으며 기업은 핫사이트 활용의 비용 이점 분석(CBA)을 고려해야 한다. 요즘 백업사이트가 다운되어 "사전 예방적" 접근방식을 놓치면 ISO 22301 접근방식(비즈니스 연속성 관리를 위한 국제표준)과 관련하여 조직의 성숙도 수준에 따라 핫사이트로 간주되지 않을 수 있다. 핫사이트는 전통적으로 콜드사이트보다 비싸다. 회사가 필요로 하는 장비의 대부분을 구입해야 하므로 사람들이 그것을 유지하기 위해 필요하기 때문에, 운영 비용을 더 높게 만들 수 있다. 그러나 동일한 조직이 비활성 상태로 매일 상당한 양의 수익을 잃는다면 비용이 들 수 있다. 핫사이트의 또 다른 장점은 재해가 발생하기 전에 작업에 사용할 수 있다는 것이다. 이 부하 균형 생산 처리 방법은 비용 효율적이며 데이터센터 중 하나에 영향을 미치는 이벤트 중에 최소한의 가동 중지 시간을 사용자에게 제공한다. 주 센터와 동일한 수준의 정보기술자원을 대기 상태(standard)로 사이트에 보유하면서, 동기적 또는 비동기적 방식으로 실시간 [[미러링]](mirroring)을 통하여 데이터를 최신으로 유지한다. 주 센터 재해 시 재해 복구 센터의 정보 시스템을 액티브로 전환하여 서비스하는 방식으로 재해 발생 시 복구까지의 소요시간(RTO)는 약 4시간 이내이다. 초기 투자 및 유지 보수에 높은 비용이 소모되며, 데이터베이스 애플리케이션 등 데이터의 업데이트 빈도가 높은 시스템의 경우 사용한다.<ref>고기는물풍선, 〈[https://m.blog.naver.com/kyeong477/221558199946 (정보보안기사)재해복구 시스템(백업 사이트)의 종류(미러 사이트, 핫 사이트, 웜 사이트, 콜드 사이트)]〉, 《네이버 블로그》, 2019-06-09</ref> |
| − | *''' | + | *'''[[웜사이트]]'''(Warm Site) : 콜드사이트와 핫사이트의 절충 사이트이다. 이 사이트들에는 하드웨어가 있고 연결이 이미 확립되어 있지만 원래의 생산 사이트나 핫 사이트보다도 규모가 작은 편이다. 웜사이트는 직접 백업본을 갖출 수 있으나 완전하지 못할 수도 있다.<ref>백업 사이트 위키백과 - https://ko.wikipedia.org/wiki/%EB%B0%B1%EC%97%85_%EC%82%AC%EC%9D%B4%ED%8A%B8</ref> 핫사이트와 유사하나 [[재해복구센터]]에 주 센터와 동일한 수준의 정보기술자원을 보유하는 대신 중요성이 높은 정보기술자원만 부분적으로 재해복구 센터에 보유하는 방식이다. 고가의 장비와 응용프로그램, 리얼 데이터(real data)를 제외한 시설과 장비 준비, 가장 널리 사용하는 모델이다. 실시간 미러링을 수행하지 않으며 데이터의 백업 주기가 수 시간~1일 정도로 핫사이트에 비해 다소 길다. |
| − | *''' | + | *'''[[미러사이트]]'''(mirror site) : 주 센터와 동인한 수준의 정보기술자원을 원격지에 구축하고, 메인센터 재해복구센터 모두 액티브 상태로 실시간 동시 서비스를 하는 방식이다. 재해 발생시 복구까지의 소요시간은 이론적으로 '0'이다. 초기 투자 및 유지 보수에 높은 비용이 소모되며, 웹 애플리케이션 서비스 등 데이터의 업데이트의 빈도가 높지 않은 시스템에 적용 가능하다.<ref>IT제이제이, 〈[https://jjinfotech.tistory.com/81 2차 사이트 종류별 특징]〉, 《티스토리》, 2018-09-06</ref> |
| − | *''' | + | *'''[[상업사이트]]''' : 백업사이트 기능의 상용 공급자로부터 서비스를 계약할 때 조직은 계약 사용 조항 및 호출 절차를 기록해야 한다. 공급자는 다양한 서비스 수준에 따라 지정된 사이트 또는 시설에 두 개 이상의 조직에 가입할 수 있다. 서비스를 사용하는 모든 조직이 동시에 서비스를 필요로 할 가능성이 낮으며 공급자가 저렴한 비용으로 서비스를 제공할 수 있기 때문에 합리적인 제안이다. 그러나 광역지역에 영향을 미치는 대규모 사고에서는 이러한 시설이 과도하게 가입될 가능성이 높다. 조직은 공급자에게 우선 서비스를 요청할 수 있으며, 종종 월 수수료가 더 높은 경우가 많다. 상용사이트는 기본 데이터센터에 대한 본격적인 미러링 환경을 갖춘 보조 프로덕션 사이트로도 사용할 수 있다. 다시 말하지만, 더 높은 수수료가 필요하지만 사이트의 보안과 조직의 데이터가 및 응용 프로그램에 대한 중단없이 액세스할 수 있는 능력은 비용을 정당화할 수 있다.<ref>Backup site 위키백과 - https://en.wikipedia.org/wiki/Backup_site</ref> |
{{각주}} | {{각주}} | ||
| 30번째 줄: | 30번째 줄: | ||
==같이 보기== | ==같이 보기== | ||
| − | * [[ | + | * [[백업]] |
| − | * [[ | + | * [[핫사이트]] |
| − | * [[ | + | * [[콜드사이트]] |
| − | * [[ | + | * [[웜사이트]] |
| + | * [[미러사이트]] | ||
{{하드웨어|검토 필요}} | {{하드웨어|검토 필요}} | ||
2020년 8월 10일 (월) 20:03 판
백업사이트(backup site)는 지진, 홍수, 테러리스트의 공격과 같은 비상시를 위해 복제된 시스템의 예비 컴퓨터 등을 갖추어 놓은 곳을 말한다. 재해 복구 계획과 더 넓은 업무 연속성 계획의 중요한 부분이다.
개요
백업사이트 또는 작업 영역 복구 사이트는 화재, 홍수, 테러 위협 또는 기타 파괴적인 이벤트와 같은 재해 발생 후 조직이 이전할 수 있는 위치이다. 이는 재해 복구 계획의 필수적인 부분이며 조직의 광범위한 비즈니스 연속성 계획이다. 백업 또는 대체 사이트는 조직에서 운영하거나 재해 복구 서비스를 전문으로 하는 회사를 통해 계약된 다른 데이터센터 위치일 수 있다. 경우에 따라 한 조직에서 공동 백업사이트를 운영하기 위해 두 번째 조직과 계약을 체결한다. 또한 조직은 각 데이터 센터에 웜사이트를 설정하는 다른 조직과 상호 계약을 맺을 수 있다. 콜드사이트, 웜사이트 및 핫사이트를 포함하여 세 가지 유형의 백업사이트가 있다. 형식 간의 차이점은 각 형식을 구현하는 데 필요한 비용과 노력에 의해 결정된다.
특징
데이터 백업 및 복구
데이터 백업과 복구는 데이터 손실 발생 시 해당 데이터를 백업하고 보안 시스템을 설정하는 프로세스로, 결과적으로 데이터를 복구할 수 있게 한다. 데이터 백업에는 데이터 손상 또는 삭제 시에도 데이터에 액세스할 수 있도록 시스템 데이터를 복사하여 아카이빙하는 것이 필요하다. 데이터를 백업한 경우 해당 시점의 데이터만 복구할 수 있다. 데이터 백업은 일종의 재해 복구로, 합리적인 재해 복구 계획의 중요한 부분을 구성한다. 데이터 백업이 항상 시스템의 모든 데이터와 설정을 복원할 수 있는 것은 아니다. 예를 들어, 시스템 클러스터나 데이터베이스 서버, 활성 디렉터리 서버의 경우 백업 및 복구로 이들을 완전히 재구성하지 못할 수 있으므로 다른 유형의 재해 복구를 추가해야 할 수 있다. 현재는 클라우드 스토리지를 사용하여 상당한 양의 데이터를 백업할 수 있으므로 로컬 시스템의 하드 드라이브나 외부 스토리지에 데이터를 아카이빙할 필요가 없다. 또한 클라우드 기술을 사용하여 모바일 디바이스를 설정해 자동으로 데이터가 복구되도록 할 수 있다.
백업과 복구의 주된 차이점은 백업이 데이터베이스 장애 시 사용할 수 있는 원본 데이터의 카피본인 반면, 복구는 장애 발생 시 데이터베이스를 원래의 상태로 복원하는 프로세스를 의미한다. 앞서 설명한 바와 같이 백업은 데이터의 대표 카피본을 가리키는 것으로, 데이터 파일과 제어 파일 같은 데이터베이스의 필수 요소가 여기에 포함된다. 예기치 않은 데이터베이스 고장을 피할 수 없기 때문에, 전체 데이터베이스 백업이 반드시 필요하다. 다음의 두 가지 주요 백업 유형이 있다.
- 물리적 백업 : 데이터, 제어 파일, 로그 파일, 아카이빙된 재실행 로그 등 실제 데이터베이스 파일의 카피본을 말한다. 다른 위치에 데이터베이스 정보를 저장하는 파일의 카피본으로, 데이터베이스 복구 메커니즘의 기초를 형성한다.
- 논리적 백업 : 여기에는 데이터베이스로부터 추출한 논리적 데이터가 포함되며 테이블, 프로시저, 뷰, 함수 등으로 구성된다. 하지만 논리적 백업만 유지하는 것은 구조적 정보만 제공한다는 점에서 권장되거나 유용하지 않을 수 있다. 반면, 복구는 장애 발생 시 온전한 상태로 데이터베이스를 복원하도록 돕는 역할을 한다. 갑작스런 장애 이후 데이터베이스를 일관된 상태로 복구할 수 있게 하므로 데이터베이스의 안정성을 향상시키는 것이다. 로그 기반 복구를 사용하여 데이터베이스를 온전히 복구할 수 있도록 한다. 로그는 트랜잭션 레코드가 포함된 레코드 시퀀스로, 안정적인 스토리지에 저장될 때 모든 트랜잭션을 기록한 로그를 통해 장애 이후 데이터베이스를 복구할 수 있게 된다. 여기에는 실행할 트랜잭션과 트랜잭션 상태, 수정된 값 등에 대한 정보가 포함된다. 이러한 정보는 모두 실행 순서에 따라 저장되어 있다.[1]
종류
- 콜드사이트(cold site) : 간단한 언어로, 콜드사이트는 고층, 에어컨, 전원 및 통신 라인 등과 같은 기본 시설이 있는 빈 운영 공간이다. 사고가 발생하고 운영이 약간의 가동 중지 시간으로 수행 할 수있는 경우 콜드사이트에 대체 시설을 가져와 운영을 재개한다. 콜드사이트는 조직이 작동할 수 있는 가장 비용이 많이 드는 유형의 백업사이트이다. 조직의 원래 위치에서 데이터 및 정보의 백업된 복사본을 포함하지 않으며 이미 설정된 하드웨어도 포함하지 않는다. 프로비저닝된 하드웨어의 부족은 콜드사이트의 최소한의 시작 비용에 기여하지만 재해 발생 후 추가 시간이 필요하므로 재해 이전에 가까운 용량에서 작업을 실행해야 한다. 경우에 따라 냉장 사이트에는 장비를 사용할 수 있지만 작동하지 않는다. 콜드사이트의 장점은 간단하다. 재해 이전에 장비가 반입되지 않아 냉장 사이트를 운영하기 위해 더 적은 리소스가 필요하다. 일부 조직에서는 이전 버전의 하드웨어를 중앙에 저장할 수 있다. 이는 많은 경우에 오래된 하드웨어를 사용할 수 있는 서버 팜 환경에서 적합할 수 있다. 콜드사이트의 단점은 콜드사이트를 효과적으로 만들기 위해 발생해야 할 잠재적 비용이다. 매우 짧은 시간에 장비를 구입하는 비용이 높을 수 있으며 재해로 인해 장비를 얻기가 어려울 수 있다. 데이터만 원격지에 보관하고 서비스를 위한 정보 자원은 확보하지 않거나 장소 등 최소한으로만 확보하고 있다가 재해 시에 데이터를 근간으로 필요한 정보자원을 조달하여 복구하는 방식이다. 주 센터의 데이터는 주기적으로 원격지에 백업한다. 구축 및 유지보수 비용이 가장 저렴하나 복구 소요시간이 매우 길고 복구의 신뢰성이 낮다.
- 핫사이트(Hot Site) : 핫사이트는 전체 컴퓨터 시스템과 사용자 데이터의 거의 완전한 백업이 있는 조직의 원래 사이트의 복제본이다. 두 사이트 간의 실시간 동기화는 광역 네트워크 링크 및 특수 소프트웨어를 사용하여 원래 사이트의 데이터 환경을 완전히 미러링하는 데 사용될 수 있다. 원래 사이트가 중단된 후 핫사이트가 존재하므로 조직이 최소한의 손실로 짧은 복구 시간에 정상 작업으로 이전할 수 있다. 이상적으로, 핫사이트는 몇 시간 이내에 실행된다. 인력은 핫사이트로 이동해야 할 수 있지만 직원이 이전하기 전에 핫사이트가 데이터 처리 관점에서 작동할 수 있다. 핫사이트의 용량은 조직의 요구 사항에 따라 원래 사이트의 용량과 일치하거나 일치하지 않을 수 있다. 이러한 유형의 백업사이트는 운영 비용이 가장 많이 든다. 핫사이트는 금융 기관, 정부 기관 및 전자 상거래 제공 업체와 같은 실시간 프로세스를 운영하는 조직에서 인기가 있다. 핫사이트에서 제공하는 가장 중요한 기능은 프로덕션 환경이 주 데이터 센터와 동시에 실행된다는 것이다. 이 동기화를 통해 비즈니스 운영에 미치는 영향과 가동 중지 시간을 최소화할 수 있다. 중대한 정전이 발생했을 때, 핫사이트는 즉시 영향을 받은 사이트를 대신할 수 있다. 그러나 이러한 중복 수준은 저렴하지 않으며 기업은 핫사이트 활용의 비용 이점 분석(CBA)을 고려해야 한다. 요즘 백업사이트가 다운되어 "사전 예방적" 접근방식을 놓치면 ISO 22301 접근방식(비즈니스 연속성 관리를 위한 국제표준)과 관련하여 조직의 성숙도 수준에 따라 핫사이트로 간주되지 않을 수 있다. 핫사이트는 전통적으로 콜드사이트보다 비싸다. 회사가 필요로 하는 장비의 대부분을 구입해야 하므로 사람들이 그것을 유지하기 위해 필요하기 때문에, 운영 비용을 더 높게 만들 수 있다. 그러나 동일한 조직이 비활성 상태로 매일 상당한 양의 수익을 잃는다면 비용이 들 수 있다. 핫사이트의 또 다른 장점은 재해가 발생하기 전에 작업에 사용할 수 있다는 것이다. 이 부하 균형 생산 처리 방법은 비용 효율적이며 데이터센터 중 하나에 영향을 미치는 이벤트 중에 최소한의 가동 중지 시간을 사용자에게 제공한다. 주 센터와 동일한 수준의 정보기술자원을 대기 상태(standard)로 사이트에 보유하면서, 동기적 또는 비동기적 방식으로 실시간 미러링(mirroring)을 통하여 데이터를 최신으로 유지한다. 주 센터 재해 시 재해 복구 센터의 정보 시스템을 액티브로 전환하여 서비스하는 방식으로 재해 발생 시 복구까지의 소요시간(RTO)는 약 4시간 이내이다. 초기 투자 및 유지 보수에 높은 비용이 소모되며, 데이터베이스 애플리케이션 등 데이터의 업데이트 빈도가 높은 시스템의 경우 사용한다.[2]
- 웜사이트(Warm Site) : 콜드사이트와 핫사이트의 절충 사이트이다. 이 사이트들에는 하드웨어가 있고 연결이 이미 확립되어 있지만 원래의 생산 사이트나 핫 사이트보다도 규모가 작은 편이다. 웜사이트는 직접 백업본을 갖출 수 있으나 완전하지 못할 수도 있다.[3] 핫사이트와 유사하나 재해복구센터에 주 센터와 동일한 수준의 정보기술자원을 보유하는 대신 중요성이 높은 정보기술자원만 부분적으로 재해복구 센터에 보유하는 방식이다. 고가의 장비와 응용프로그램, 리얼 데이터(real data)를 제외한 시설과 장비 준비, 가장 널리 사용하는 모델이다. 실시간 미러링을 수행하지 않으며 데이터의 백업 주기가 수 시간~1일 정도로 핫사이트에 비해 다소 길다.
- 미러사이트(mirror site) : 주 센터와 동인한 수준의 정보기술자원을 원격지에 구축하고, 메인센터 재해복구센터 모두 액티브 상태로 실시간 동시 서비스를 하는 방식이다. 재해 발생시 복구까지의 소요시간은 이론적으로 '0'이다. 초기 투자 및 유지 보수에 높은 비용이 소모되며, 웹 애플리케이션 서비스 등 데이터의 업데이트의 빈도가 높지 않은 시스템에 적용 가능하다.[4]
- 상업사이트 : 백업사이트 기능의 상용 공급자로부터 서비스를 계약할 때 조직은 계약 사용 조항 및 호출 절차를 기록해야 한다. 공급자는 다양한 서비스 수준에 따라 지정된 사이트 또는 시설에 두 개 이상의 조직에 가입할 수 있다. 서비스를 사용하는 모든 조직이 동시에 서비스를 필요로 할 가능성이 낮으며 공급자가 저렴한 비용으로 서비스를 제공할 수 있기 때문에 합리적인 제안이다. 그러나 광역지역에 영향을 미치는 대규모 사고에서는 이러한 시설이 과도하게 가입될 가능성이 높다. 조직은 공급자에게 우선 서비스를 요청할 수 있으며, 종종 월 수수료가 더 높은 경우가 많다. 상용사이트는 기본 데이터센터에 대한 본격적인 미러링 환경을 갖춘 보조 프로덕션 사이트로도 사용할 수 있다. 다시 말하지만, 더 높은 수수료가 필요하지만 사이트의 보안과 조직의 데이터가 및 응용 프로그램에 대한 중단없이 액세스할 수 있는 능력은 비용을 정당화할 수 있다.[5]
각주
- ↑ 데이터 백업 및 복구: 기업을 위한 필수 가이드 베리타스 - https://www.veritas.com/ko/kr/information-center/data-backup-and-recovery
- ↑ 고기는물풍선, 〈(정보보안기사)재해복구 시스템(백업 사이트)의 종류(미러 사이트, 핫 사이트, 웜 사이트, 콜드 사이트)〉, 《네이버 블로그》, 2019-06-09
- ↑ 백업 사이트 위키백과 - https://ko.wikipedia.org/wiki/%EB%B0%B1%EC%97%85_%EC%82%AC%EC%9D%B4%ED%8A%B8
- ↑ IT제이제이, 〈2차 사이트 종류별 특징〉, 《티스토리》, 2018-09-06
- ↑ Backup site 위키백과 - https://en.wikipedia.org/wiki/Backup_site
참고자료
같이 보기
