"백업"의 두 판 사이의 차이
잔글 |
|||
(사용자 3명의 중간 판 15개는 보이지 않습니다) | |||
1번째 줄: | 1번째 줄: | ||
− | [[파일:백업.jpg|썸네일|400픽셀|백업]] | + | [[파일:백업.jpg|썸네일|400픽셀|'''백업'''(backup)]] |
− | '''백업'''(backup) | + | '''백업'''(backup)은 중요한 [[데이터]](data)나 [[프로그램]]을 다른 안전한 시스템이나 저장장치 또는 저장매체로 옮기거나 [[복사]]하여 [[보관]]하는 것을 말한다. 시스템 장애 시 백업 데이터를 풀어서 시스템을 복구할 수 있다. 또한, 정보 기술에서는 [[데이터 백업]](data backup)이라고 하며, 데이터를 미리 임시로 복제하여, 문제가 일어나도 데이터를 복구할 수 있도록 준비해 두는 것을 말한다. 데이터 백업을 수행한 파일은 [[백업 파일]]이라고 한다. 그리고 원본 데이터를 복사하여 다른 저장소에 저장하는 행위이므로 원본 데이터의 용량이 크다면 그만큼의 스토리지 공간과 데이터를 전달하는 네트워크 비용, 시간이 소요된다. |
==개요== | ==개요== | ||
− | + | 공공부문 정보화에 대한 예산투자가 증가함에 따라 업무 편의의 증진과 공공부문 대국민 서비스의 확대를 위한 공공기관의 정보시스템 도입이 점차 확산되고 있다. 이에 따라 오늘날 공공기관에서 사용되는 대부분의 정보들이 정보시스템을 통해 저장 관리 활용되고 있다. 정보시스템에 대한 업무의 의존도가 높아지고 있는 현 상황과 더불어 최근 바이러스 컴퓨터 범죄 각종 정보시스템 장애 인적 혹은 자연적 재해 재난 등 정보시스템의 원활한 운영을 방해하는 위협요소들이 다양한 원인을 통해 등장하고 있다 이에 따라 각 기관에서 운영되고 있는 정보시스템의 운영 및 유지보수를 위한 작업들이 정보화를 위한 중요한 기능으로 인식되고 있다. 백업은 백업 대상을 기준으로 크게 OS, 데이터베이스, 사용자 일반파일 및 기타파일 등으로 분류할 수 있다. | |
− | |||
− | |||
− | + | 백업은 비상 상황들에 대비하고 문제를 극복하기 위한 방법 중의 하나로써 정보시스템에 대한 백업을 생각할 수 있다 정보시스템 백업은 일반적으로 전산장비의 고장 및 기타 불의의 사고에 대비하여 파일 혹은 데이터를 복사해두는 행위를 의미한다. 공공기관 [[정보자원조사]]의 결과에 따르면 자체 백업시스템을 운영하는 기관은 설문 응답기관의 약 89.6%, 원격지 백업을 실시하는 기관은 약 16.7%에 이르고 있다. <ref name="사"> <[https://www.tta.or.kr/data/ttas_view.jsp?rn=1&rn1=Y&rn2=&rn3=&nowpage=1&pk_num=TTAS.KO-10.0253&standard_no=&kor_standard=%B9%E9%BE%F7+%C1%F6%C4%A7&publish_date=§ion_code=&order=publish_date&by=desc&nowSu=2&totalSu=2&acode1=&acode2=&scode1=&scode2= 정보시스템 백업 지침]>,《한국정보통신기술협회》, 2007-12-26 </ref> | |
− | |||
− | == | + | ==등장배경== |
− | 백업을 | + | 데이터라 함은 단순히 문서에 있는 내용을 전산 장치에 입력하는 것이었고 백업은 보관된 해당 문서(Paper)를 일컫는 것이었다. 그러나, 점차 [[IT]] 환경이 보편화되고, 데이터의 양이 증가함에 따라 미디어 형태로 백업을 받는 형태가 등장했다. 물론 이러한 미디어 형태의 백업이 지금도 일반적으로 수행하고 있는 백업의 형태라 할 수 있다. 또한, 미디어를 통한 백업도 단순히 오프라인에서 데이터를 직접 연결 저장장치(DAS) 형태로 구성된 미디어에 받아낸 후 보관하는 방식이었다. 이러한 것들 중 대표적인 백업 장치가 디지털 오디오 테이프(DAT)이다. 점차 백업의 양이 증가하고 좀 더 많은 수의 서버들을 사용하게 되자, 백업에 대한 용량이나 업무량이 증가하고, 백업을 위해 많은 시간을 할애해야 할 필요성이 대두됐다. 이에 따라 백업을 위한 전용 소프트웨어 및 백업 장치를 공유해 실제 백업 장치가 없는 서버들도 다른 서버의 백업 장치를 이용해 백업을 받을 수 있도록 하는 네트워크 백업이 등장했다. 네트워크 백업을 이용해 백업을 수행함으로써, 실제 백업에 대한 중앙 집중화가 가능하게 됐으며, 백업 관리 및 백업 장치의 효율적인 운영으로 백업에 대한 효율을 높여주는 계기가 됐다. 네트워크 백업은 백업에 대한 관리 및 백업 장치에 대한 비용을 줄여주는 효과가 있지만, 네트워크를 이용하기 때문에 네트워크에 부하가 가중되고 애플리케이션 성능에 영향을 주기도 한다. |
− | + | 또한 백업 성능이 직접 연결 저장장치 형태에 비해 많이 떨어진다는 단점도 있다. 이러한 단점을 극복하고, 네트워크 백업의 장점 및 고성능의 백업을 수행하기 위해 새롭게 등장한 것이 스토리지 에어리어 네트워크(SAN) 백업이다. 스토리지 에어리어 네트워크가 등장하면서, 이제는 백업에서도 스토리지 에어리어 네트워크를 통한 고성능의 백업 및 중앙 관리가 가능한 백업 형태가 나타났다. 직접 연결 저장장치 백업의 성능상 장점과 네트워크 백업의 중앙 집중 관리에 대한 장점만을 모아 백업을 구성한 것이 바로 SAN 백업이다. 현재에는 이러한, 스토리지 에어리어 네트워크 기반의 환경을 기초로 백업에 대한 많은 기법들이 개발됐다. 온라인 중에 데이터베이스를 받을 수 있는 백업과 복제 볼륨을 이용해 손쉽게 수행하는 백업, 또한 서버에 전혀 부하를 주지 않고 백업을 진행할 수 있는 서버리스 백업들이 등장했다. 뿐만 아니라 백업에 대한 관점에서 점차 복구에 대한 관점으로 옮아감에 따라, 얼마나 백업을 빠르고 정확하게 수행하느냐에서 얼마나 복구를 손쉽고 빠르게 진행하는가에 초점을 맞춘 백업 솔루션 및 제품들이 출시되고 있다.<ref name="라">ppp , <[https://m.blog.naver.com/PostView.nhn?blogId=xcicix&logNo=60004876699&proxyReferer=https:%2F%2Fwww.google.co.kr%2F 백업솔루션의 등장배경및개요]>, 《네이버 블로그》, 2004-08-12 </ref> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | 백업 | ||
− | |||
− | |||
− | |||
− | === | + | ==특징== |
− | + | ===필요성=== | |
− | + | 백업을 하지 않는다는 것은 두 가지로 해석할 수 있다. 한 가지는, 데이터가 손상되더라도 업무 혹은 데이터의 손실에 그다지 영향이 없는 경우일 것이다. 또한, 다른 하나는, 데이터에 대한 가용성이 100%여서 백업을 받을 이유가 없는 경우이다. 물론, 첫번째의 경우는 선택적으로 가능할 수 있지만, 두번째처럼 100%의 가용성을 가진다는 것은 현재 IT 환경에서는 거의 불가능한 일이다. 일반적으로 가용성을 이야기할 때, 99.99%나 99.999% 등의 수치를 1년 동안의 시스템 가용성을 판단하는 기준으로 사용하고 있다. 그러나 이는 데이터에 대한 가용성이라기보다는 업무의 연속성에 대한 판단 기준이라고 볼 수 있다. 따라서 결론적으로 백업은 어떠한 경우라도, 데이터에 대한 보호 측면에서 반드시 수행해야만 하는 필수 요소이다.<ref name="라"></ref> | |
− | + | ; 피해 사례 | |
+ | *'''랜섬웨어'''(ransomware) : 컴퓨터 시스템을 감염시켜 접근을 제한하고 일종의 몸값을 요구하는 악성 소프트웨어의 한 종류이다. 컴퓨터로의 접근이 제한되기 때문에 제한을 없애려면 해당 악성 프로그램을 개발한 자에게 지불을 강요받게 된다. 이때 암호화되는 랜섬웨어가 있는 반면, 어떤 것은 시스템을 단순하게 잠그고 컴퓨터 사용자가 지불하게 만들기 위해 안내문구를 띄운다.<ref> 랜섬웨이 위키백과 - https://ko.wikipedia.org/wiki/%EB%9E%9C%EC%84%AC%EC%9B%A8%EC%96%B4#주요_사례</ref>2020년 7월 28일, 웨어러블 제조업체 [[가민]](garmin)이 랜섬웨어 공격에 스마트워치 서비스 먹통을 먹었다. | ||
+ | *'''KT IDC 센터 화재''' : 2018년 11월 24일 오전 11시 12분, 서울특별시 서대문구 충정로3가에 위치한 KT 아현지사 건물의 지하 통신구에서 화재가 발생하여 일대 KT망을 사용하는 기기들의 유·무선 통신 장애가 발생한 사고다. 이 사고로 중구 , 용산, 서대문, 마포 인근 통신망이 모두 먹통이 되어 불편함을 겪었다. 통신망 장애로 남대문 경찰서에서는 비상벨이 오작동하기도 했다. 이 사건은 화재 원인도 밝혀내지 못한 사건이 되었다. | ||
+ | *'''AWS(amazon web service) 서울 리전 DNS 설정 실수''' : 2018년 11월 22일 오전 AWS 서울 리전의 일부 DNS 서버 설정이 잘못되어 84분 동안 Amazon EC2 인스턴스의 DNS 확인을 방해하는 일이 발생한 사고다. DNS 확인 문제의 근본 원인은 설정 업데이트 시 서울 리전의 EC2 DNS 확인 서버군의 최소 정상 호스트를 지정하는 설정을 잘못 제거한 것이었다. 이로 인해 최소한의 정상 호스트 구성 기본 설정 값이 매우 낮은 것으로 해석되어, 정상 서비스 호스트 숫자가 줄어들었다. EC2 DNS 확인 서버군의 정상 호스트 용량이 감소함에 따라, 고객 EC2 인스턴스 내의 DNS 쿼리가 실패하기 시작했다. AWS 엔지니어링 팀에게 오전 8시 21분에 서울 리전 내의 DNS 확인 문제가 통보되었고, 즉시 문제 해결에 나섰다. AWS는 먼저 더 이상 정상 호스트가 서비스에서 제거되는 것을 방지함으로써 추가적인 영향이 없음을 확인했다. 이 작업에 15분이 추가로 소요되었다. 이후 서비스 용량을 이전 수준으로 복원했으며, 한국 시간 오전 9시 43분에 EC2 인스턴스의 DNS 질의 문제를 완전히 복구했다..<ref name ="자">〈[https://aws.amazon.com/ko/backup/ AWS Backup]〉, 《아마존》</ref> | ||
− | == | + | ===관련 용어=== |
− | + | *'''시스템 백업''' : 컴퓨터의 시스템 파일(OS 영역,시스템 설정파일 ,시스템로그 등)에 대한 정기적인 백업을 의미한다. 데이터 백업과 구별하여 보통 OS(Operating System) 백업이라고 일컫는다. | |
− | + | *'''데이터 백업''' : 시스템 영역을 제외한 모든 파일에 대한 백업을 의미한다 백업대상에는 개발자 소스파일, 응용프로그램 파일, 데이터 관련 파일 등이 있다. | |
− | |||
− | |||
− | + | *'''백업 시스템''' : 백업시스템은 백업을 구성하는 장비나 장치를 의미한다 시스템 및 데이터 . 백업을 수행하기 위한 모든 하드웨어, 소프트웨어 및 인프라(전원, 공간, 인력)를 총칭하는 의미로 사용하며 때로는 장애를 대비한 이중화 시스템을 칭하기도 한다. | |
− | |||
− | |||
− | + | *'''백업 장비''' : 백업시스템을 구성하기 위해 필요한 매체 라이브러리 채널 등의 물리적인 설비를 의미한다. 백업 장비와 백업 장치는 동일한 용어로 정의한다. | |
− | + | ||
− | + | *'''백업 매체''' : 백업된 데이터를 저장하여 보관하기 위한 물리적 저장소로서, 테이프와 디스크가 대표적이다. | |
− | + | ||
− | + | *'''가상 테이프 라이브러리'''(VTL) : 디스크를 백업매체로 활용하는 방식의 하나로서, 디스크를 여러 개의 가상 테이프 및 드라이브로 구성된 라이브러리 시스템으로 인식시켜 디스크를 마치 테이프 백업 장비와 같이 사용하는 기술을 말한다. | |
+ | |||
+ | *'''소산 백업''' : 백업 실시 후 재난 및 재해에 대비하여 백업 테이프를 원격지의 안전한 곳에 보관하는 경우, 이를 [[소산 백업]] 또는 [[볼팅]](vaulting)이라 한다. | ||
+ | |||
+ | *'''전산센터''' : 고객사 사업장과 분리되어 정보시스템을 물리적으로 구성하고 운영 관리하는 인프라 설비 및 시설을 의미한다. 전산센터에서는 정보시스템의 물리적인 관리, 논리적인 OS 관리, 시스템 소프트웨어 운영, 백업 및 복구 서비스를 수행한다 주로 대규모의 사업을 수행하는 기관에서 별도로 구축하거나 별도의 전산센터에 [[아웃소싱]]을 의뢰하여 운영한다. 전산센터의 경우 별도의 독립된 장소(건물, 층)에 운영하는 것이 일반적이다. | ||
+ | |||
+ | *'''전산실''' : 서비스 프로그램 개발 및 정보시스템을 운영 관리하는 개발자 및 운영자가 상주하는 공간이다. 전산실의 위치는 현업부서에 근접하여 운영되거나 별도의 대규모 전산센터 내에 위치하여 운영될 수 있다. | ||
+ | |||
+ | *'''백업센터''' : 현재 사용 중인 전산 인프라를 운영하는 주 전산센터에 반하여 장애 및 재해에 대비하여 업무연속성(continuity)을 보장할 수 있는 재해복구를 위한 백업 전산센터를 의미한다. | ||
+ | |||
+ | *'''백업 구성 방식''' : 백업시스템을 구성하는 형태 및 특징을 의미한다. 백업 솔루션을 구분하기 위해 크게 로컬(다이렉트) 백업, 네트워크 백업, SAN(Storage Area Network) 백업 으로 나뉘어 지며 백업 규모, 시간 및 특성에 따라 그 구성 방식이 결정된다. | ||
+ | |||
+ | *'''디스크 복제''' : 중요한 업무에서 주로 적용하는 디스크 백업 솔루션 중 하나로써 디스크의 이미지를 다른 디스크로 빠르게 복제하는 기술을 의미한다. 복제의 속도가 빠르고 복구 역시 용이하며, 보통 디스크 제공사의 복제 솔루션을 많이 사용한다. | ||
+ | |||
+ | *'''미러링''' : 디스크의 [[RAID]](Redundant Array of Independent Disks) 레벨 중 RAID 1에 해당하는 디스크 구성방법으로써 한 개의 디스크에 물리적 장애가 발생하더라도 미러링 되어 있는 디스크가 자동으로 장애가 발생한 디스크를 대체하여 서비스를 지속할 수 있다. 주로 OS 디스크 및 중요한 데이터 보관 부분에 많이 사용한다.<ref name="사"></ref> | ||
+ | |||
+ | ===종류=== | ||
+ | ;테이프 | ||
+ | *'''18-트랙 테이프''' : 가장 오래된 형태의 테이프 매체로서, 이것은 둥근릴 주위를 1/2인치 너비의 테이프가 감겨있는 형태이다. 테이프는 수 십 년 동안 전형적인 백업 매체로 한 종류 이상의 자기 테이프가 사용되었고, 이는 그 크기와 형식에 있어서 매우 다양하게 발전해 왔다. 자기 테이프는 폴리에스텔 테이프의 표면에 자성 물질을 입힌 것으로 속도는 느리나, 테이프 자체를 별도 보관하는 것이 가능하며, 기억용량이 크고, 재생하여 다시 사용할 수 있을 뿐만 아니라 가격이 저렴하다. 오랫동안 사용되어 왔으나 부피가 너무 크고, 하드웨어가 비싼 편이며, 하나의 테이프에 약 255 MB 정도가 저장된다. 따라서 요즘과 같은 대용량 디스크를 사용하는 상황에서는 하나의 디스크를 백업받기 위해 여러 번 새로운 테이프를 교체해야 한다. | ||
+ | |||
+ | *'''8mm 테이프''' : 비교적 빠르고 큰 용량을 가지고 있기 때문에 운영자가 중간에 개입할 필요 없이 백업을 수행할 수가 있다. 또한 크기가 작아서 테이프를 보관하는데 필요한 공간을 줄이고, 떨어져 있는 외부 저장장치를 쉽게 쓸 수 있다. 하지만 드라이브 구조가 약간 복잡하다는 단점이 있다. | ||
+ | |||
+ | *'''4mm 테이프''' : 음질의 오디오를 녹음하기 위해 만들어진 것으 로 많은 장비업체가 이 테이프를 사용하는 드라이브를 제공하고 있다. 디지털 오디오 테이프(DAT) 테이프는 현재 이용 가능한 마그네틱 매체 중에서 가장 작으나, 8mm 테이프보다 훨씬 빠르고 드라이브도 안정적으로 동작한다. | ||
+ | |||
+ | *'''카트리지 테이프''' : 평상시에는 주로 백업 라이브러리 내에 보관되며, 백업 및 복구 시 자동제어 로봇팔에 의해 백업 드라이브에 삽입되어 사용된다. 최근에는 한 개의 카트리지 테이프 용량이 수백GB에 이르며 저장 시 압축기술을 이용하면 원래 용량의 2배 이상을 백업할 수도 있다.<ref name="사"></ref> | ||
+ | |||
+ | ;디스크 | ||
+ | *'''플로피 디스크''' : 대부분의 소형 컴퓨터 시스템에서는 플로피 디스크 드라이브를 사용하고 있다. 플로피 디스크는 값이 싸고, 신뢰성 있는 매체이지만 용량이 매우 적다. 즉 큰 파일을 전체 백업하는데 수 백 개의 디스켓이 필요하므로, 사실상 백업 매체로서는 적절한 것은 아니다. 그러므로 부팅 정도를 위한 용도로 사용되고 있다. | ||
− | + | *'''고용량 광자기 디스크''' : 광자기 디스크의 너비와 길이는 플로피 디스크와 같지만 두께는 두 배 정도가 된다. 플로피 디스크보다 훨씬 더 많은 자료를 담을 수 있으며 데이터를 기록할 때는 마그네틱 방식을 사용하여 쓰게 되지만, 읽을 때는 광학 방식을 사용하기 때문에 다른 자기 매체보다 더 안전하다고 할 수 있다. 하지만, 드라이브와 디스크의 값이 고가이므로 흔히 사용되지는 않는다. | |
− | + | ||
− | + | *'''CD/DVD-ROM''' : 합성수지와 금속 재료의 원반에 데이터를 기록하여 레이저로 읽어내는 방식의 저장매체이다. 일반적인 디스크나 다른 마그네틱 저장매체보다 내구성이 좋고 보관이 용이하여 보통 장기 보존 문서와 같은 자료들을 오랫동안 보관하기 위한 목적으로 많이 쓰인다. | |
− | |||
− | + | *'''하드 디스크''' : 파일시스템에 있는 자료를 물리적으로 분리된 다른 하드 디스크에 백업하여 둘 수도 있다. 단, 이 방법은 일반적인 테이프 백업장치를 사용 하는 것에 비해 고비용이 든다.<ref name="사"></ref> | |
− | + | ;대상별 분류 | |
+ | *'''운영체제'''(Operating System) | ||
+ | : 사용자가 컴퓨터를 쉽게 다룰 수 있게 해주는 인터페이스이다. 대부분 운영 체제 전공책을 보면 OS에 대한 정의를 엄밀하게 하지 않는다. 컴퓨터 자원을 효율적으로 관리하기 위한 시스템, 공통된 소프트웨어 플랫폼, 컴퓨터 응용 프로그램 관리자 등으로 다양하다. 드라이버는 대개의 경우 OS를 거쳐서 설치되므로 운영 체제는 펌웨어 다음으로 하드웨어와 가장 직접적으로 관련되는 소프트웨어이다. 운영 체제는 하드웨어와 소프트웨어를 관리하는 소프트웨어 전체라고 할 수 있다. 이러한 운영체제는 어느 기기에서 어떠한 형태로도 나타날 수 있다. 비단 PC용 윈도우만이 운영체제가 아니고, MP3 플레이어를 켜면 전원이 들어와 장치를 깨우고 사용자의 명령에 따라 음악을 재생하는 동작들을 관리하는 것들도 전부 운영 체제라 할 수 있다. 단, 이런 식으로 전자기기에 공장 출고시 설치되며 애플리케이션 설치를 통한 기능 추가를 할 수 없는 것은 보통 [[펌웨어]](firmware)라고 부른다.<ref> OS 나무위키 - https://namu.wiki/w/%EC%9A%B4%EC%98%81%20%EC%B2%B4%EC%A0%9C </ref> | ||
− | + | :서버의 운영체제나 시스템 구성 파라미터 파일 및 시스템 로그 파일이 그 대상이다. 보통 월 1회 혹은 시스템 변경 시 시스템 백업을 실시하여야 하며 백업 및 복구가 간편한 디지털 오디오 테이프를 많이 이용한다. 시스템 최초 설치 및 업그레이드, 버그 패치 등의 작업 후에도 이미지 백업을 실시 후 보관한다.<ref name="사"></ref> | |
− | |||
− | |||
− | + | *'''데이터 베이스''' : 통합하여 관리되는 데이터의 집합체를 의미한다. 이는 중복된 데이터를 없애고, 자료를 구조화하여, 효율적인 처리를 할 수 있도록 관리된다. 따라서, 여러 업무에 여러 사용자가 데이터 베이스를 사용할 수 있다. 이러한 데이터베이스는 응용 프로그램과는 다른 별도의 미들웨어에 의해 관리된다. 데이터베이스를 관리하는 이러한 미들웨어를 데이터베이스 관리 시스템(DBMS)이라고 한다.<ref><[http://tcpschool.com/mysql/DB 데이터 베이스]> ,《티씨피 스쿨》</ref> | |
− | + | :데이터베이스의 데이터파일 및 컨트롤 파일 변경로그 파일 등이 그 대상이다. 이외에도 데이터베이스 엔진이나 구성파일 자체도 주기적으로 또는 변경작업 전에 백업하여야 한다.<ref name="사"></ref> | |
− | *''' | ||
− | |||
− | |||
− | *''' | + | *'''사용자 일반파일''' : 사용자 데이터, 개발자 소스 파일, 응용 소프트웨어 등이 그 대상이다. 백업 시기로는 일일 주요 파일(개발소스) 백업, 주 1회 전체 백업, 월 회 1 전체 백업, 사용자의 요구 시에 발생하는 비정기적인 백업 등이 있다.<ref name="사"></ref> |
− | : | ||
− | === | + | ===방식=== |
− | *''' | + | ====전통적인 백업 방식==== |
− | + | [[파일:전체 백업.jpg|썸네일|400픽셀|전체 백업]] | |
+ | [[파일:증분 백업.jpg|썸네일|400픽셀|증분 백업]] | ||
+ | [[파일:치등 백업.jpg|썸네일|400픽셀|차등 백업]] | ||
+ | |||
+ | * '''전체 백업'''(full backup) : 변경(changed) 데이터나 고유(unique) 데이터를 전혀 구분하지 않고 백업할 때마다 모든 데이터의 복사본을 만드는 백업 방식이다. 전체 백업은, 복구 시에 일부 다른 백업 방식보다 간편하고 시간이 증분 백업에 비해 상대적으로 덜 걸린다는 장점이 있다.<ref name="나">감자 , 〈[https://m.blog.naver.com/PostView.nhn?blogId=kamza81&logNo=40043289025&proxyReferer=https:%2F%2Fwww.google.co.kr%2F 백업 종류]〉, 《네이버 블로그》, 2007-10-17</ref> | ||
+ | |||
+ | * '''증분 백업'''(incremetal Backup) : 전체 백업과는 달리 최종 전체 백업 혹은 최종 증분 백업 이후에 변경된 파일만을 복사한다. 전체 백업과 비교할 때 증분 백업은 매일 백업해야 하는 파일의 양이 적어 빠른 백업 윈도가 가능하다는 점이 장점이다. 그러나 복구 과정에서는 최종 백업된 전체 및 모든 후속 증분 이미지나 복사본까지 복구해야 하기 때문에 복구 작업이 번거로워지고 경우에 따라서는 시간이 훨씬 더 걸릴 수 있다.<ref name="나"></ref> | ||
+ | |||
+ | *'''차등 백업'''(differential backup) : 마지막 전체 백업 이후 변경된 모든 데이터를 백업하는 방식이다. 이는 바로 이전의 전체 백업 혹은 증분 백업 이후 변경된 데이터만 복사하는 증분 백업과는 다르다. 일단 파일이 변경되면 예정된 다음 전체 백업 시까지 매일 백업한다. 따라서 파일이 변경될 때마다 파일 크기가 증가하게 되며, 다음 전체 백업 때까지 파일 크기가 점점 커지게 된다. 하지만, 전체 백업 이미지와 가장 최근의 차등 이미지만 복구하면 되기 때문에 복구 시점에 따라 다르긴 하지만 대개 증분 백업보다 복구 속도가 빠르다.<ref name="나"></ref> | ||
+ | ====다른 백업 방식==== | ||
+ | [[파일:신센틱 백업.jpg|썸네일|400픽셀|신센틱 백업]] | ||
+ | [[파일:중복제거 백업.jpg|썸네일|400픽셀|중복제거 백업]] | ||
+ | |||
+ | ;신센틱 백업 | ||
+ | 신센틱 백업(Synthetic Backup)은 선택된 폴더의 전체백업 이후 변경, 추가된 데이터(data)를 증분 백업(Incremental Backup) 형식으로 저장 후 두번째 Full 백업 작업시 중간에 모아 둔 Incremental bakcup을 이용하여 전체 백업(Full Backup)으로 재생성 하는 방식이다.백업 서버에 data를 백업 서버에서 다시 한번 모두 복사(copy) 하면서 전체백업을 만들 수도 있다. 카탈로그(catalog) 정보만으로 백업본을 생성하는 제품도 있다.기본적인 백업은 [[네트워크]]를 이용해서 데이터를 가져와 백업 서버(backup server)에 저장 한다. 신센틱 백업을 이용하면 백업 서버에서 이미 저장되어 있는 증분 데이터(Incremental Data)를 이용해 Full Backup을 새로 만들기 때문에 Network 사용량을 줄일 수가 있다.<ref name="다">관리자(쉐어드아이티) , 〈[https://www.sharedit.co.kr/posts/427 백업 방식에 대해 알아 보자!!]〉, 《쉐어드아이티》, 2017-11-06</ref> | ||
+ | |||
+ | ;중복제거 백업 | ||
+ | 중복제거 백업(Deduplication Backup)은 한개의 파일 혹은 여러개의 파일에서 동일한 부분은 하나만 저정하고 나머지 파일 구조는 메타 데이타로 따로 저장하여 백업 저장소와 백업 데이터를 줄일 수 있다. 백업 소프트 위에는 파일단위 백업이 기본이기 때문에 파일의 사이즈에 관계없이 변경되면 변경된 파일 을 모두 백업하도록 동작 한다. 중복제거 기술은 섹터 단위로 파일을 검사하기 때문에 변경된 섹터의 값만 다시 백업한다. 증분 및 차등 백업과 중복제거 변경된 파일을 가져 온다는 의미에는 큰 차이점이 없다. 그러나, 실제로 백업 소프트웨어에서 동작할때 차이점이 발생 한다. 증분 및 차등을 200MB의 200장의 화면을 가진 파워 포인트가 있다고 가정하면, 중복 제거와의 차이점은 다음과 같다.<ref name="다"></ref> | ||
+ | |||
+ | * '''증분 및 차분''' | ||
+ | # 전체 백업(full Backup)을 실행 하면 200MB의 파일을 받아 온다. | ||
+ | # 200장의 화면중 2장이 변경 한다. | ||
+ | # 200MB의 파일의 변경 인식 후 200MB를 다시 받아 온다. | ||
+ | |||
+ | * '''중복제거''' | ||
+ | # 전체 백업을 실행 하면 200MB의 파일을 받아 온다. | ||
+ | # 200장의 화면중 2장이 변경 한다. | ||
+ | # 200MB의 파일의 변경 인식 후 변경된 섹터의 값만 받아 온다. | ||
− | + | ====라이브 백업==== | |
− | + | 라이브 백업은 온라인 백업이나 실시간 백업으로도 불리며, 컴퓨터나 데이터베이스가 운영 중인 상태에서 백업하는 것을 말한다. 인포믹스 데이터베이스의 공식적인 백업 유틸리티인 온바(Onbar:Online Backup and Recovery)에서 온라인 백업이라는 용어를 사용하면서 온라인 백업은 데이터베이스를 중단시키지 않고 백업한다는 개념으로 발전하였고, 라이브 백업은 컴퓨터가 운영 중인 상태에서 실시간 백업한다는 의미로 정해지고 있다. 라이브 백업을 할 수 있는 조건을 가질려면 운영 중 백업, 실시간 감시, 백그라운드 실행, 운영 환경에 부하 최소화 정도의 조건을 만족해야 한다.<ref>라이브 백업 위키백과 - https://ko.wikipedia.org/wiki/%EB%9D%BC%EC%9D%B4%EB%B8%8C_%EB%B0%B1%EC%97%85 </ref> | |
− | |||
− | *''' | + | *'''에이전트 기반''' : 컴퓨터에 설치된 에이전트가 데이터의 변화를 감지하고 이를 실시간 백업한다. |
− | + | *'''스토리지 기반''' : 데이터가 저장된 외장 스토리지에서 데이터의 변화를 블록-레벨로 감지하여 백업한다. | |
− | == | + | ===서비스=== |
− | + | ; 국내 서비스 | |
− | ''' | + | * '''스마트 스위치'''(smart switch) : 삼성전자에서 모바일과 PC에서 이용 할 수 있는 백업을 지원하는 서비스이다. 휴대전화 네트워크 유무와 관계 없이 사용자의 PC또는 SD카드에 백업이 가능하다. 다만 PC와 SD카드라는 별도의 저장공간을 필요로 할 수 있다. |
− | + | *'''모바일 스위치'''(mobile switch) : [[엘지전자㈜]]에서 스마트폰간 백업 및 데이터 이동을 지원하는 백업 서비스이다. 이동 가능한 데이터 종류는 주소록, 메시지, 통화기록, 캘린더, 음성녹음, 사진, 동영상, 음악, 문서, 메모, 다운로드앱,공인인증서, 기타 설정 항목 등을 새로운 LG 스마트폰으로 옮길 수 있다. | |
− | ''' | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | ; 국외 서비스 | |
− | ''' | + | *'''아마존 웹 서비스 백업'''(amazon web service backup, aws backup) : [[아마존]]에서 지원하는 완전관리형 백업 서비스로, AWS 서비스 전체에 걸쳐 데이터 백업을 쉽게 중앙 집중화하고 자동화할 수 있다. AWS 백업을 사용하면 백업 정책을 중앙에서 구성하고 Amazon EBS 볼륨, Amazon EC2 인스턴스, Amazon RDS 데이터베이스, Amazon DynamoDB 테이블, Amazon EFS 파일 시스템 및 AWS Storage Gateway 볼륨과 같은 AWS 리소스의 백업 활동을 모니터링할 수 있다. AWS Backup에서는 이전에 서비스별로 수행되던 백업 작업을 자동화하고 통합하므로, 사용자 지정 스크립트와 수동 프로세스를 생성할 필요가 없다. AWS Backup 콘솔에서 클릭 몇 번이면 백업 일정과 보존 관리를 자동화하는 백업 정책을 생성할 수 있다. AWS Backup은 완전관리형 정책 기반 백업 솔루션을 제공하여 백업 관리를 간소화하고 비즈니스 및 규제상의 백업 규정 준수 요구 사항을 충족할 수 있도록 지원한다.<ref name="자">〈[https://aws.amazon.com/ko/backup/ AWS Backup]〉, 《아마존》</ref> |
+ | *'''아이클라우드 백업'''(iCloud backup) : [[애플]]에서 지원하는 백업 서비스로, [[와이파이]](Wi-Fi) 네트워크(network)로 연결하면 iCloud를 사용하여 기기의 백업을 만들 수 있다. 기기를 컴퓨터에 연결하지 않아도 또는 집에 있지 않아도 iCloud를 사용하여 백업할 수 있다. iCloud 백업에는 기기에 저장된 거의 모든 데이터와 설정이 포함된다.<ref>〈[https://support.apple.com/ko-kr/HT204136 iPhone, iPad 및 iPod touch 백업에 관하여]〉, 《애플》</ref> | ||
+ | *'''구글 드라이브'''(google drive) : [[구글]]에서 제공하는 클라우드 기반 협업도구이자 파일저장/공유 백업도 할 수 있는 서비스다. | ||
− | + | ===복구=== | |
+ | 완전 복구(Bare Metal Recovery, BMR)라고 불리는 과정은 시스템을 재설치하는 경우, 즉 아무런 운영 체제나 응용 프로그램도 설치되지 않은 시스템에 전체 시스템 백업을 복구하는 경우를 말한다. 또한, 재설치 후 복구하는 방법으로 완전히 새 컴퓨터를 구입했을 때처럼 기본 운영 체제를 설치한 후 적절한 설정 작업을 마치고 남은 디스크 드라이브를 파티션 분할하여 포맷한 후 백업 매체에서 모든 백업을 복구하는 방법이있다. 시스템 복구 디스크는 최소 시스템 환경을 포함한 부팅 매체로서 가장 기본적인 시스템 관리자 작업을 수행할 수 있게 해준다. 복구 환경에서는 디스크 드라이브를 파티션하고 포맷 가능한 필수 유틸리티 및 백업 장치에 액세스하는데 필요한 장치 드라이버와 백업 매체에서 데이터를 복구하는데 필요한 소프트웨어를 사용한다. 완전 복구를 위한 복구 절차는 다음과 같다.<ref name="바"> 〈[http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-isa-ko-4/s1-disaster-backups.html 시스템 관리 안내서 8장. 재난 방지 계획 세우기]〉, 《엠아이티》</ref> | ||
− | + | * '''복구 절차''' | |
− | + | # '''장애 원인 파악''' : 정보시스템에 장애가 발생하면 먼저, 장애 원인, 영향범위 및 장애유형 등을 파악해야 한다. 장애 원인 및 범위, 유형에 따라 장애를 복구하기 위해 백업본에 대한 리스토어가 필요한지 여부를 포함한 세부적 장애복구 절차를 결정하고, 이에 따라 장애복구 예상시간 및 사전 준비사항을 마련하여야 한다. | |
+ | # '''복구대상 확인''' : 시스템 장애 해결책으로 백업본의 리스토어 의사결정이 되면 복구가 요구되는 시점에 유의하여, 백업본을 식별하고 백업 데이터의 정상 유무를 확인하여 복구 작업을 준비한다. 실제로 장애 발생시 백업본을 활용하여 복구를 수행하는 의사결정을 하는 것이 쉽지 않으며 시간도 많이 걸린다. 따라서 장애 유형별 복구 전략을 사전 정의하여 의사결정 시간을 단축하는 것이 장애시간을 최소화하는 데 도움이 된다. | ||
+ | # '''복구 수행''' : 복구방법에 대한 의사결정이 나고 복구 대상에 대한 백업본을 식별하여 복구할 준비가 끝나면 실제 복구 작업을 수행한다. | ||
+ | # '''검증''' : 복구 작업이 끝나면 업무 담당자 협조 하에 복구 작업의 유효성 및 데이터의 무결성을 검증한다. 검증이 완료된 후에 시스템을 정상적으로 서비스에 투입 할 수 있다. 복구작업이 불완전한 상태에서 검증을 거치지 않고 서비스를 투입하면 향후 데이터 정합성에 치명적인 손상을 야기할 수 있으므로 주의한다.<ref name="사"></ref> | ||
− | == | + | ==백업정책 수립== |
− | + | 백업정책의 수립은 크게 업무중요도 파악, RTO, RPO 설정, 백업가능시간 및 백업대상 데이터 분석 등을 수행하는 백업환경분석 단계를 거쳐 백업주기, 보관기간, 백업수행시간, 백업방법 등의 각 요소별의 백업정책을 수립하는 절차를 따르게 된다. 먼저, 백업 정책의 수립을 위해서는 업무 분석을 통해 업무의 중요도를 객관적인 기준으로 분류하여야 한다. 여러 업무가 있는 경우, 중요도가 비슷한 업무들을 그룹화하여 몇 개의 업무 그룹으로 분류할 수도 있다. 예를 들면, 직접적으로 대국민 서비스 중 민원처리와 관련된 업무들은 기관의 신뢰성과 직접 관련되어 있으므로 매우 중요한 업무 그룹이라고 생각할 수 있다. 이렇게 업무별 중요도가 설정된 다음에는, 업무의 흐름을 파악하여 백업을 수행하기 위한 최적의 시간대(백업시간 또는 백업윈도우)를 찾아내어야 한다. 이는 백업된 데이터가 복구시 최대한 유효한 데이터가 되도록 하고 백업시간 동안 서버 부하 등으로 인한 업무 영향도를 최소화하기 위함이다. 또한, 백업대상이 되는 데이터의 종류와 용량을 파악하여야 한다. 데이터의 종류에는 [[운영체제]](OS), [[데이터베이스]], 일반 파일 등이 있으며, 이러한 데이터의 종류와 용량에 따라 백업 정책의 결정에 영향을 미치게 된다. 마지막으로, 업무중요도에 따라 분류된 업무그룹 및 개별업무의 각 데이터별로 백업주기, 보관기간을 결정해야 한다. 이때, 백업정책의 수립 과정을 효율화하고 여러 업무 담당자의 상이한 의견을 수렴하는 가이드가 될 수 있도록 하기 위하여, 각 기관별로 표준백업정책을 수립함으로써 백업 정책의 표준화와 일관성의 향상을 도모할 수 있다.<ref name="사"></ref> | |
{{각주}} | {{각주}} | ||
− | == | + | == 참고자료== |
* 백업 위키백과 - https://ko.wikipedia.org/wiki/%EB%B0%B1%EC%97%85 | * 백업 위키백과 - https://ko.wikipedia.org/wiki/%EB%B0%B1%EC%97%85 | ||
− | * 라이브 백업 위키백과 - https://ko.wikipedia.org/wiki/%EB%9D%BC%EC%9D%B4%EB%B8%8C_%EB%B0%B1%EC%97%85 | + | * 라이브 백업 위키백과 - https://ko.wikipedia.org/wiki/%EB%9D%BC%EC%9D%B4%EB%B8%8C_%EB%B0%B1%EC%97%85 |
* ppp, <[https://m.blog.naver.com/PostView.nhn?blogId=xcicix&logNo=60004876699&proxyReferer=https:%2F%2Fwww.google.co.kr%2F 백업솔루션의 등장배경및개요]>, 《네이버 블로그》, 2004-08-12 | * ppp, <[https://m.blog.naver.com/PostView.nhn?blogId=xcicix&logNo=60004876699&proxyReferer=https:%2F%2Fwww.google.co.kr%2F 백업솔루션의 등장배경및개요]>, 《네이버 블로그》, 2004-08-12 | ||
+ | * 랜섬웨이 위키백과 - https://ko.wikipedia.org/wiki/%EB%9E%9C%EC%84%AC%EC%9B%A8%EC%96%B4#주요_사례 | ||
* 감자 , 〈[https://m.blog.naver.com/PostView.nhn?blogId=kamza81&logNo=40043289025&proxyReferer=https:%2F%2Fwww.google.co.kr%2F 백업 종류]〉, 《네이버 블로그》, 2007-10-17 | * 감자 , 〈[https://m.blog.naver.com/PostView.nhn?blogId=kamza81&logNo=40043289025&proxyReferer=https:%2F%2Fwww.google.co.kr%2F 백업 종류]〉, 《네이버 블로그》, 2007-10-17 | ||
− | * 관리자(쉐어드아이티) , 〈[https://www.sharedit.co.kr/posts/427 백업 방식에 대해 알아 보자!!]〉, | + | * 관리자(쉐어드아이티) , 〈[https://www.sharedit.co.kr/posts/427 백업 방식에 대해 알아 보자!!]〉, 《쉐어드아이티》, 2017-11-06 |
− | *〈[https://aws.amazon.com/ko/backup/ AWS Backup]〉, | + | *〈[https://aws.amazon.com/ko/backup/ AWS Backup]〉, 《아마존》 |
− | * | + | * OS 나무위키 - https://namu.wiki/w/%EC%9A%B4%EC%98%81%20%EC%B2%B4%EC%A0%9C |
− | + | * <[http://tcpschool.com/mysql/DB 데이터 베이스]> ,《티씨피 스쿨》 | |
− | + | *〈[https://support.apple.com/ko-kr/HT204136 iPhone, iPad 및 iPod touch 백업에 관하여]〉, 《애플》 | |
− | * | + | *〈[http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-isa-ko-4/s1-disaster-backups.html 시스템 관리 안내서 8장. 재난 방지 계획 세우기]〉, 《엠아이티》 |
− | * | + | * <[https://www.tta.or.kr/data/ttas_view.jsp?rn=1&rn1=Y&rn2=&rn3=&nowpage=1&pk_num=TTAS.KO-10.0253&standard_no=&kor_standard=%B9%E9%BE%F7+%C1%F6%C4%A7&publish_date=§ion_code=&order=publish_date&by=desc&nowSu=2&totalSu=2&acode1=&acode2=&scode1=&scode2= 정보시스템 백업 지침]>,《한국정보통신기술협회》, 2007-12-26 |
− | |||
− | *〈[http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-isa-ko-4/s1-disaster-backups.html 시스템 관리 안내서 8장. 재난 방지 계획 세우기]〉, | ||
== 같이 보기 == | == 같이 보기 == | ||
* [[백업장비]] | * [[백업장비]] | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
* [[데이터]] | * [[데이터]] | ||
− | |||
{{하드웨어|검토 필요}} | {{하드웨어|검토 필요}} |
2020년 8월 11일 (화) 09:48 기준 최신판
백업(backup)은 중요한 데이터(data)나 프로그램을 다른 안전한 시스템이나 저장장치 또는 저장매체로 옮기거나 복사하여 보관하는 것을 말한다. 시스템 장애 시 백업 데이터를 풀어서 시스템을 복구할 수 있다. 또한, 정보 기술에서는 데이터 백업(data backup)이라고 하며, 데이터를 미리 임시로 복제하여, 문제가 일어나도 데이터를 복구할 수 있도록 준비해 두는 것을 말한다. 데이터 백업을 수행한 파일은 백업 파일이라고 한다. 그리고 원본 데이터를 복사하여 다른 저장소에 저장하는 행위이므로 원본 데이터의 용량이 크다면 그만큼의 스토리지 공간과 데이터를 전달하는 네트워크 비용, 시간이 소요된다.
목차
개요[편집]
공공부문 정보화에 대한 예산투자가 증가함에 따라 업무 편의의 증진과 공공부문 대국민 서비스의 확대를 위한 공공기관의 정보시스템 도입이 점차 확산되고 있다. 이에 따라 오늘날 공공기관에서 사용되는 대부분의 정보들이 정보시스템을 통해 저장 관리 활용되고 있다. 정보시스템에 대한 업무의 의존도가 높아지고 있는 현 상황과 더불어 최근 바이러스 컴퓨터 범죄 각종 정보시스템 장애 인적 혹은 자연적 재해 재난 등 정보시스템의 원활한 운영을 방해하는 위협요소들이 다양한 원인을 통해 등장하고 있다 이에 따라 각 기관에서 운영되고 있는 정보시스템의 운영 및 유지보수를 위한 작업들이 정보화를 위한 중요한 기능으로 인식되고 있다. 백업은 백업 대상을 기준으로 크게 OS, 데이터베이스, 사용자 일반파일 및 기타파일 등으로 분류할 수 있다.
백업은 비상 상황들에 대비하고 문제를 극복하기 위한 방법 중의 하나로써 정보시스템에 대한 백업을 생각할 수 있다 정보시스템 백업은 일반적으로 전산장비의 고장 및 기타 불의의 사고에 대비하여 파일 혹은 데이터를 복사해두는 행위를 의미한다. 공공기관 정보자원조사의 결과에 따르면 자체 백업시스템을 운영하는 기관은 설문 응답기관의 약 89.6%, 원격지 백업을 실시하는 기관은 약 16.7%에 이르고 있다. [1]
등장배경[편집]
데이터라 함은 단순히 문서에 있는 내용을 전산 장치에 입력하는 것이었고 백업은 보관된 해당 문서(Paper)를 일컫는 것이었다. 그러나, 점차 IT 환경이 보편화되고, 데이터의 양이 증가함에 따라 미디어 형태로 백업을 받는 형태가 등장했다. 물론 이러한 미디어 형태의 백업이 지금도 일반적으로 수행하고 있는 백업의 형태라 할 수 있다. 또한, 미디어를 통한 백업도 단순히 오프라인에서 데이터를 직접 연결 저장장치(DAS) 형태로 구성된 미디어에 받아낸 후 보관하는 방식이었다. 이러한 것들 중 대표적인 백업 장치가 디지털 오디오 테이프(DAT)이다. 점차 백업의 양이 증가하고 좀 더 많은 수의 서버들을 사용하게 되자, 백업에 대한 용량이나 업무량이 증가하고, 백업을 위해 많은 시간을 할애해야 할 필요성이 대두됐다. 이에 따라 백업을 위한 전용 소프트웨어 및 백업 장치를 공유해 실제 백업 장치가 없는 서버들도 다른 서버의 백업 장치를 이용해 백업을 받을 수 있도록 하는 네트워크 백업이 등장했다. 네트워크 백업을 이용해 백업을 수행함으로써, 실제 백업에 대한 중앙 집중화가 가능하게 됐으며, 백업 관리 및 백업 장치의 효율적인 운영으로 백업에 대한 효율을 높여주는 계기가 됐다. 네트워크 백업은 백업에 대한 관리 및 백업 장치에 대한 비용을 줄여주는 효과가 있지만, 네트워크를 이용하기 때문에 네트워크에 부하가 가중되고 애플리케이션 성능에 영향을 주기도 한다.
또한 백업 성능이 직접 연결 저장장치 형태에 비해 많이 떨어진다는 단점도 있다. 이러한 단점을 극복하고, 네트워크 백업의 장점 및 고성능의 백업을 수행하기 위해 새롭게 등장한 것이 스토리지 에어리어 네트워크(SAN) 백업이다. 스토리지 에어리어 네트워크가 등장하면서, 이제는 백업에서도 스토리지 에어리어 네트워크를 통한 고성능의 백업 및 중앙 관리가 가능한 백업 형태가 나타났다. 직접 연결 저장장치 백업의 성능상 장점과 네트워크 백업의 중앙 집중 관리에 대한 장점만을 모아 백업을 구성한 것이 바로 SAN 백업이다. 현재에는 이러한, 스토리지 에어리어 네트워크 기반의 환경을 기초로 백업에 대한 많은 기법들이 개발됐다. 온라인 중에 데이터베이스를 받을 수 있는 백업과 복제 볼륨을 이용해 손쉽게 수행하는 백업, 또한 서버에 전혀 부하를 주지 않고 백업을 진행할 수 있는 서버리스 백업들이 등장했다. 뿐만 아니라 백업에 대한 관점에서 점차 복구에 대한 관점으로 옮아감에 따라, 얼마나 백업을 빠르고 정확하게 수행하느냐에서 얼마나 복구를 손쉽고 빠르게 진행하는가에 초점을 맞춘 백업 솔루션 및 제품들이 출시되고 있다.[2]
특징[편집]
필요성[편집]
백업을 하지 않는다는 것은 두 가지로 해석할 수 있다. 한 가지는, 데이터가 손상되더라도 업무 혹은 데이터의 손실에 그다지 영향이 없는 경우일 것이다. 또한, 다른 하나는, 데이터에 대한 가용성이 100%여서 백업을 받을 이유가 없는 경우이다. 물론, 첫번째의 경우는 선택적으로 가능할 수 있지만, 두번째처럼 100%의 가용성을 가진다는 것은 현재 IT 환경에서는 거의 불가능한 일이다. 일반적으로 가용성을 이야기할 때, 99.99%나 99.999% 등의 수치를 1년 동안의 시스템 가용성을 판단하는 기준으로 사용하고 있다. 그러나 이는 데이터에 대한 가용성이라기보다는 업무의 연속성에 대한 판단 기준이라고 볼 수 있다. 따라서 결론적으로 백업은 어떠한 경우라도, 데이터에 대한 보호 측면에서 반드시 수행해야만 하는 필수 요소이다.[2]
- 피해 사례
- 랜섬웨어(ransomware) : 컴퓨터 시스템을 감염시켜 접근을 제한하고 일종의 몸값을 요구하는 악성 소프트웨어의 한 종류이다. 컴퓨터로의 접근이 제한되기 때문에 제한을 없애려면 해당 악성 프로그램을 개발한 자에게 지불을 강요받게 된다. 이때 암호화되는 랜섬웨어가 있는 반면, 어떤 것은 시스템을 단순하게 잠그고 컴퓨터 사용자가 지불하게 만들기 위해 안내문구를 띄운다.[3]2020년 7월 28일, 웨어러블 제조업체 가민(garmin)이 랜섬웨어 공격에 스마트워치 서비스 먹통을 먹었다.
- KT IDC 센터 화재 : 2018년 11월 24일 오전 11시 12분, 서울특별시 서대문구 충정로3가에 위치한 KT 아현지사 건물의 지하 통신구에서 화재가 발생하여 일대 KT망을 사용하는 기기들의 유·무선 통신 장애가 발생한 사고다. 이 사고로 중구 , 용산, 서대문, 마포 인근 통신망이 모두 먹통이 되어 불편함을 겪었다. 통신망 장애로 남대문 경찰서에서는 비상벨이 오작동하기도 했다. 이 사건은 화재 원인도 밝혀내지 못한 사건이 되었다.
- AWS(amazon web service) 서울 리전 DNS 설정 실수 : 2018년 11월 22일 오전 AWS 서울 리전의 일부 DNS 서버 설정이 잘못되어 84분 동안 Amazon EC2 인스턴스의 DNS 확인을 방해하는 일이 발생한 사고다. DNS 확인 문제의 근본 원인은 설정 업데이트 시 서울 리전의 EC2 DNS 확인 서버군의 최소 정상 호스트를 지정하는 설정을 잘못 제거한 것이었다. 이로 인해 최소한의 정상 호스트 구성 기본 설정 값이 매우 낮은 것으로 해석되어, 정상 서비스 호스트 숫자가 줄어들었다. EC2 DNS 확인 서버군의 정상 호스트 용량이 감소함에 따라, 고객 EC2 인스턴스 내의 DNS 쿼리가 실패하기 시작했다. AWS 엔지니어링 팀에게 오전 8시 21분에 서울 리전 내의 DNS 확인 문제가 통보되었고, 즉시 문제 해결에 나섰다. AWS는 먼저 더 이상 정상 호스트가 서비스에서 제거되는 것을 방지함으로써 추가적인 영향이 없음을 확인했다. 이 작업에 15분이 추가로 소요되었다. 이후 서비스 용량을 이전 수준으로 복원했으며, 한국 시간 오전 9시 43분에 EC2 인스턴스의 DNS 질의 문제를 완전히 복구했다..[4]
관련 용어[편집]
- 시스템 백업 : 컴퓨터의 시스템 파일(OS 영역,시스템 설정파일 ,시스템로그 등)에 대한 정기적인 백업을 의미한다. 데이터 백업과 구별하여 보통 OS(Operating System) 백업이라고 일컫는다.
- 데이터 백업 : 시스템 영역을 제외한 모든 파일에 대한 백업을 의미한다 백업대상에는 개발자 소스파일, 응용프로그램 파일, 데이터 관련 파일 등이 있다.
- 백업 시스템 : 백업시스템은 백업을 구성하는 장비나 장치를 의미한다 시스템 및 데이터 . 백업을 수행하기 위한 모든 하드웨어, 소프트웨어 및 인프라(전원, 공간, 인력)를 총칭하는 의미로 사용하며 때로는 장애를 대비한 이중화 시스템을 칭하기도 한다.
- 백업 장비 : 백업시스템을 구성하기 위해 필요한 매체 라이브러리 채널 등의 물리적인 설비를 의미한다. 백업 장비와 백업 장치는 동일한 용어로 정의한다.
- 백업 매체 : 백업된 데이터를 저장하여 보관하기 위한 물리적 저장소로서, 테이프와 디스크가 대표적이다.
- 가상 테이프 라이브러리(VTL) : 디스크를 백업매체로 활용하는 방식의 하나로서, 디스크를 여러 개의 가상 테이프 및 드라이브로 구성된 라이브러리 시스템으로 인식시켜 디스크를 마치 테이프 백업 장비와 같이 사용하는 기술을 말한다.
- 전산센터 : 고객사 사업장과 분리되어 정보시스템을 물리적으로 구성하고 운영 관리하는 인프라 설비 및 시설을 의미한다. 전산센터에서는 정보시스템의 물리적인 관리, 논리적인 OS 관리, 시스템 소프트웨어 운영, 백업 및 복구 서비스를 수행한다 주로 대규모의 사업을 수행하는 기관에서 별도로 구축하거나 별도의 전산센터에 아웃소싱을 의뢰하여 운영한다. 전산센터의 경우 별도의 독립된 장소(건물, 층)에 운영하는 것이 일반적이다.
- 전산실 : 서비스 프로그램 개발 및 정보시스템을 운영 관리하는 개발자 및 운영자가 상주하는 공간이다. 전산실의 위치는 현업부서에 근접하여 운영되거나 별도의 대규모 전산센터 내에 위치하여 운영될 수 있다.
- 백업센터 : 현재 사용 중인 전산 인프라를 운영하는 주 전산센터에 반하여 장애 및 재해에 대비하여 업무연속성(continuity)을 보장할 수 있는 재해복구를 위한 백업 전산센터를 의미한다.
- 백업 구성 방식 : 백업시스템을 구성하는 형태 및 특징을 의미한다. 백업 솔루션을 구분하기 위해 크게 로컬(다이렉트) 백업, 네트워크 백업, SAN(Storage Area Network) 백업 으로 나뉘어 지며 백업 규모, 시간 및 특성에 따라 그 구성 방식이 결정된다.
- 디스크 복제 : 중요한 업무에서 주로 적용하는 디스크 백업 솔루션 중 하나로써 디스크의 이미지를 다른 디스크로 빠르게 복제하는 기술을 의미한다. 복제의 속도가 빠르고 복구 역시 용이하며, 보통 디스크 제공사의 복제 솔루션을 많이 사용한다.
- 미러링 : 디스크의 RAID(Redundant Array of Independent Disks) 레벨 중 RAID 1에 해당하는 디스크 구성방법으로써 한 개의 디스크에 물리적 장애가 발생하더라도 미러링 되어 있는 디스크가 자동으로 장애가 발생한 디스크를 대체하여 서비스를 지속할 수 있다. 주로 OS 디스크 및 중요한 데이터 보관 부분에 많이 사용한다.[1]
종류[편집]
- 테이프
- 18-트랙 테이프 : 가장 오래된 형태의 테이프 매체로서, 이것은 둥근릴 주위를 1/2인치 너비의 테이프가 감겨있는 형태이다. 테이프는 수 십 년 동안 전형적인 백업 매체로 한 종류 이상의 자기 테이프가 사용되었고, 이는 그 크기와 형식에 있어서 매우 다양하게 발전해 왔다. 자기 테이프는 폴리에스텔 테이프의 표면에 자성 물질을 입힌 것으로 속도는 느리나, 테이프 자체를 별도 보관하는 것이 가능하며, 기억용량이 크고, 재생하여 다시 사용할 수 있을 뿐만 아니라 가격이 저렴하다. 오랫동안 사용되어 왔으나 부피가 너무 크고, 하드웨어가 비싼 편이며, 하나의 테이프에 약 255 MB 정도가 저장된다. 따라서 요즘과 같은 대용량 디스크를 사용하는 상황에서는 하나의 디스크를 백업받기 위해 여러 번 새로운 테이프를 교체해야 한다.
- 8mm 테이프 : 비교적 빠르고 큰 용량을 가지고 있기 때문에 운영자가 중간에 개입할 필요 없이 백업을 수행할 수가 있다. 또한 크기가 작아서 테이프를 보관하는데 필요한 공간을 줄이고, 떨어져 있는 외부 저장장치를 쉽게 쓸 수 있다. 하지만 드라이브 구조가 약간 복잡하다는 단점이 있다.
- 4mm 테이프 : 음질의 오디오를 녹음하기 위해 만들어진 것으 로 많은 장비업체가 이 테이프를 사용하는 드라이브를 제공하고 있다. 디지털 오디오 테이프(DAT) 테이프는 현재 이용 가능한 마그네틱 매체 중에서 가장 작으나, 8mm 테이프보다 훨씬 빠르고 드라이브도 안정적으로 동작한다.
- 카트리지 테이프 : 평상시에는 주로 백업 라이브러리 내에 보관되며, 백업 및 복구 시 자동제어 로봇팔에 의해 백업 드라이브에 삽입되어 사용된다. 최근에는 한 개의 카트리지 테이프 용량이 수백GB에 이르며 저장 시 압축기술을 이용하면 원래 용량의 2배 이상을 백업할 수도 있다.[1]
- 디스크
- 플로피 디스크 : 대부분의 소형 컴퓨터 시스템에서는 플로피 디스크 드라이브를 사용하고 있다. 플로피 디스크는 값이 싸고, 신뢰성 있는 매체이지만 용량이 매우 적다. 즉 큰 파일을 전체 백업하는데 수 백 개의 디스켓이 필요하므로, 사실상 백업 매체로서는 적절한 것은 아니다. 그러므로 부팅 정도를 위한 용도로 사용되고 있다.
- 고용량 광자기 디스크 : 광자기 디스크의 너비와 길이는 플로피 디스크와 같지만 두께는 두 배 정도가 된다. 플로피 디스크보다 훨씬 더 많은 자료를 담을 수 있으며 데이터를 기록할 때는 마그네틱 방식을 사용하여 쓰게 되지만, 읽을 때는 광학 방식을 사용하기 때문에 다른 자기 매체보다 더 안전하다고 할 수 있다. 하지만, 드라이브와 디스크의 값이 고가이므로 흔히 사용되지는 않는다.
- CD/DVD-ROM : 합성수지와 금속 재료의 원반에 데이터를 기록하여 레이저로 읽어내는 방식의 저장매체이다. 일반적인 디스크나 다른 마그네틱 저장매체보다 내구성이 좋고 보관이 용이하여 보통 장기 보존 문서와 같은 자료들을 오랫동안 보관하기 위한 목적으로 많이 쓰인다.
- 하드 디스크 : 파일시스템에 있는 자료를 물리적으로 분리된 다른 하드 디스크에 백업하여 둘 수도 있다. 단, 이 방법은 일반적인 테이프 백업장치를 사용 하는 것에 비해 고비용이 든다.[1]
- 대상별 분류
- 운영체제(Operating System)
- 사용자가 컴퓨터를 쉽게 다룰 수 있게 해주는 인터페이스이다. 대부분 운영 체제 전공책을 보면 OS에 대한 정의를 엄밀하게 하지 않는다. 컴퓨터 자원을 효율적으로 관리하기 위한 시스템, 공통된 소프트웨어 플랫폼, 컴퓨터 응용 프로그램 관리자 등으로 다양하다. 드라이버는 대개의 경우 OS를 거쳐서 설치되므로 운영 체제는 펌웨어 다음으로 하드웨어와 가장 직접적으로 관련되는 소프트웨어이다. 운영 체제는 하드웨어와 소프트웨어를 관리하는 소프트웨어 전체라고 할 수 있다. 이러한 운영체제는 어느 기기에서 어떠한 형태로도 나타날 수 있다. 비단 PC용 윈도우만이 운영체제가 아니고, MP3 플레이어를 켜면 전원이 들어와 장치를 깨우고 사용자의 명령에 따라 음악을 재생하는 동작들을 관리하는 것들도 전부 운영 체제라 할 수 있다. 단, 이런 식으로 전자기기에 공장 출고시 설치되며 애플리케이션 설치를 통한 기능 추가를 할 수 없는 것은 보통 펌웨어(firmware)라고 부른다.[5]
- 서버의 운영체제나 시스템 구성 파라미터 파일 및 시스템 로그 파일이 그 대상이다. 보통 월 1회 혹은 시스템 변경 시 시스템 백업을 실시하여야 하며 백업 및 복구가 간편한 디지털 오디오 테이프를 많이 이용한다. 시스템 최초 설치 및 업그레이드, 버그 패치 등의 작업 후에도 이미지 백업을 실시 후 보관한다.[1]
- 데이터 베이스 : 통합하여 관리되는 데이터의 집합체를 의미한다. 이는 중복된 데이터를 없애고, 자료를 구조화하여, 효율적인 처리를 할 수 있도록 관리된다. 따라서, 여러 업무에 여러 사용자가 데이터 베이스를 사용할 수 있다. 이러한 데이터베이스는 응용 프로그램과는 다른 별도의 미들웨어에 의해 관리된다. 데이터베이스를 관리하는 이러한 미들웨어를 데이터베이스 관리 시스템(DBMS)이라고 한다.[6]
- 데이터베이스의 데이터파일 및 컨트롤 파일 변경로그 파일 등이 그 대상이다. 이외에도 데이터베이스 엔진이나 구성파일 자체도 주기적으로 또는 변경작업 전에 백업하여야 한다.[1]
- 사용자 일반파일 : 사용자 데이터, 개발자 소스 파일, 응용 소프트웨어 등이 그 대상이다. 백업 시기로는 일일 주요 파일(개발소스) 백업, 주 1회 전체 백업, 월 회 1 전체 백업, 사용자의 요구 시에 발생하는 비정기적인 백업 등이 있다.[1]
방식[편집]
전통적인 백업 방식[편집]
- 전체 백업(full backup) : 변경(changed) 데이터나 고유(unique) 데이터를 전혀 구분하지 않고 백업할 때마다 모든 데이터의 복사본을 만드는 백업 방식이다. 전체 백업은, 복구 시에 일부 다른 백업 방식보다 간편하고 시간이 증분 백업에 비해 상대적으로 덜 걸린다는 장점이 있다.[7]
- 증분 백업(incremetal Backup) : 전체 백업과는 달리 최종 전체 백업 혹은 최종 증분 백업 이후에 변경된 파일만을 복사한다. 전체 백업과 비교할 때 증분 백업은 매일 백업해야 하는 파일의 양이 적어 빠른 백업 윈도가 가능하다는 점이 장점이다. 그러나 복구 과정에서는 최종 백업된 전체 및 모든 후속 증분 이미지나 복사본까지 복구해야 하기 때문에 복구 작업이 번거로워지고 경우에 따라서는 시간이 훨씬 더 걸릴 수 있다.[7]
- 차등 백업(differential backup) : 마지막 전체 백업 이후 변경된 모든 데이터를 백업하는 방식이다. 이는 바로 이전의 전체 백업 혹은 증분 백업 이후 변경된 데이터만 복사하는 증분 백업과는 다르다. 일단 파일이 변경되면 예정된 다음 전체 백업 시까지 매일 백업한다. 따라서 파일이 변경될 때마다 파일 크기가 증가하게 되며, 다음 전체 백업 때까지 파일 크기가 점점 커지게 된다. 하지만, 전체 백업 이미지와 가장 최근의 차등 이미지만 복구하면 되기 때문에 복구 시점에 따라 다르긴 하지만 대개 증분 백업보다 복구 속도가 빠르다.[7]
다른 백업 방식[편집]
- 신센틱 백업
신센틱 백업(Synthetic Backup)은 선택된 폴더의 전체백업 이후 변경, 추가된 데이터(data)를 증분 백업(Incremental Backup) 형식으로 저장 후 두번째 Full 백업 작업시 중간에 모아 둔 Incremental bakcup을 이용하여 전체 백업(Full Backup)으로 재생성 하는 방식이다.백업 서버에 data를 백업 서버에서 다시 한번 모두 복사(copy) 하면서 전체백업을 만들 수도 있다. 카탈로그(catalog) 정보만으로 백업본을 생성하는 제품도 있다.기본적인 백업은 네트워크를 이용해서 데이터를 가져와 백업 서버(backup server)에 저장 한다. 신센틱 백업을 이용하면 백업 서버에서 이미 저장되어 있는 증분 데이터(Incremental Data)를 이용해 Full Backup을 새로 만들기 때문에 Network 사용량을 줄일 수가 있다.[8]
- 중복제거 백업
중복제거 백업(Deduplication Backup)은 한개의 파일 혹은 여러개의 파일에서 동일한 부분은 하나만 저정하고 나머지 파일 구조는 메타 데이타로 따로 저장하여 백업 저장소와 백업 데이터를 줄일 수 있다. 백업 소프트 위에는 파일단위 백업이 기본이기 때문에 파일의 사이즈에 관계없이 변경되면 변경된 파일 을 모두 백업하도록 동작 한다. 중복제거 기술은 섹터 단위로 파일을 검사하기 때문에 변경된 섹터의 값만 다시 백업한다. 증분 및 차등 백업과 중복제거 변경된 파일을 가져 온다는 의미에는 큰 차이점이 없다. 그러나, 실제로 백업 소프트웨어에서 동작할때 차이점이 발생 한다. 증분 및 차등을 200MB의 200장의 화면을 가진 파워 포인트가 있다고 가정하면, 중복 제거와의 차이점은 다음과 같다.[8]
- 증분 및 차분
- 전체 백업(full Backup)을 실행 하면 200MB의 파일을 받아 온다.
- 200장의 화면중 2장이 변경 한다.
- 200MB의 파일의 변경 인식 후 200MB를 다시 받아 온다.
- 중복제거
- 전체 백업을 실행 하면 200MB의 파일을 받아 온다.
- 200장의 화면중 2장이 변경 한다.
- 200MB의 파일의 변경 인식 후 변경된 섹터의 값만 받아 온다.
라이브 백업[편집]
라이브 백업은 온라인 백업이나 실시간 백업으로도 불리며, 컴퓨터나 데이터베이스가 운영 중인 상태에서 백업하는 것을 말한다. 인포믹스 데이터베이스의 공식적인 백업 유틸리티인 온바(Onbar:Online Backup and Recovery)에서 온라인 백업이라는 용어를 사용하면서 온라인 백업은 데이터베이스를 중단시키지 않고 백업한다는 개념으로 발전하였고, 라이브 백업은 컴퓨터가 운영 중인 상태에서 실시간 백업한다는 의미로 정해지고 있다. 라이브 백업을 할 수 있는 조건을 가질려면 운영 중 백업, 실시간 감시, 백그라운드 실행, 운영 환경에 부하 최소화 정도의 조건을 만족해야 한다.[9]
- 에이전트 기반 : 컴퓨터에 설치된 에이전트가 데이터의 변화를 감지하고 이를 실시간 백업한다.
- 스토리지 기반 : 데이터가 저장된 외장 스토리지에서 데이터의 변화를 블록-레벨로 감지하여 백업한다.
서비스[편집]
- 국내 서비스
- 스마트 스위치(smart switch) : 삼성전자에서 모바일과 PC에서 이용 할 수 있는 백업을 지원하는 서비스이다. 휴대전화 네트워크 유무와 관계 없이 사용자의 PC또는 SD카드에 백업이 가능하다. 다만 PC와 SD카드라는 별도의 저장공간을 필요로 할 수 있다.
- 모바일 스위치(mobile switch) : 엘지전자㈜에서 스마트폰간 백업 및 데이터 이동을 지원하는 백업 서비스이다. 이동 가능한 데이터 종류는 주소록, 메시지, 통화기록, 캘린더, 음성녹음, 사진, 동영상, 음악, 문서, 메모, 다운로드앱,공인인증서, 기타 설정 항목 등을 새로운 LG 스마트폰으로 옮길 수 있다.
- 국외 서비스
- 아마존 웹 서비스 백업(amazon web service backup, aws backup) : 아마존에서 지원하는 완전관리형 백업 서비스로, AWS 서비스 전체에 걸쳐 데이터 백업을 쉽게 중앙 집중화하고 자동화할 수 있다. AWS 백업을 사용하면 백업 정책을 중앙에서 구성하고 Amazon EBS 볼륨, Amazon EC2 인스턴스, Amazon RDS 데이터베이스, Amazon DynamoDB 테이블, Amazon EFS 파일 시스템 및 AWS Storage Gateway 볼륨과 같은 AWS 리소스의 백업 활동을 모니터링할 수 있다. AWS Backup에서는 이전에 서비스별로 수행되던 백업 작업을 자동화하고 통합하므로, 사용자 지정 스크립트와 수동 프로세스를 생성할 필요가 없다. AWS Backup 콘솔에서 클릭 몇 번이면 백업 일정과 보존 관리를 자동화하는 백업 정책을 생성할 수 있다. AWS Backup은 완전관리형 정책 기반 백업 솔루션을 제공하여 백업 관리를 간소화하고 비즈니스 및 규제상의 백업 규정 준수 요구 사항을 충족할 수 있도록 지원한다.[4]
- 아이클라우드 백업(iCloud backup) : 애플에서 지원하는 백업 서비스로, 와이파이(Wi-Fi) 네트워크(network)로 연결하면 iCloud를 사용하여 기기의 백업을 만들 수 있다. 기기를 컴퓨터에 연결하지 않아도 또는 집에 있지 않아도 iCloud를 사용하여 백업할 수 있다. iCloud 백업에는 기기에 저장된 거의 모든 데이터와 설정이 포함된다.[10]
- 구글 드라이브(google drive) : 구글에서 제공하는 클라우드 기반 협업도구이자 파일저장/공유 백업도 할 수 있는 서비스다.
복구[편집]
완전 복구(Bare Metal Recovery, BMR)라고 불리는 과정은 시스템을 재설치하는 경우, 즉 아무런 운영 체제나 응용 프로그램도 설치되지 않은 시스템에 전체 시스템 백업을 복구하는 경우를 말한다. 또한, 재설치 후 복구하는 방법으로 완전히 새 컴퓨터를 구입했을 때처럼 기본 운영 체제를 설치한 후 적절한 설정 작업을 마치고 남은 디스크 드라이브를 파티션 분할하여 포맷한 후 백업 매체에서 모든 백업을 복구하는 방법이있다. 시스템 복구 디스크는 최소 시스템 환경을 포함한 부팅 매체로서 가장 기본적인 시스템 관리자 작업을 수행할 수 있게 해준다. 복구 환경에서는 디스크 드라이브를 파티션하고 포맷 가능한 필수 유틸리티 및 백업 장치에 액세스하는데 필요한 장치 드라이버와 백업 매체에서 데이터를 복구하는데 필요한 소프트웨어를 사용한다. 완전 복구를 위한 복구 절차는 다음과 같다.[11]
- 복구 절차
- 장애 원인 파악 : 정보시스템에 장애가 발생하면 먼저, 장애 원인, 영향범위 및 장애유형 등을 파악해야 한다. 장애 원인 및 범위, 유형에 따라 장애를 복구하기 위해 백업본에 대한 리스토어가 필요한지 여부를 포함한 세부적 장애복구 절차를 결정하고, 이에 따라 장애복구 예상시간 및 사전 준비사항을 마련하여야 한다.
- 복구대상 확인 : 시스템 장애 해결책으로 백업본의 리스토어 의사결정이 되면 복구가 요구되는 시점에 유의하여, 백업본을 식별하고 백업 데이터의 정상 유무를 확인하여 복구 작업을 준비한다. 실제로 장애 발생시 백업본을 활용하여 복구를 수행하는 의사결정을 하는 것이 쉽지 않으며 시간도 많이 걸린다. 따라서 장애 유형별 복구 전략을 사전 정의하여 의사결정 시간을 단축하는 것이 장애시간을 최소화하는 데 도움이 된다.
- 복구 수행 : 복구방법에 대한 의사결정이 나고 복구 대상에 대한 백업본을 식별하여 복구할 준비가 끝나면 실제 복구 작업을 수행한다.
- 검증 : 복구 작업이 끝나면 업무 담당자 협조 하에 복구 작업의 유효성 및 데이터의 무결성을 검증한다. 검증이 완료된 후에 시스템을 정상적으로 서비스에 투입 할 수 있다. 복구작업이 불완전한 상태에서 검증을 거치지 않고 서비스를 투입하면 향후 데이터 정합성에 치명적인 손상을 야기할 수 있으므로 주의한다.[1]
백업정책 수립[편집]
백업정책의 수립은 크게 업무중요도 파악, RTO, RPO 설정, 백업가능시간 및 백업대상 데이터 분석 등을 수행하는 백업환경분석 단계를 거쳐 백업주기, 보관기간, 백업수행시간, 백업방법 등의 각 요소별의 백업정책을 수립하는 절차를 따르게 된다. 먼저, 백업 정책의 수립을 위해서는 업무 분석을 통해 업무의 중요도를 객관적인 기준으로 분류하여야 한다. 여러 업무가 있는 경우, 중요도가 비슷한 업무들을 그룹화하여 몇 개의 업무 그룹으로 분류할 수도 있다. 예를 들면, 직접적으로 대국민 서비스 중 민원처리와 관련된 업무들은 기관의 신뢰성과 직접 관련되어 있으므로 매우 중요한 업무 그룹이라고 생각할 수 있다. 이렇게 업무별 중요도가 설정된 다음에는, 업무의 흐름을 파악하여 백업을 수행하기 위한 최적의 시간대(백업시간 또는 백업윈도우)를 찾아내어야 한다. 이는 백업된 데이터가 복구시 최대한 유효한 데이터가 되도록 하고 백업시간 동안 서버 부하 등으로 인한 업무 영향도를 최소화하기 위함이다. 또한, 백업대상이 되는 데이터의 종류와 용량을 파악하여야 한다. 데이터의 종류에는 운영체제(OS), 데이터베이스, 일반 파일 등이 있으며, 이러한 데이터의 종류와 용량에 따라 백업 정책의 결정에 영향을 미치게 된다. 마지막으로, 업무중요도에 따라 분류된 업무그룹 및 개별업무의 각 데이터별로 백업주기, 보관기간을 결정해야 한다. 이때, 백업정책의 수립 과정을 효율화하고 여러 업무 담당자의 상이한 의견을 수렴하는 가이드가 될 수 있도록 하기 위하여, 각 기관별로 표준백업정책을 수립함으로써 백업 정책의 표준화와 일관성의 향상을 도모할 수 있다.[1]
각주[편집]
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 <정보시스템 백업 지침>,《한국정보통신기술협회》, 2007-12-26
- ↑ 2.0 2.1 ppp , <백업솔루션의 등장배경및개요>, 《네이버 블로그》, 2004-08-12
- ↑ 랜섬웨이 위키백과 - https://ko.wikipedia.org/wiki/%EB%9E%9C%EC%84%AC%EC%9B%A8%EC%96%B4#주요_사례
- ↑ 4.0 4.1 〈AWS Backup〉, 《아마존》
- ↑ OS 나무위키 - https://namu.wiki/w/%EC%9A%B4%EC%98%81%20%EC%B2%B4%EC%A0%9C
- ↑ <데이터 베이스> ,《티씨피 스쿨》
- ↑ 7.0 7.1 7.2 감자 , 〈백업 종류〉, 《네이버 블로그》, 2007-10-17
- ↑ 8.0 8.1 관리자(쉐어드아이티) , 〈백업 방식에 대해 알아 보자!!〉, 《쉐어드아이티》, 2017-11-06
- ↑ 라이브 백업 위키백과 - https://ko.wikipedia.org/wiki/%EB%9D%BC%EC%9D%B4%EB%B8%8C_%EB%B0%B1%EC%97%85
- ↑ 〈iPhone, iPad 및 iPod touch 백업에 관하여〉, 《애플》
- ↑ 〈시스템 관리 안내서 8장. 재난 방지 계획 세우기〉, 《엠아이티》
참고자료[편집]
- 백업 위키백과 - https://ko.wikipedia.org/wiki/%EB%B0%B1%EC%97%85
- 라이브 백업 위키백과 - https://ko.wikipedia.org/wiki/%EB%9D%BC%EC%9D%B4%EB%B8%8C_%EB%B0%B1%EC%97%85
- ppp, <백업솔루션의 등장배경및개요>, 《네이버 블로그》, 2004-08-12
- 랜섬웨이 위키백과 - https://ko.wikipedia.org/wiki/%EB%9E%9C%EC%84%AC%EC%9B%A8%EC%96%B4#주요_사례
- 감자 , 〈백업 종류〉, 《네이버 블로그》, 2007-10-17
- 관리자(쉐어드아이티) , 〈백업 방식에 대해 알아 보자!!〉, 《쉐어드아이티》, 2017-11-06
- 〈AWS Backup〉, 《아마존》
- OS 나무위키 - https://namu.wiki/w/%EC%9A%B4%EC%98%81%20%EC%B2%B4%EC%A0%9C
- <데이터 베이스> ,《티씨피 스쿨》
- 〈iPhone, iPad 및 iPod touch 백업에 관하여〉, 《애플》
- 〈시스템 관리 안내서 8장. 재난 방지 계획 세우기〉, 《엠아이티》
- <정보시스템 백업 지침>,《한국정보통신기술협회》, 2007-12-26
같이 보기[편집]