위키원
"백업사이트"의 두 판 사이의 차이
leejia1222 (토론 | 기여) |
|||
| 8번째 줄: | 8번째 줄: | ||
데이터 백업과 복구는 데이터 손실 발생 시 해당 데이터를 백업하고 보안 시스템을 설정하는 프로세스로, 결과적으로 데이터를 복구할 수 있게 한다. 데이터 백업에는 데이터 손상 또는 삭제 시에도 데이터에 액세스할 수 있도록 시스템 데이터를 복사하여 아카이빙하는 것이 필요하다. 데이터를 백업한 경우 해당 시점의 데이터만 복구할 수 있다. 데이터 백업은 일종의 재해 복구로, 합리적인 재해 복구 계획의 중요한 부분을 구성한다. 데이터 백업이 항상 시스템의 모든 데이터와 설정을 복원할 수 있는 것은 아니다. 예를 들어, 시스템 클러스터나 데이터베이스 서버, 활성 디렉터리 서버의 경우 백업 및 복구로 이들을 완전히 재구성하지 못할 수 있으므로 다른 유형의 재해 복구를 추가해야 할 수 있다. 현재는 클라우드 스토리지를 사용하여 상당한 양의 데이터를 백업할 수 있으므로 로컬 시스템의 하드 드라이브나 외부 스토리지에 데이터를 아카이빙할 필요가 없다. 또한 클라우드 기술을 사용하여 모바일 디바이스를 설정해 자동으로 데이터가 복구되도록 할 수 있다. | 데이터 백업과 복구는 데이터 손실 발생 시 해당 데이터를 백업하고 보안 시스템을 설정하는 프로세스로, 결과적으로 데이터를 복구할 수 있게 한다. 데이터 백업에는 데이터 손상 또는 삭제 시에도 데이터에 액세스할 수 있도록 시스템 데이터를 복사하여 아카이빙하는 것이 필요하다. 데이터를 백업한 경우 해당 시점의 데이터만 복구할 수 있다. 데이터 백업은 일종의 재해 복구로, 합리적인 재해 복구 계획의 중요한 부분을 구성한다. 데이터 백업이 항상 시스템의 모든 데이터와 설정을 복원할 수 있는 것은 아니다. 예를 들어, 시스템 클러스터나 데이터베이스 서버, 활성 디렉터리 서버의 경우 백업 및 복구로 이들을 완전히 재구성하지 못할 수 있으므로 다른 유형의 재해 복구를 추가해야 할 수 있다. 현재는 클라우드 스토리지를 사용하여 상당한 양의 데이터를 백업할 수 있으므로 로컬 시스템의 하드 드라이브나 외부 스토리지에 데이터를 아카이빙할 필요가 없다. 또한 클라우드 기술을 사용하여 모바일 디바이스를 설정해 자동으로 데이터가 복구되도록 할 수 있다. | ||
| − | 백업과 복구의 주된 차이점은 백업이 데이터베이스 장애 시 사용할 수 있는 원본 데이터의 카피본인 반면, 복구는 장애 발생 시 데이터베이스를 원래의 상태로 복원하는 프로세스를 의미한다. | + | 백업과 복구의 주된 차이점은 백업이 데이터베이스 장애 시 사용할 수 있는 원본 데이터의 카피본인 반면, 복구는 장애 발생 시 데이터베이스를 원래의 상태로 복원하는 프로세스를 의미한다. 백업은 데이터의 대표 카피본을 가리키는 것으로, 데이터 파일과 제어 파일 같은 데이터베이스의 필수 요소가 여기에 포함된다. 예기치 않은 데이터베이스 고장을 피할 수 없기 때문에, 전체 데이터베이스 백업이 반드시 필요하다. 다음의 두 가지 주요 백업 유형이 있다. |
| − | *물리적 백업 : 데이터, 제어 파일, 로그 파일, 아카이빙된 재실행 로그 등 실제 데이터베이스 파일의 카피본을 말한다. 다른 위치에 데이터베이스 정보를 저장하는 파일의 카피본으로, 데이터베이스 복구 메커니즘의 기초를 형성한다. | + | * '''물리적 백업''' : 데이터, 제어 파일, 로그 파일, 아카이빙된 재실행 로그 등 실제 데이터베이스 파일의 카피본을 말한다. 다른 위치에 데이터베이스 정보를 저장하는 파일의 카피본으로, 데이터베이스 복구 메커니즘의 기초를 형성한다. |
| − | *논리적 백업 : | + | * '''논리적 백업''' : 데이터베이스로부터 추출한 논리적 데이터가 포함되며 테이블, 프로시저, 뷰, 함수 등으로 구성된다. 하지만 논리적 백업만 유지하는 것은 구조적 정보만 제공한다는 점에서 권장되거나 유용하지 않을 수 있다. 반면, 복구는 장애 발생 시 온전한 상태로 데이터베이스를 복원하도록 돕는 역할을 한다. 갑작스런 장애 이후 데이터베이스를 일관된 상태로 복구할 수 있게 하므로 데이터베이스의 안정성을 향상시키는 것이다. 로그 기반 복구를 사용하여 데이터베이스를 온전히 복구할 수 있도록 한다. 로그는 트랜잭션 레코드가 포함된 레코드 시퀀스로, 안정적인 스토리지에 저장될 때 모든 트랜잭션을 기록한 로그를 통해 장애 이후 데이터베이스를 복구할 수 있게 된다. 여기에는 실행할 트랜잭션과 트랜잭션 상태, 수정된 값 등에 대한 정보가 포함된다. 이러한 정보는 모두 실행 순서에 따라 저장되어 있다.<ref>데이터 백업 및 복구: 기업을 위한 필수 가이드 베리타스 - https://www.veritas.com/ko/kr/information-center/data-backup-and-recovery</ref> |
| − | + | 웹사이트를 백업하는 방법을 모르는 경우 온라인 백업 서비스가 프로세스를 크게 간소화할 수 있다. 사이트를 백업하는 것을 기억하거나 백업을 올바른 방법으로 보호하는 것에 대해 걱정할 필요가 없다. 백업 서비스는 다음과 같은 장점을 가지고 있다. | |
| − | |||
| − | *''' | + | * '''간편성''' : 온라인 백업 서비스를 사용하면 사이트가 백업될지 여부를 생각할 필요가 없다. 클라우드 기반 백업 솔루션은 매우 효율적이다. 백업을 직접 관리하고 제대로 저장되었는지 확인하는 대신 전체 프로세스가 백그라운드에서 자동으로 발생하고 사이트의 파일과 폴더가 원격 서버에 안전하게 저장된다. 또한 데이터 저장 장치의 유지 보수 또는 물리적 보호에 대해 걱정할 필요가 없다. 이 모든 것은 웹 사이트 백업 공급자가 처리한다. 일반적으로 웹 사이트 데이터는 손상되거나 어떤 식으로든 손상된 경우여러 다른 저장소 위치에도 저장된다. |
| − | *''' | + | * '''향상된 보안 프로토콜''' : 사이트를 수동으로 백업하고 기본 저장소 솔루션을 사용하는 경우 클라우드 백업 솔루션이 제공할 수 있는 만큼 보안 수준이 높지 않다. HDD 백업을 사용하면 데이터 손상, 스토리지 오작동, 물리적 손상 등과 같은 모든 종류의 위험까지 파일을 열 수 있다. 사이트를 정기적으로 백업하는 경우에도 실제로 데이터에 액세스할 수 없는 경우 사용할 수 없다. 온라인 백업 서비스에는 파일을 보호하기 위해 여러 계층의 보안이 있을 뿐만 아니라 중복 서버에 저장된다. 즉, 사이트의 파일 복사본이 여러 서버 물리적 서버에 저장된다. 백업을 직접 관리할 때 이러한 수준의 보안 및 데이터 복구를 얻는 것은 쉽지 않다. |
| − | *''' | + | * '''신속한 사이트 복구''' : 온라인 백업 서비스를 사용하는 가장 큰 이점 중 하나는 사이트를 즉시 이전 버전으로 복원할 수 있다는 것이다. 빠른 웹 사이트 복구 및 데이터 복원 시간을 사용하면 사이트가 처음부터 손상을 입지 않은 것처럼 보인다. 자신의 백업을 관리하는 경우 특히 필요한 기술이 없는 경우 프로세스가 훨씬 느리다. 많은 온라인 백업 서비스는 사이트를 복원하거나 한 번의 클릭으로 복구 옵션을 제공하는 기술 지원을 제공한다.<ref> Kevin Wood, 〈[https://www.hostgator.com/blog/backing-website-important/ How to Backup Your Website & Why It’s Important]〉, 《호스트 게이터》, 2019-04-30</ref> |
| − | + | ===재난복구작업=== | |
| + | 재해복구 시스템이란 태풍, 지진 등과 같은 자연재해 또는 테러와 같은 공격 등에 의한 비상시 연속적으로 서비스를 제공하기 위해 복제된 시스템 및 컴퓨터를 갖춘 곳을 의미한다. 재해복구 시스템의 과정에서 백업 사이트가 이용된다. 재난복구작업의 과정은 다음과 같다. | ||
| − | + | ; 재난복구계획 수립 | |
| − | + | 백업 작업은 매우 중요하지만 재난 복구 계획이 없이는 무용지물이 될 수 있다. 재난 복구 계획에는 다음과 같은 내용을 포함한 모든 재난 복구 절차를 지정한다. | |
| − | * | + | * 발생 가능한 재난에 대한 설명 |
| + | * 회사에서 재난 상태를 공표하고 재난 복구 계획을 실행할 권한을 가진 직원 정보 | ||
| + | * 재난 상태가 공표된 후 백업을 준비하는데 필요한 작업 순서 | ||
| + | * 재난 복구 계획 수행과 관련된 핵심 인물들의 역할 | ||
| + | * 복구 작업을 수행하는데 필요한 필수 하드웨어와 소프트웨어 목록 | ||
| + | * 재난 팀 구성원들이 과로하지 않도록 교대 지원할 직원 목록과 교대 스케쥴 | ||
| + | * 백업이 위치한 곳에서 복구된/새 데이터 센터로 옮겨가는 작업 순서 | ||
| − | + | 재난 복구 계획을 세웠다면 해당 내용을 서류에 잘 정리해 놓아야 한다. 응급 상황이 발생하였을 때 이러한 정보가 있어야 복구 작업을 시작할 수 있으므로 매우 중요하게 사용된다. 또한 재난 복구 계획 서류는 회사뿐만 아니라 백업이 보관된 곳에도 비치해 두어야 한다. 만일 재난이 발생하여 회사 건물이 모두 손상을 입는 경우 재난 복구 계획도 함께 사라지게 되기 때문이다. 따라서 멀리 떨어진 백업 보관 장소에 복사본을 비치해 두는 것이 좋다. 만일 회사의 보안 정책에 위반되지 않는다면, 각 재난 복구팀 직원 가정에도 복사본을 한부씩 보관해 두는 것도 좋은 생각이다. 주의해야 할 점은 재난 복구 계획을 항상 업데이트 해야 한다는 것이다. 오랜 기간 업데이트 되지 않은 재난 복구 계획은 무용지물이 되기 때문에 주기적으로 계획을 검토하고 업데이트할 계획도 세워야 한다. | |
| − | + | ; 재난복구계획 테스트 및 구현 | |
| + | 재난복구 계획 서류 문서 집필을 마치면 주기적으로 내용을 테스트해 보아야 한다. 재난 복구 계획을 테스트하기 위해서는 직접 모든 절차를 실행해야 한다. 백업이 위치한 장소에 가서 임시 데이터 센터를 설치하고, 응용 프로그램을 원격적으로 실행한 후 재난 상황이 발생 후 정상적인 작업을 다시 시작해봐야 한다. 대부분의 경우 재난 복구 계획에 명시된 모든 작업을 수행하려고 하는데, 대표 시스템과 응용 프로그램만 선택하여 백업 장소로 옮긴 후 얼마동안 생산 환경을 운영해본 후 테스팅을 마치면 장상적인 작업 상태로 되돌리면 된다. | ||
| + | |||
| + | ; 복구 작업 실행 | ||
| + | 재난 복구에서 가장 중요한 측면 중 하나가 바로 복구작업을 실행할 수 있는 장소 즉, 백업사이트이다. 재난이 발생할 경우 백업사이트에서 바로 데이터 센터를 다시 생성하여 재난 기간 동안 작업을 수행할 수 있다. 백업사이트는 1) 재난 복구 서비스를 전문적으로 제공하는 업체 2) 기업이 소유하고 운영하는 다른 장소 3) 재난이 발생할 경우 데이터 센터 시설을 공유하기로 다른 기업체와 상호 계약을 맺은 경우와 같은 세 가지 다른 곳에서 제공한다. 각 방식마다 장단점이 있는데, 예를 들어 재난 복구 업체와 계약을 맺은 경우에는 재난 복구 계획을 세울 때 전문적인 도움을 받을 수 있지만 비용이 만만치 않다. 회사가 소유하고 운영하는 다른 장소를 사용하는 경우 장소 자체에는 비용이 들지 않지만 백업사이트에 하드웨어를 구입하여 넣고 준비될 때까지 관리하는 작업은 여전히 많은 비용이 든다. 다른 기업체와 함께 데이터 센터를 공유하는 상호 계약을 맺은 경우에는 비용이 매우 절약되지만, 데이터 센터를 제공하는 기업체에서는 여전히 일반 생산 작업을 지속적으로 수행해야 하므로 장기간 이러한 방식을 사용할 수는 없다. 결국 백업사이트를 선택하기 위해서는 비용과 생산 환경 요건을 놓고 타협 지점을 찾아야 한다. | ||
| + | |||
| + | ; 사용 가능한 하드웨어와 소픝웨어 준비 | ||
| + | 재난 복구 계획을 세울 때 반드시 백업사이트에서 작업하는 데 필요한 하드웨어와 소프트웨어를 준비하는 방법도 포함시켜야 한다. 전문적으로 관리되는 백업사이트에는 이미 모두 갖추어져 있을 수도 있지만 콜드사이트의 경우에는 각 상황에 필요한 하드웨어와 소프트웨어를 미리 파악해 놓아야 한다. 종종 기업체에서는 재난 발생 시 신속하게 하드웨어와 소프트웨어가 배달되도록 제조업체와 상호 계약을 맺는 경우도 있다. | ||
| + | |||
| + | ; 사용 가능한 백업 준비 | ||
| + | 재난 상황이 공표되면 바로 원격지 저장 장소에 통보해야 한다. 최근 백업을 백업사이트로 배달하도록 알리고, 주기적으로 백업을 픽업하여 백업사이트에 배달되도록 계획을 세워야 하기 때문이다. 재난이 발생할 경우 이전 데이터센터에서 가져온 최근 백업은 매우 중요한 역할을 한다. 어떠한 복구 작업을 시작하기 전에 최근 백업의 복사본을 만들어 두고, 복사본을 만들자마자 최대한 빨리 원본을 원격지 백업사이트로 보내야 한다. | ||
| + | |||
| + | ; 백업사이트로 네트워크 연결 가능 여부 | ||
| + | 데이터센터가 회사 내 다른 어느 곳과도 네트워크로 연결되어 있지 않다면 아무런 소용이 없다. 재난복구계획 및 재난의 성격에 따라서 사용자가 백업사이트에서 멀리 떨어진 곳에 위치할 경우도 있다. 이러한 경우 복구 작업의 성공 여부는 얼마나 네트워크 연결이 잘 되어있느냐에 달려있다. 또 한가지 기억해야 할 것은 전화 연결 여부이다. 사용자와 모든 대화를 주고받을 수 있도록 충분한 전화선이 준비되어 있어야 한다. 백업사이트와 사용자가 멀리 떨어져 있을 경우 복구 계획 실행을 장거리 전화 대화에 의존해야 하므로 가능한 보다 많은 전화선을 연결해 놓는 것이 좋다. | ||
| + | |||
| + | ; 백업사이트로 인재 파견 | ||
| + | 백업사이트로 인재를 파견하기 위해서는 여러가지 측면을 고려해야 한다. 우선 백업 데이터센터를 장기간 운영하는데 필요한 직원수를 결정해야 한다. 최소 인원수만으로 짧은 기간 동안 운영 가능할지는 모르겠지만, 만일 비상 사태가 발생하면 보다 많은 직원이 필요하다. 따라서 직원이 백업사이트에 도착하여 휴식을 취할 시간과 가정으로 돌아가는데 걸리는 시간도 고려해야 한다. 만일 직원이 집과 가정에도 영향을 미치는 재난이 발생했을 경우 각 직원이 자기 가정의 재난복구를 먼저 처리할 수 있는 시간도 할당해야 한다. 종종 재난 복구 시 회사 내 모든 분야의 사용자 그룹 대표가 참여해야 할 경우도 있다. 이러한 경우에는 사용자 대표가 백업사이트에서 작업할 때 머무를 숙박 시설이 미리 준비되어야 한다. | ||
| + | |||
| + | ; 정상적인 작업으로 돌아가는 절차 | ||
| + | 언젠가는 재난 사태가 끝이 나기 마련이다. 따라서 재난복구 계획에는 반드시 이 마지막 단계에 대한 내용을 포함해야 한다. 새 데이터 센터에는 필요한 모든 하드웨어와 소프트웨어가 완비되어야 한다. 이 작업은 비상 사태가 처음 선포되었을 때만큼 급하게 서두를 필요는 없지만, 백업사이트를 매일 운영하는 데 드는 비용이 만만치 않으므로 가능하면 빨리 새 데이터센터로 작업을 옮기는 게 좋다. 백업사이트에서 최신 백업을 만들어 새 데이터센터로 배달해 와야 한다. 새 하드웨어에 모든 자료가 복구되면 새 데이터 센터로 생산 작업을 옮겨올 수 있다. | ||
| + | |||
| + | ==종류== | ||
| + | 백업사이트는 콜드사이트, 웜사이트, 핫사이트, 미러사이트 등의 네 가지 유형으로 구분된다. 이 용어는 백업사이트의 온도와는 아무런 관계가 없다. 오히려 백업사이트의 규모와 재난 발생 시 드는 노력과 관련된다. | ||
| + | |||
| + | ===콜드사이트=== | ||
| + | 콜드사이트(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)’라는 이름이 붙었다. 이런 식으로 웹사이트의 파일을 동기화하는 것을 [[미러링]]이라고 부른다. 미러링의 목적은 데이터의 안정적 보존 및 본 [[서버]]에 문제가 생겼을 경우에 대한 대비이다. 미러링을 함으로써 본 서버의 접속자를 분산하거나 해당 웹페이지를 빠르고 가볍게 접속할 수 있다.<ref>미러 사이트 나무위키 - https://namu.wiki/w/%EB%AF%B8%EB%9F%AC%20%EC%82%AC%EC%9D%B4%ED%8A%B8</ref> 접속량이 많은 사이트들은 과다한 트래픽으로 접속이 힘들거나 접속 속도가 떨어지는 경우가 있다. 이를 방지하기 위해 네트워크 이용 효율을 향상시키기 위한 목적으로 미러사이트가 개발되었다. 미러사이트를 이용하면 웹사이트나 파일의 가용성을 좋게 하고, 그 사이트에서 다운로드된 파일들이 미러사이트 부근에 있는 사용자들에게 보다 빨리 도착하게 한다. | ||
| + | |||
| + | 미러사이트들은 원래 사이트가 지리적으로 어느 정도의 거리가 있을 때, 보다 빨리 액세스하기 위해 사용된다. 미러사이트는 파일의 배포 부담을 2개 이상의 파일서버로 분산하거나 통신량이 폭주하는 장거리 또는 국제 회선을 경우하지 않고, [[FTP]] 서사이트에 접근할 수 있게 하여 FTP 서버로부터 다운로드 될 수 있는 파일들에 대해서도 미러파일을 만들 수 있다. 다만 인터넷상에서 유명한 사이트의 경우 전 세계 몇 군데의 미러사이트가 있기 때문에 접속이 원활하지 않은 경우가 있어, 그런 경우에는 가까운 곳 또는 국내의 미러사이트를 이용하는 것이 바람직하다. 원래 사이트가 인터넷에 고속으로 접속되어 있지 않은 경우, 고속으로 접속되어 있는 대형 사이트에 미러사이트를 만든다면 아마도 보다 많은 방문객을 유지할 수 있을 것이다. 넷스케이프, 마이크로시스템즈, 썬 마이크로시스템즈, 그리고 다른 많은 회사들이 자신의 브라우저 소프트웨어를 다운로드 받을 수 있는 미러사이트들을 가지고 있다.<ref>〈[http://www.terms.co.kr/mirrorsite.htm mirror site ; 미러사이트]〉, 《텀즈》, 1999-11-04</ref> 한편 미러사이트는 원래 사이트의 정확한 복제품이어야 하므로 원래 사이트의 내용을 확실히 반영시키기 위해 보통 주기적으로 갱신된다는 특징이 있다. | ||
| + | |||
| + | ===상업사이트=== | ||
| + | [[상업사이트]]는 백업사이트 기능의 상용 공급자로부터 서비스를 계약할 때 조직은 계약 사용 조항 및 호출 절차를 기록해야 한다. 공급자는 다양한 서비스 수준에 따라 지정된 사이트 또는 시설에 두 개 이상의 조직에 가입할 수 있다. 서비스를 사용하는 모든 조직이 동시에 서비스를 필요로 할 가능성이 낮으며 공급자가 저렴한 비용으로 서비스를 제공할 수 있기 때문에 합리적인 제안이다. 그러나 광역지역에 영향을 미치는 대규모 사고에서는 이러한 시설이 과도하게 가입될 가능성이 높다. 조직은 공급자에게 우선 서비스를 요청할 수 있으며, 종종 월 수수료가 더 높은 경우가 많다. 상용사이트는 기본 데이터센터에 대한 본격적인 미러링 환경을 갖춘 보조 프로덕션 사이트로도 사용할 수 있다. 다시 말하지만, 더 높은 수수료가 필요하지만 사이트의 보안과 조직의 데이터가 및 응용 프로그램에 대한 중단없이 액세스할 수 있는 능력은 비용을 정당화할 수 있다.<ref>Backup site 위키백과 - https://en.wikipedia.org/wiki/Backup_site</ref> | ||
==다른 백업 사이트== | ==다른 백업 사이트== | ||
2020년 8월 12일 (수) 11:46 판
백업사이트(backup site)는 지진, 홍수, 테러리스트의 공격과 같은 비상시를 위해 복제된 시스템의 예비 컴퓨터 등을 갖추어 놓은 곳을 말한다. 재해 복구 계획과 더 넓은 업무 연속성 계획의 중요한 부분이다.
목차
개요
백업사이트 또는 작업 영역 복구 사이트는 화재, 홍수, 테러 위협 또는 기타 파괴적인 이벤트와 같은 재해 발생 후 조직이 이전할 수 있는 위치이다. 이는 재해 복구 계획의 필수적인 부분이며 조직의 광범위한 비즈니스 연속성 계획이다. 백업 또는 대체 사이트는 조직에서 운영하거나 재해 복구 서비스를 전문으로 하는 회사를 통해 계약된 다른 데이터센터 위치일 수 있다. 경우에 따라 한 조직에서 공동 백업사이트를 운영하기 위해 두 번째 조직과 계약을 체결한다. 또한 조직은 각 데이터 센터에 웜사이트를 설정하는 다른 조직과 상호 계약을 맺을 수 있다. 콜드사이트, 웜사이트 및 핫사이트를 포함하여 세 가지 유형의 백업사이트가 있다. 형식 간의 차이점은 각 형식을 구현하는 데 필요한 비용과 노력에 의해 결정된다.
특징
데이터 백업 및 복구
데이터 백업과 복구는 데이터 손실 발생 시 해당 데이터를 백업하고 보안 시스템을 설정하는 프로세스로, 결과적으로 데이터를 복구할 수 있게 한다. 데이터 백업에는 데이터 손상 또는 삭제 시에도 데이터에 액세스할 수 있도록 시스템 데이터를 복사하여 아카이빙하는 것이 필요하다. 데이터를 백업한 경우 해당 시점의 데이터만 복구할 수 있다. 데이터 백업은 일종의 재해 복구로, 합리적인 재해 복구 계획의 중요한 부분을 구성한다. 데이터 백업이 항상 시스템의 모든 데이터와 설정을 복원할 수 있는 것은 아니다. 예를 들어, 시스템 클러스터나 데이터베이스 서버, 활성 디렉터리 서버의 경우 백업 및 복구로 이들을 완전히 재구성하지 못할 수 있으므로 다른 유형의 재해 복구를 추가해야 할 수 있다. 현재는 클라우드 스토리지를 사용하여 상당한 양의 데이터를 백업할 수 있으므로 로컬 시스템의 하드 드라이브나 외부 스토리지에 데이터를 아카이빙할 필요가 없다. 또한 클라우드 기술을 사용하여 모바일 디바이스를 설정해 자동으로 데이터가 복구되도록 할 수 있다.
백업과 복구의 주된 차이점은 백업이 데이터베이스 장애 시 사용할 수 있는 원본 데이터의 카피본인 반면, 복구는 장애 발생 시 데이터베이스를 원래의 상태로 복원하는 프로세스를 의미한다. 백업은 데이터의 대표 카피본을 가리키는 것으로, 데이터 파일과 제어 파일 같은 데이터베이스의 필수 요소가 여기에 포함된다. 예기치 않은 데이터베이스 고장을 피할 수 없기 때문에, 전체 데이터베이스 백업이 반드시 필요하다. 다음의 두 가지 주요 백업 유형이 있다.
- 물리적 백업 : 데이터, 제어 파일, 로그 파일, 아카이빙된 재실행 로그 등 실제 데이터베이스 파일의 카피본을 말한다. 다른 위치에 데이터베이스 정보를 저장하는 파일의 카피본으로, 데이터베이스 복구 메커니즘의 기초를 형성한다.
- 논리적 백업 : 데이터베이스로부터 추출한 논리적 데이터가 포함되며 테이블, 프로시저, 뷰, 함수 등으로 구성된다. 하지만 논리적 백업만 유지하는 것은 구조적 정보만 제공한다는 점에서 권장되거나 유용하지 않을 수 있다. 반면, 복구는 장애 발생 시 온전한 상태로 데이터베이스를 복원하도록 돕는 역할을 한다. 갑작스런 장애 이후 데이터베이스를 일관된 상태로 복구할 수 있게 하므로 데이터베이스의 안정성을 향상시키는 것이다. 로그 기반 복구를 사용하여 데이터베이스를 온전히 복구할 수 있도록 한다. 로그는 트랜잭션 레코드가 포함된 레코드 시퀀스로, 안정적인 스토리지에 저장될 때 모든 트랜잭션을 기록한 로그를 통해 장애 이후 데이터베이스를 복구할 수 있게 된다. 여기에는 실행할 트랜잭션과 트랜잭션 상태, 수정된 값 등에 대한 정보가 포함된다. 이러한 정보는 모두 실행 순서에 따라 저장되어 있다.[1]
웹사이트를 백업하는 방법을 모르는 경우 온라인 백업 서비스가 프로세스를 크게 간소화할 수 있다. 사이트를 백업하는 것을 기억하거나 백업을 올바른 방법으로 보호하는 것에 대해 걱정할 필요가 없다. 백업 서비스는 다음과 같은 장점을 가지고 있다.
- 간편성 : 온라인 백업 서비스를 사용하면 사이트가 백업될지 여부를 생각할 필요가 없다. 클라우드 기반 백업 솔루션은 매우 효율적이다. 백업을 직접 관리하고 제대로 저장되었는지 확인하는 대신 전체 프로세스가 백그라운드에서 자동으로 발생하고 사이트의 파일과 폴더가 원격 서버에 안전하게 저장된다. 또한 데이터 저장 장치의 유지 보수 또는 물리적 보호에 대해 걱정할 필요가 없다. 이 모든 것은 웹 사이트 백업 공급자가 처리한다. 일반적으로 웹 사이트 데이터는 손상되거나 어떤 식으로든 손상된 경우여러 다른 저장소 위치에도 저장된다.
- 향상된 보안 프로토콜 : 사이트를 수동으로 백업하고 기본 저장소 솔루션을 사용하는 경우 클라우드 백업 솔루션이 제공할 수 있는 만큼 보안 수준이 높지 않다. HDD 백업을 사용하면 데이터 손상, 스토리지 오작동, 물리적 손상 등과 같은 모든 종류의 위험까지 파일을 열 수 있다. 사이트를 정기적으로 백업하는 경우에도 실제로 데이터에 액세스할 수 없는 경우 사용할 수 없다. 온라인 백업 서비스에는 파일을 보호하기 위해 여러 계층의 보안이 있을 뿐만 아니라 중복 서버에 저장된다. 즉, 사이트의 파일 복사본이 여러 서버 물리적 서버에 저장된다. 백업을 직접 관리할 때 이러한 수준의 보안 및 데이터 복구를 얻는 것은 쉽지 않다.
- 신속한 사이트 복구 : 온라인 백업 서비스를 사용하는 가장 큰 이점 중 하나는 사이트를 즉시 이전 버전으로 복원할 수 있다는 것이다. 빠른 웹 사이트 복구 및 데이터 복원 시간을 사용하면 사이트가 처음부터 손상을 입지 않은 것처럼 보인다. 자신의 백업을 관리하는 경우 특히 필요한 기술이 없는 경우 프로세스가 훨씬 느리다. 많은 온라인 백업 서비스는 사이트를 복원하거나 한 번의 클릭으로 복구 옵션을 제공하는 기술 지원을 제공한다.[2]
재난복구작업
재해복구 시스템이란 태풍, 지진 등과 같은 자연재해 또는 테러와 같은 공격 등에 의한 비상시 연속적으로 서비스를 제공하기 위해 복제된 시스템 및 컴퓨터를 갖춘 곳을 의미한다. 재해복구 시스템의 과정에서 백업 사이트가 이용된다. 재난복구작업의 과정은 다음과 같다.
- 재난복구계획 수립
백업 작업은 매우 중요하지만 재난 복구 계획이 없이는 무용지물이 될 수 있다. 재난 복구 계획에는 다음과 같은 내용을 포함한 모든 재난 복구 절차를 지정한다.
- 발생 가능한 재난에 대한 설명
- 회사에서 재난 상태를 공표하고 재난 복구 계획을 실행할 권한을 가진 직원 정보
- 재난 상태가 공표된 후 백업을 준비하는데 필요한 작업 순서
- 재난 복구 계획 수행과 관련된 핵심 인물들의 역할
- 복구 작업을 수행하는데 필요한 필수 하드웨어와 소프트웨어 목록
- 재난 팀 구성원들이 과로하지 않도록 교대 지원할 직원 목록과 교대 스케쥴
- 백업이 위치한 곳에서 복구된/새 데이터 센터로 옮겨가는 작업 순서
재난 복구 계획을 세웠다면 해당 내용을 서류에 잘 정리해 놓아야 한다. 응급 상황이 발생하였을 때 이러한 정보가 있어야 복구 작업을 시작할 수 있으므로 매우 중요하게 사용된다. 또한 재난 복구 계획 서류는 회사뿐만 아니라 백업이 보관된 곳에도 비치해 두어야 한다. 만일 재난이 발생하여 회사 건물이 모두 손상을 입는 경우 재난 복구 계획도 함께 사라지게 되기 때문이다. 따라서 멀리 떨어진 백업 보관 장소에 복사본을 비치해 두는 것이 좋다. 만일 회사의 보안 정책에 위반되지 않는다면, 각 재난 복구팀 직원 가정에도 복사본을 한부씩 보관해 두는 것도 좋은 생각이다. 주의해야 할 점은 재난 복구 계획을 항상 업데이트 해야 한다는 것이다. 오랜 기간 업데이트 되지 않은 재난 복구 계획은 무용지물이 되기 때문에 주기적으로 계획을 검토하고 업데이트할 계획도 세워야 한다.
- 재난복구계획 테스트 및 구현
재난복구 계획 서류 문서 집필을 마치면 주기적으로 내용을 테스트해 보아야 한다. 재난 복구 계획을 테스트하기 위해서는 직접 모든 절차를 실행해야 한다. 백업이 위치한 장소에 가서 임시 데이터 센터를 설치하고, 응용 프로그램을 원격적으로 실행한 후 재난 상황이 발생 후 정상적인 작업을 다시 시작해봐야 한다. 대부분의 경우 재난 복구 계획에 명시된 모든 작업을 수행하려고 하는데, 대표 시스템과 응용 프로그램만 선택하여 백업 장소로 옮긴 후 얼마동안 생산 환경을 운영해본 후 테스팅을 마치면 장상적인 작업 상태로 되돌리면 된다.
- 복구 작업 실행
재난 복구에서 가장 중요한 측면 중 하나가 바로 복구작업을 실행할 수 있는 장소 즉, 백업사이트이다. 재난이 발생할 경우 백업사이트에서 바로 데이터 센터를 다시 생성하여 재난 기간 동안 작업을 수행할 수 있다. 백업사이트는 1) 재난 복구 서비스를 전문적으로 제공하는 업체 2) 기업이 소유하고 운영하는 다른 장소 3) 재난이 발생할 경우 데이터 센터 시설을 공유하기로 다른 기업체와 상호 계약을 맺은 경우와 같은 세 가지 다른 곳에서 제공한다. 각 방식마다 장단점이 있는데, 예를 들어 재난 복구 업체와 계약을 맺은 경우에는 재난 복구 계획을 세울 때 전문적인 도움을 받을 수 있지만 비용이 만만치 않다. 회사가 소유하고 운영하는 다른 장소를 사용하는 경우 장소 자체에는 비용이 들지 않지만 백업사이트에 하드웨어를 구입하여 넣고 준비될 때까지 관리하는 작업은 여전히 많은 비용이 든다. 다른 기업체와 함께 데이터 센터를 공유하는 상호 계약을 맺은 경우에는 비용이 매우 절약되지만, 데이터 센터를 제공하는 기업체에서는 여전히 일반 생산 작업을 지속적으로 수행해야 하므로 장기간 이러한 방식을 사용할 수는 없다. 결국 백업사이트를 선택하기 위해서는 비용과 생산 환경 요건을 놓고 타협 지점을 찾아야 한다.
- 사용 가능한 하드웨어와 소픝웨어 준비
재난 복구 계획을 세울 때 반드시 백업사이트에서 작업하는 데 필요한 하드웨어와 소프트웨어를 준비하는 방법도 포함시켜야 한다. 전문적으로 관리되는 백업사이트에는 이미 모두 갖추어져 있을 수도 있지만 콜드사이트의 경우에는 각 상황에 필요한 하드웨어와 소프트웨어를 미리 파악해 놓아야 한다. 종종 기업체에서는 재난 발생 시 신속하게 하드웨어와 소프트웨어가 배달되도록 제조업체와 상호 계약을 맺는 경우도 있다.
- 사용 가능한 백업 준비
재난 상황이 공표되면 바로 원격지 저장 장소에 통보해야 한다. 최근 백업을 백업사이트로 배달하도록 알리고, 주기적으로 백업을 픽업하여 백업사이트에 배달되도록 계획을 세워야 하기 때문이다. 재난이 발생할 경우 이전 데이터센터에서 가져온 최근 백업은 매우 중요한 역할을 한다. 어떠한 복구 작업을 시작하기 전에 최근 백업의 복사본을 만들어 두고, 복사본을 만들자마자 최대한 빨리 원본을 원격지 백업사이트로 보내야 한다.
- 백업사이트로 네트워크 연결 가능 여부
데이터센터가 회사 내 다른 어느 곳과도 네트워크로 연결되어 있지 않다면 아무런 소용이 없다. 재난복구계획 및 재난의 성격에 따라서 사용자가 백업사이트에서 멀리 떨어진 곳에 위치할 경우도 있다. 이러한 경우 복구 작업의 성공 여부는 얼마나 네트워크 연결이 잘 되어있느냐에 달려있다. 또 한가지 기억해야 할 것은 전화 연결 여부이다. 사용자와 모든 대화를 주고받을 수 있도록 충분한 전화선이 준비되어 있어야 한다. 백업사이트와 사용자가 멀리 떨어져 있을 경우 복구 계획 실행을 장거리 전화 대화에 의존해야 하므로 가능한 보다 많은 전화선을 연결해 놓는 것이 좋다.
- 백업사이트로 인재 파견
백업사이트로 인재를 파견하기 위해서는 여러가지 측면을 고려해야 한다. 우선 백업 데이터센터를 장기간 운영하는데 필요한 직원수를 결정해야 한다. 최소 인원수만으로 짧은 기간 동안 운영 가능할지는 모르겠지만, 만일 비상 사태가 발생하면 보다 많은 직원이 필요하다. 따라서 직원이 백업사이트에 도착하여 휴식을 취할 시간과 가정으로 돌아가는데 걸리는 시간도 고려해야 한다. 만일 직원이 집과 가정에도 영향을 미치는 재난이 발생했을 경우 각 직원이 자기 가정의 재난복구를 먼저 처리할 수 있는 시간도 할당해야 한다. 종종 재난 복구 시 회사 내 모든 분야의 사용자 그룹 대표가 참여해야 할 경우도 있다. 이러한 경우에는 사용자 대표가 백업사이트에서 작업할 때 머무를 숙박 시설이 미리 준비되어야 한다.
- 정상적인 작업으로 돌아가는 절차
언젠가는 재난 사태가 끝이 나기 마련이다. 따라서 재난복구 계획에는 반드시 이 마지막 단계에 대한 내용을 포함해야 한다. 새 데이터 센터에는 필요한 모든 하드웨어와 소프트웨어가 완비되어야 한다. 이 작업은 비상 사태가 처음 선포되었을 때만큼 급하게 서두를 필요는 없지만, 백업사이트를 매일 운영하는 데 드는 비용이 만만치 않으므로 가능하면 빨리 새 데이터센터로 작업을 옮기는 게 좋다. 백업사이트에서 최신 백업을 만들어 새 데이터센터로 배달해 와야 한다. 새 하드웨어에 모든 자료가 복구되면 새 데이터 센터로 생산 작업을 옮겨올 수 있다.
종류
백업사이트는 콜드사이트, 웜사이트, 핫사이트, 미러사이트 등의 네 가지 유형으로 구분된다. 이 용어는 백업사이트의 온도와는 아무런 관계가 없다. 오히려 백업사이트의 규모와 재난 발생 시 드는 노력과 관련된다.
콜드사이트
콜드사이트(cold site)는 고층, 에어컨, 전원 및 통신 라인 등과 같은 기본 시설이 있는 빈 운영 공간이다. 사고가 발생하고 운영이 약간의 가동 중지 시간으로 수행 할 수있는 경우 콜드사이트에 대체 시설을 가져와 운영을 재개한다. 콜드사이트는 조직이 작동할 수 있는 가장 비용이 많이 드는 유형의 백업사이트이다. 조직의 원래 위치에서 데이터 및 정보의 백업된 복사본을 포함하지 않으며 이미 설정된 하드웨어도 포함하지 않는다. 프로비저닝된 하드웨어의 부족은 콜드사이트의 최소한의 시작 비용에 기여하지만 재해 발생 후 추가 시간이 필요하므로 재해 이전에 가까운 용량에서 작업을 실행해야 한다. 경우에 따라 콜드사이트에는 장비를 사용할 수 있지만 작동하지 않는다. 콜드사이트의 장점은 간단하다. 재해 이전에 장비가 반입되지 않아 콜드사이트를 운영하기 위해 더 적은 리소스가 필요하다. 일부 조직에서는 이전 버전의 하드웨어를 중앙에 저장할 수 있다. 이는 많은 경우에 오래된 하드웨어를 사용할 수 있는 서버 팜 환경에서 적합할 수 있다. 콜드사이트의 단점은 콜드사이트를 효과적으로 만들기 위해 발생해야 할 잠재적 비용이다. 매우 짧은 시간에 장비를 구입하는 비용이 높을 수 있으며 재해로 인해 장비를 얻기가 어려울 수 있다. 데이터만 원격지에 보관하고 서비스를 위한 정보 자원은 확보하지 않거나 장소 등 최소한으로만 확보하고 있다가 재해 시에 데이터를 근간으로 필요한 정보자원을 조달하여 복구하는 방식이다. 주 센터의 데이터는 주기적으로 원격지에 백업한다. 구축 및 유지보수 비용이 가장 저렴하나 복구 소요시간이 매우 길고 복구의 신뢰성이 낮다.
핫사이트
핫사이트(Hot Site)는 전체 컴퓨터 시스템과 사용자 데이터의 거의 완전한 백업이 있는 조직의 원래 사이트의 복제본이다. 두 사이트 간의 실시간 동기화는 광역 네트워크 링크 및 특수 소프트웨어를 사용하여 원래 사이트의 데이터 환경을 완전히 미러링하는 데 사용될 수 있다. 원래 사이트가 중단된 후 핫사이트가 존재하므로 조직이 최소한의 손실로 짧은 복구 시간에 정상 작업으로 이전할 수 있다. 이상적으로, 핫사이트는 몇 시간 이내에 실행된다. 인력은 핫사이트로 이동해야 할 수 있지만 직원이 이전하기 전에 핫사이트가 데이터 처리 관점에서 작동할 수 있다. 핫사이트의 용량은 조직의 요구 사항에 따라 원래 사이트의 용량과 일치하거나 일치하지 않을 수 있다. 이러한 유형의 백업사이트는 운영 비용이 가장 많이 든다. 핫사이트는 금융 기관, 정부 기관 및 전자 상거래 제공 업체와 같은 실시간 프로세스를 운영하는 조직에서 인기가 있다. 핫사이트에서 제공하는 가장 중요한 기능은 프로덕션 환경이 주 데이터 센터와 동시에 실행된다는 것이다. 이 동기화를 통해 비즈니스 운영에 미치는 영향과 가동 중지 시간을 최소화할 수 있다. 중대한 정전이 발생했을 때, 핫사이트는 즉시 영향을 받은 사이트를 대신할 수 있다. 그러나 이러한 중복 수준은 저렴하지 않으며 기업은 핫사이트 활용의 비용 이점 분석(CBA)을 고려해야 한다. 요즘 백업사이트가 다운되어 "사전 예방적" 접근방식을 놓치면 ISO 22301 접근방식(비즈니스 연속성 관리를 위한 국제표준)과 관련하여 조직의 성숙도 수준에 따라 핫사이트로 간주되지 않을 수 있다. 핫사이트는 전통적으로 콜드사이트보다 비싸다. 회사가 필요로 하는 장비의 대부분을 구입해야 하므로 사람들이 그것을 유지하기 위해 필요하기 때문에, 운영 비용을 더 높게 만들 수 있다. 그러나 동일한 조직이 비활성 상태로 매일 상당한 양의 수익을 잃는다면 비용이 들 수 있다. 핫사이트의 또 다른 장점은 재해가 발생하기 전에 작업에 사용할 수 있다는 것이다. 이 부하 균형 생산 처리 방법은 비용 효율적이며 데이터센터 중 하나에 영향을 미치는 이벤트 중에 최소한의 가동 중지 시간을 사용자에게 제공한다. 주 센터와 동일한 수준의 정보기술자원을 대기 상태(standard)로 사이트에 보유하면서, 동기적 또는 비동기적 방식으로 실시간 미러링(mirroring)을 통하여 데이터를 최신으로 유지한다. 주 센터 재해 시 재해 복구 센터의 정보 시스템을 액티브로 전환하여 서비스하는 방식으로 재해 발생 시 복구까지의 소요시간(RTO)는 약 4시간 이내이다. 초기 투자 및 유지 보수에 높은 비용이 소모되며, 데이터베이스 애플리케이션 등 데이터의 업데이트 빈도가 높은 시스템의 경우 사용한다.[3]
웜사이트
웜사이트(Warm Site)는 콜드사이트와 핫사이트의 절충 사이트이다. 이 사이트들에는 하드웨어가 있고 연결이 이미 확립되어 있지만 원래의 생산 사이트나 핫 사이트보다도 규모가 작은 편이다. 웜사이트는 직접 백업본을 갖출 수 있으나 완전하지 못할 수도 있다.[4] 핫사이트와 유사하나 재해복구센터에 주 센터와 동일한 수준의 정보기술자원을 보유하는 대신 중요성이 높은 정보기술자원만 부분적으로 재해복구 센터에 보유하는 방식이다. 고가의 장비와 응용프로그램, 리얼 데이터(real data)를 제외한 시설과 장비 준비, 가장 널리 사용하는 모델이다. 실시간 미러링을 수행하지 않으며 데이터의 백업 주기가 수 시간~1일 정도로 핫사이트에 비해 다소 길다.
미러사이트
미러사이트는 다른 웹사이트의 콘텐츠를 그대로 복사하여 갖고 있는 웹사이트 또는 컴퓨터 파일서버를 말한다. 다른 사이트의 정보를 거울처럼 그대로 복사하는 사이트라고 해서 ‘미러(mirror)’라는 이름이 붙었다. 이런 식으로 웹사이트의 파일을 동기화하는 것을 미러링이라고 부른다. 미러링의 목적은 데이터의 안정적 보존 및 본 서버에 문제가 생겼을 경우에 대한 대비이다. 미러링을 함으로써 본 서버의 접속자를 분산하거나 해당 웹페이지를 빠르고 가볍게 접속할 수 있다.[5] 접속량이 많은 사이트들은 과다한 트래픽으로 접속이 힘들거나 접속 속도가 떨어지는 경우가 있다. 이를 방지하기 위해 네트워크 이용 효율을 향상시키기 위한 목적으로 미러사이트가 개발되었다. 미러사이트를 이용하면 웹사이트나 파일의 가용성을 좋게 하고, 그 사이트에서 다운로드된 파일들이 미러사이트 부근에 있는 사용자들에게 보다 빨리 도착하게 한다.
미러사이트들은 원래 사이트가 지리적으로 어느 정도의 거리가 있을 때, 보다 빨리 액세스하기 위해 사용된다. 미러사이트는 파일의 배포 부담을 2개 이상의 파일서버로 분산하거나 통신량이 폭주하는 장거리 또는 국제 회선을 경우하지 않고, FTP 서사이트에 접근할 수 있게 하여 FTP 서버로부터 다운로드 될 수 있는 파일들에 대해서도 미러파일을 만들 수 있다. 다만 인터넷상에서 유명한 사이트의 경우 전 세계 몇 군데의 미러사이트가 있기 때문에 접속이 원활하지 않은 경우가 있어, 그런 경우에는 가까운 곳 또는 국내의 미러사이트를 이용하는 것이 바람직하다. 원래 사이트가 인터넷에 고속으로 접속되어 있지 않은 경우, 고속으로 접속되어 있는 대형 사이트에 미러사이트를 만든다면 아마도 보다 많은 방문객을 유지할 수 있을 것이다. 넷스케이프, 마이크로시스템즈, 썬 마이크로시스템즈, 그리고 다른 많은 회사들이 자신의 브라우저 소프트웨어를 다운로드 받을 수 있는 미러사이트들을 가지고 있다.[6] 한편 미러사이트는 원래 사이트의 정확한 복제품이어야 하므로 원래 사이트의 내용을 확실히 반영시키기 위해 보통 주기적으로 갱신된다는 특징이 있다.
상업사이트
상업사이트는 백업사이트 기능의 상용 공급자로부터 서비스를 계약할 때 조직은 계약 사용 조항 및 호출 절차를 기록해야 한다. 공급자는 다양한 서비스 수준에 따라 지정된 사이트 또는 시설에 두 개 이상의 조직에 가입할 수 있다. 서비스를 사용하는 모든 조직이 동시에 서비스를 필요로 할 가능성이 낮으며 공급자가 저렴한 비용으로 서비스를 제공할 수 있기 때문에 합리적인 제안이다. 그러나 광역지역에 영향을 미치는 대규모 사고에서는 이러한 시설이 과도하게 가입될 가능성이 높다. 조직은 공급자에게 우선 서비스를 요청할 수 있으며, 종종 월 수수료가 더 높은 경우가 많다. 상용사이트는 기본 데이터센터에 대한 본격적인 미러링 환경을 갖춘 보조 프로덕션 사이트로도 사용할 수 있다. 다시 말하지만, 더 높은 수수료가 필요하지만 사이트의 보안과 조직의 데이터가 및 응용 프로그램에 대한 중단없이 액세스할 수 있는 능력은 비용을 정당화할 수 있다.[7]
다른 백업 사이트
- 볼트프레스(VaulPress)
워드 프레스의 공동 설립자 맷 밀렌웨그에 의해 시작되었다. 볼트프레스는 지금 인기있는 제트팩(Jetpack) 플러그인의 일부이며 제트팩 백업으로 알려져있다. 플러그인은 실시간 백업 및 원 클릭 복원을 통해 신속하게 다시 온라인 상태가 될 수 있다. 포함된 활동 로그는 웹 사이트가 파산하기 전에 발생한 작업을 파악하여 문제를 진단할 수 있도록 도와준다. 제트팩은 두 가지 백업 옵션을 제공한다. 첫 번째로 일일 백업(대부분의 사이트에 적합)이 있고, 두 번째로 모든 편집으로 백업을 저장하는 실시간 백업이 있다.
- 백업버디(BackupBuddy)
백업버디는 접근 방식의 다른 백업 솔루션과 약간 다르다. 사용자의 전체 워드 프레스 설치를 백업한다. 필요한 경우 다른 서버에서 사이트를 복원하는 데 사용할 수 있는 전체 워드프레스 웹사이트의 다운로드 가능한 지퍼 파일을 얻을 수 있다. 백업은 데이터베이스만 백업하거나 특정 파일 또는 전체 사이트로 백업되도록 사용자 지정할 수 있다. 백업은 특정 시간에 실행되도록 예약하고 드롭박스(DropBox) 또는 구글(Google) 드라이브와 같은 오프사이트 위치로 전송될 수도 있다. 플러그인은 또한 쉽게 백업에서 웹 사이트를 복원 할 수 있다.
- 블로그볼트(BlogVault)
일부 대규모 복잡한 웹 사이트 또는 기반이 부족한 호스팅 서버의 경우 백업으로 라이브 사이트를 느리게 할 수 있다. 소프트웨어가 서버 리소스에서 실행되고 있기 때문이다. 블로그볼트 백업은 블로그볼트 서버에서 실행된다. 따라서 웹 사이트의 성능은 영향을 받지 않는다. 블로그볼트는 통합 스테이징을 제공하여 다른 백업 솔루션과도 분리된다. 그들의 스테이징 솔루션을 사용하면 라이브 웹 사이트로 푸시하기 전에 업데이트 및 변경 사항을 안전하게 테스트 할 수 있다. 스테이징 웹 사이트는 클라우드 서버에서 실행되며 추가 비용 없이 제공된다. 변경 사항에 만족하면 라이브 사이트로 쉽게 밀어 낼 수 있다. 블로그볼트는 또한 웹 사이트를 새 서버로 마이그레이션하는 데 도움이 된다. 간편한 한 번의 클릭 자동화로 가능하다. 또한 대시보드를 사용하면 여러 웹 사이트에 대한 백업, 준비 및 마이그레이션을 관리할 수 있다.
- 업드레프트플러스(Updraft plus)
업드레프트플러스는 많은 사람들이 사랑하는 무료 옵션이 있다. 무료 버전과 프리미엄 버전을 모두 사용하면 일정에 따라 웹 사이트를 백업하고 필요한 경우 복원 할 수 있다. 그러나 프리미엄 버전은 몇 가지 추가 기능과 함께 제공된다. 추가된 기능은 복제 및 마이그레이션, 증분 백업, 지원기능, 워드 프레스가 아닌 파일 및 데이터베이스 백업, 백업 워드 프레스 멀티사이트, 데이터베이스 암호화와 같은 추가 백업 옵션, 다른 플러그인에서 백업을 복원 하는 기능 그리고 광고가 없다. 무료 옵션은 많은 사람들에게 잘 작동하며, 특히 기술적으로 차이가 있을 경우 더욱 잘 작동한다.
- 중복기(Duplicator)
중복기는 1백만 개 이상의 웹 사이트에서 사용하는 또 다른 무료 백업 솔루션이다. 플러그인을 사용하면 도메인 또는 호스트 간에 가동 중지 시간이 없는 경우 워드프레스(WordPress) 사이트를 이동, 마이그레이션 또는 복제할 수 있다. 워드프레스 사이트 또는 사이트의 일부를 수동으로 백업한다. 그러나 가장 큰 제한은 워드 프레스 웹 사이트의 백업을 자동화, 예약할 수 없다는 점이다. 따라서 웹 사이트의 정기적인 백업을 만들기위한 강력한 경쟁자는 아니지만. 사이트 마이그레이션을 위한 백업을 만들거나 라이브 사이트를 로컬 호스트로 끌어내려 개발을 위해 필요한 사람들을 언급할 필요가 있다.[8]
각주
- ↑ 데이터 백업 및 복구: 기업을 위한 필수 가이드 베리타스 - https://www.veritas.com/ko/kr/information-center/data-backup-and-recovery
- ↑ Kevin Wood, 〈How to Backup Your Website & Why It’s Important〉, 《호스트 게이터》, 2019-04-30
- ↑ 고기는물풍선, 〈(정보보안기사)재해복구 시스템(백업 사이트)의 종류(미러 사이트, 핫 사이트, 웜 사이트, 콜드 사이트)〉, 《네이버 블로그》, 2019-06-09
- ↑ 백업 사이트 위키백과 - https://ko.wikipedia.org/wiki/%EB%B0%B1%EC%97%85_%EC%82%AC%EC%9D%B4%ED%8A%B8
- ↑ 미러 사이트 나무위키 - https://namu.wiki/w/%EB%AF%B8%EB%9F%AC%20%EC%82%AC%EC%9D%B4%ED%8A%B8
- ↑ 〈mirror site ; 미러사이트〉, 《텀즈》, 1999-11-04
- ↑ Backup site 위키백과 - https://en.wikipedia.org/wiki/Backup_site
- ↑ hristopher Lara, 〈The Best Backup Plugins for WordPress〉, 《트리디지털》, 2020-07-31
참고자료
- IT제이제이, 〈2차 사이트 종류별 특징〉, 《티스토리》, 2018-09-06
- Kevin Wood, 〈How to Backup Your Website & Why It’s Important〉, 《호스트 게이터》, 2019-04-30
- 고기는물풍선, 〈(정보보안기사)재해복구 시스템(백업 사이트)의 종류(미러 사이트, 핫 사이트, 웜 사이트, 콜드 사이트)〉, 《네이버 블로그》, 2019-06-09
- hristopher Lara, 〈The Best Backup Plugins for WordPress〉, 《트리디지털》, 2020-07-31
- 데이터 백업 및 복구: 기업을 위한 필수 가이드 베리타스 - https://www.veritas.com/ko/kr/information-center/data-backup-and-recovery
- 백업 사이트 위키백과 - https://ko.wikipedia.org/wiki/%EB%B0%B1%EC%97%85_%EC%82%AC%EC%9D%B4%ED%8A%B8
- Backup site 위키백과 - https://en.wikipedia.org/wiki/Backup_site
같이 보기
