본문으로 이동

백업

위키백과, 우리 모두의 백과사전.

백업(영어: backup, 문화어: 후보)은 임시 보관을 일컫는 말로, 정보 기술에서는 데이터 백업(영어: data backup)이라고 하며, 데이터 손실 사고가 발생한 후 원본을 복구하는 데 사용할 수 있도록 다른 곳에 보관된 컴퓨터 데이터의 복사본을 의미한다. 이를 수행하는 과정을 나타내는 동사형은 "백업하다"이며, 명사 및 형용사형은 "백업"이다.[1] 백업은 데이터 삭제나 손상으로 인한 손실 후 데이터를 복구하거나, 이전 시점의 데이터를 복구하는 데 사용될 수 있다. [2] 백업은 단순한 형태의 재난 복구 계획을 제공하지만, 모든 백업 시스템이 컴퓨터 시스템이나 컴퓨터 클러스터, 액티브 디렉터리 서버, 데이터베이스 서버와 같은 복잡한 구성을 재구성할 수 있는 것은 아니다.[3]

백업 시스템은 저장할 가치가 있다고 판단되는 모든 데이터의 복사본을 적어도 하나 이상 포함한다. 데이터 저장 요구 사항은 방대할 수 있으며, 이 저장소에 구조를 제공하기 위해 정보 저장소 모델이 사용될 수 있다. 이미 보조 저장장치에 있는 데이터를 아카이브 파일로 백업 복사하는 데 사용되는 다양한 유형의 데이터 저장 장치가 있다.[note 1][4] 또한 지리적 분산,[5] 데이터 보안, 휴대성을 제공하기 위해 이러한 장치를 배치하는 다양한 방법이 존재한다.

데이터는 저장을 위해 선택, 추출 및 조작된다. 이 과정에는 열려 있는 파일을 포함한 실시간 데이터를 처리하는 방법뿐만 아니라 압축, 암호화, 중복 제거가 포함될 수 있다. 엔터프라이즈 클라이언트-서버 백업에는 추가적인 기술이 적용된다. 백업 체계에는 백업되는 데이터의 신뢰성을 검증하는 드라이 런(dry run)이 포함될 수 있다. 모든 백업 체계에는 한계와 인적 요인이 수반된다.

저장소

[편집]

백업 전략에는 데이터 "소스"의 백업을 집계하는 "데이터를 위한 보조 저장 공간"인 정보 저장소가 필요하다.[6] 저장소는 모든 백업 매체(DVD 등)와 제작 날짜의 목록만큼 간단할 수도 있고, 컴퓨터화된 인덱스, 카탈로그 또는 관계형 데이터베이스를 포함할 수도 있다.

3-2-1 백업 규칙

[편집]

백업 데이터는 저장되어야 하며, 이를 위해 백업 순환 체계(backup rotation scheme)가 필요하다.[4] 이는 더 이상 필요하지 않은 백업을 덮어써서 데이터 저장 매체를 적절히 재사용함으로써, 별도로 유지되는 서로 다른 날짜의 백업 수를 제한하는 시스템이다. 이 체계는 각 이동식 저장 장치가 백업 작업에 사용되는 방식과 시기, 그리고 백업 데이터가 저장된 후 보관되는 기간을 결정한다. 백업 과정에는 3-2-1 규칙이 도움이 될 수 있다. 이 규칙은 데이터의 복사본을 최소 3개 보유하고, 2가지 이상의 서로 다른 저장 매체에 저장하며, 1개의 복사본은 원격지(이에는 클라우드 스토리지가 포함될 수 있음)에 보관해야 한다는 원칙이다. 유사한 원인으로 인한 데이터 손실을 방지하기 위해 2가지 이상의 서로 다른 매체를 사용해야 한다(예를 들어, 광 디스크는 침수를 견딜 수 있지만 LTO 테이프는 그렇지 못할 수 있으며, SSD는 하드 드라이브와 달리 움직이는 부품이 없으므로 헤드 충돌이나 스핀들 모터 손상으로 인해 고장 나지 않는다). 원격지 복사본은 화재, 물리적 매체(테이프나 디스크 등)의 도난, 홍수나 지진 같은 자연재해로부터 데이터를 보호한다. 물리적으로 보호되는 하드 드라이브가 원격지 복사본의 대안이 될 수 있지만, 한정된 시간 동안만 화재를 견딜 수 있는 등의 한계가 있어 원격지 복사본이 여전히 이상적인 선택으로 남는다.

완벽한 저장 장치는 없기 때문에, 많은 백업 전문가들은 데이터를 원격지에 백업하더라도 로컬 물리적 장치에 두 번째 복사본을 유지할 것을 권장한다.[7][8][9][10]

백업 방법

[편집]

비구조적

[편집]

비구조적 저장소는 무엇이 언제 백업되었는지에 대한 최소한의 정보만 있는 테이프, DVD-R 또는 외장 HDD의 더미일 수 있다. 이 방법은 구현하기 가장 쉽지만 자동화가 부족하여 높은 수준의 복구 가능성을 달성하기 어렵다.

전체 전용/시스템 이미지

[편집]

이 백업 방법을 사용하는 저장소에는 하나 이상의 특정 시점에 생성된 완전한 소스 데이터 복사본이 포함된다. 시스템 이미지를 복사하는 이 방법은 컴퓨터 기술자들이 양호한 것으로 확인된 구성을 기록하기 위해 자주 사용한다. 그러나 이미지 생성[11]은 일반적으로 다양한 시스템의 지속적인 백업을 위한 도구보다는 표준 구성을 여러 시스템에 배포하는 방법으로 더 유용하다.

증분

[편집]

증분 백업은 특정 기준 시점 이후에 변경된 데이터만 저장한다. 변경되지 않은 데이터의 중복 복사본은 복사되지 않는다. 일반적으로 모든 파일의 전체 백업은 한 번 또는 드문 간격으로 이루어지며, 이는 증분 저장소의 기준 시점 역할을 한다. 그 후, 연속적인 기간마다 여러 차례의 증분 백업이 수행된다. 복구는 마지막 전체 백업에서 시작하여 증분 백업들을 적용한다.[12] 일부 백업 시스템[13]은 일련의 증분 백업으로부터 합성 전체 백업(synthetic full backup)을 생성하여 빈번하게 전체 백업을 수행하는 것과 동일한 효과를 제공할 수 있다. 단일 아카이브 파일을 수정하는 방식으로 수행될 때, 이는 최신 버전 파일의 복구 속도를 높여준다.

Near-CDP

[편집]

지속 데이터 보호(CDP)는 데이터에 가해진 모든 변경 사항의 복사본을 즉시 저장하는 백업을 의미한다. 이를 통해 데이터를 어느 시점으로든 복구할 수 있으며, 가장 포괄적이고 발전된 데이터 보호 방식이다.[14] 종종 "CDP"로 마케팅되는 Near-CDP 백업 애플리케이션은 15분, 1시간 또는 24시간과 같은 특정 간격으로 증분 백업을 자동으로 수행한다. 따라서 간격 경계 시점으로만 복구할 수 있다.[14] Near-CDP 백업 애플리케이션은 저널링을 사용하며, 일반적으로 특정 시점에서 고정된 데이터의 읽기 전용 복사본인 "스냅샷"을 기반으로 한다.[15]

Near-CDP는 (Apple Time Machine을 제외하고)[16] 호스트 시스템의 모든 변경 사항을 로그에 기록하며,[17] 종종 파일 수준의 차이가 아닌 바이트 또는 블록 수준의 차이를 저장한다. 이 백업 방법은 로그의 롤백을 가능하게 하여 데이터의 이전 이미지를 복구할 수 있다는 점에서 단순한 디스크 미러링과 다르다. 로그 기록 방식은 실시간 데이터의 일관성을 위한 예방 조치를 가능하게 하여 자체 일관성이 있는 파일을 보호하지만, 애플리케이션이 "정지되어 백업 준비가 완료된 상태"가 되어야 한다.

Near-CDP는 가상 머신[18][19]이나 그에 준하는 환경[20]과 함께 실행되어야 하는 True CDP에 비해 일반적인 개인용 백업 애플리케이션에 더 실용적이며, 따라서 일반적으로 엔터프라이즈 클라이언트-서버 백업에서 사용된다.

소프트웨어는 정전, 운영 체제 충돌 또는 디스크 공간 부족으로 인한 쓰기 실패가 데이터 손실을 일으키는 것을 방지하기 위해 작성된 문서, 멀티미디어 프로젝트 또는 사용자 설정과 같은 개별 파일의 복사본을 생성할 수 있다. 일반적인 구현 방식은 파일 이름에 ".bak" 확장자를 추가하는 것이다.

역증분

[편집]

역증분(Reverse incremental) 백업 방법은 소스 데이터의 최신 아카이브 파일 "미러"와 현재 상태의 "미러"와 이전 상태들 사이의 일련의 차이점을 저장한다. 역증분 백업 방법은 이미지가 아닌 전체 백업으로 시작한다. 전체 백업이 수행된 후, 시스템은 주기적으로 전체 백업을 실시간 복사본과 동기화하는 동시에 이전 버전을 재구성하는 데 필요한 데이터를 저장한다. 이는 애플 타임 머신처럼 하드 링크를 사용하거나 이진 차분(diffs)을 사용하여 수행할 수 있다.

차등

[편집]

차등 백업은 마지막 전체 백업 이후 변경된 데이터만 저장한다. 이는 저장소에서 최대 두 개의 백업만 사용하여 데이터를 복구할 수 있음을 의미한다. 그러나 마지막 전체 백업 이후 시간이 지남에 따라(따라서 누적된 데이터 변경량이 증가함에 따라) 차등 백업을 수행하는 데 걸리는 시간도 늘어난다. 전체 시스템을 복구하려면 가장 최근의 전체 백업에서 시작하여 마지막 차등 백업만 적용하면 된다.

차등 백업은 다른 차등 백업이 수행되었는지 여부와 관계없이 마지막 전체 백업 이후 생성되거나 변경된 파일을 복사하는 반면, 증분 백업은 유형(전체 또는 증분)에 관계없이 가장 최근의 백업 이후 생성되거나 변경된 파일을 복사한다. 파일의 변경 사항은 최근 수정 날짜/시간 파일 특성 또는 파일 크기의 변화를 통해 감지될 수 있다. 증분 백업의 다른 변형으로는 다단계 증분과 파일 전체가 아닌 일부만 비교하는 블록 수준 증분이 있다.

저장 매체

[편집]
왼쪽부터 플라스틱 케이스에 담긴 DVD 디스크, USB 플래시 드라이브 및 외장 하드 드라이브

사용되는 저장소 모델과 관계없이 데이터는 아카이브 파일 데이터 저장 매체에 복사되어야 한다. 사용되는 매체는 백업 대상 유형이라고도 불린다.

자기 테이프

[편집]

자기 테이프는 오랫동안 대량 데이터 저장, 백업, 아카이빙 및 교환에 가장 일반적으로 사용되는 매체였다. 이전에는 더 저렴한 옵션이었으나, 소량의 데이터에 대해서는 더 이상 그렇지 않다.[21] 테이프는 순차 접근 매체이므로 데이터를 지속적으로 쓰거나 읽는 속도가 매우 빠를 수 있다. 테이프 매체 자체는 용량당 비용이 낮지만, 테이프 드라이브는 일반적으로 하드 디스크 드라이브나 광학 드라이브보다 수십 배 더 비싸다.

많은 테이프 형식이 독점적이거나 메인프레임 또는 특정 브랜드의 개인용 컴퓨터와 같은 특정 시장 전용이었다. 2014년까지 LTO가 주요 테이프 기술이 되었다.[22] 남아있는 또 다른 실행 가능한 "슈퍼" 형식은 IBM 3592(TS11xx 시리즈라고도 함)이다. 오라클 스토리지텍 T10000은 2016년에 단종되었다.[23]

하드 디스크

[편집]

하드 디스크 저장 장치의 사용은 가격이 점차 저렴해짐에 따라 시간이 지나면서 증가했다. 하드 디스크는 대개 사용하기 쉽고 널리 보급되어 있으며 빠르게 액세스할 수 있다.[22] 그러나 하드 디스크 백업은 정밀한 기계 장치이며 특히 운송 중에 테이프보다 더 쉽게 손상될 수 있다.[24] 2000년대 중반, 몇몇 드라이브 제조사들은 램프 로드(ramp load) 및 가속도계 기술(때때로 "충격 센서"라고 함)을 채택한 휴대용 드라이브를 생산하기 시작했으며,[25][26] 2010년까지 이 기술이 적용된 드라이브의 낙하 테스트 산업 평균은 산업용 카펫 위에 36인치 높이에서 비작동 상태로 낙하해도 드라이브가 온전하게 작동함을 보여주었다.[27] 일부 제조업체는 하드 디스크 주변에 충격 흡수 케이스를 포함하고 더 높은 범위의 낙하 사양을 주장하는 '견고화(ruggedized)' 휴대용 하드 드라이브도 제공한다.[27][28][29] 수년에 걸친 하드 디스크 백업의 안정성은 테이프 백업보다 짧다.[23][30][24]

외장 하드 디스크는 SCSI, USB, FireWire, 또는 eSATA와 같은 로컬 인터페이스나 이더넷, iSCSI, 또는 파이버 채널과 같은 장거리 기술을 통해 연결할 수 있다. 가상 테이프 라이브러리 등을 통한 일부 디스크 기반 백업 시스템은 데이터 중복 제거를 지원하여 일일 및 주간 백업 데이터가 소비하는 디스크 저장 용량을 줄일 수 있다.[31][32][33]

광 저장 장치

[편집]
광 디스크는 물에 취약하지 않아 홍수 재난에서도 살아남을 가능성이 높다.

광기억 장치는 레이저를 사용하여 데이터를 저장하고 검색한다. 기록 가능한 CD, DVD 및 블루레이 디스크는 개인용 컴퓨터에서 흔히 사용되며 일반적으로 저렴하다. 이러한 디스크의 용량과 속도는 일반적으로 하드 디스크나 테이프보다 낮았다. 광 매체의 발전은 향후 그 격차를 줄일 수 있다.[34][35]

점진적인 매체 열화로 인해 발생할 수 있는 미래의 데이터 손실은 수정 가능한 경미한 데이터 오류율을 측정함으로써 예측할 수 있으며, 이러한 오류가 연속적으로 너무 많이 발생하면 수정 불가능한 섹터가 발생할 위험이 높아진다. 오류 스캐닝에 대한 지원은 광학 드라이브 공급업체마다 다르다.[36]

많은 광 디스크 형식은 한 번 쓰고 여러 번 읽는 WORM 유형으로, 사용자 실수나 랜섬웨어와 같은 악성 소프트웨어에 의해 데이터가 변경될 수 없으므로 아카이브 목적에 유용하다. 또한 광 디스크는 헤드 충돌, 자기장, 침수 또는 전압 스파이크에 취약하지 않으며, 드라이브 고장은 대개 회전을 멈추는 정도에 그친다.

광 매체는 모듈성을 갖는다. 저장소 컨트롤러는 하드 드라이브나 플래시 저장소(플래시 메모리 컨트롤러)와 달리 매체 자체에 묶여 있지 않아, 매체를 분리하여 다른 드라이브를 통해 액세스할 수 있다. 그러나 기록 가능한 매체는 빛에 장기간 노출될 경우 조기에 열화될 수 있다.[37]

일부 광 저장 시스템은 디스크에 사람이 직접 접촉하지 않고도 카탈로그화된 데이터 백업을 수행할 수 있어 더 긴 데이터 무결성을 보장한다. 2008년 프랑스의 한 연구에 따르면 일반적으로 판매되는 CD-R의 수명은 2~10년이었으나,[38] 이후 한 제조업체는 금 증착 층을 사용한 자사 CD-R의 수명을 최대 100년으로 추정했다.[39] 소니의 독자적인 옵티컬 디스크 아카이브[22]는 2016년에 250 MB/s의 읽기 속도에 도달했다.[40]

솔리드 스테이트 드라이브

[편집]

솔리드 스테이트 드라이브(SSD)는 집적 회로 조립체를 사용하여 데이터를 저장한다. 플래시 메모리, 썸 드라이브, USB 플래시 드라이브, 콤팩트플래시, 스마트미디어, 메모리 스틱 및 Secure Digital 카드 장치는 용량에 비해 상대적으로 비싸지만, 비교적 적은 양의 데이터를 백업하는 데 편리하다. 솔리드 스테이트 드라이브는 움직이는 부품이 없어 물리적 손상에 덜 취약하며, 약 500 Mbit/s에서 최대 6 Gbit/s의 거대한 처리량을 가질 수 있다. 사용 가능한 SSD는 점점 더 대용량화되고 저렴해졌다.[41][28] 플래시 메모리 백업은 하드 디스크 백업보다 안정 유지 기간이 짧다.[23]

원격 백업 서비스

[편집]

원격 백업 서비스 또는 클라우드 백업은 서비스 제공업체가 데이터를 원격지에 저장하는 것을 포함한다. 이는 로컬에 저장된 백업을 파괴할 수 있는 화재, 홍수 또는 지진과 같은 사고로부터 데이터를 보호하는 데 사용되어 왔다.[42] (구글 드라이브 및 마이크로소프트 원드라이브와 같은 서비스나 유사한 서비스를 통한) 클라우드 기반 백업은 데이터 보호의 한 계층을 제공한다.[24] 그러나 사용자는 제공업체가 데이터의 프라이버시와 무결성을 유지할 것이라고 신뢰해야 하며, 암호화를 통해 기밀성을 강화할 수 있다. 속도와 가용성은 사용자의 온라인 연결 상태에 따라 제한되므로,[24] 대량의 데이터를 가진 사용자는 시드 로딩(seed loading)과 대량 복구 기능을 사용해야 할 수도 있다.

관리

[편집]

백업 매체를 관리하기 위해 접근성, 보안 및 비용 사이의 균형을 맞추는 다양한 방법이 사용될 수 있다. 이러한 매체 관리 방법은 상호 배타적이지 않으며 사용자의 요구를 충족시키기 위해 자주 결합된다. 데이터를 니어라인(near-line) 테이프 라이브러리로 보내기 전에 스테이징하기 위해 온라인 디스크를 사용하는 것이 일반적인 예이다.[43][44]

온라인

[편집]

온라인 백업 저장소는 일반적으로 가장 접근하기 쉬운 유형의 데이터 저장소이며, 수 밀리초 내에 복구를 시작할 수 있다. 내부 하드 디스크나 (SAN에 연결된) 디스크 어레이가 온라인 백업의 예이다. 이 유형의 저장소는 편리하고 빠르지만, 실수나 악의적인 행위, 또는 데이터 삭제 컴퓨터 바이러스 등에 의해 삭제되거나 덮어씌워질 위험이 있다.

니어라인

[편집]

니어라인 저장소는 일반적으로 온라인 저장소보다 접근성은 낮고 비용은 저렴하지만, 여전히 백업 데이터 저장에 유용하다. 일반적으로 저장소에서 드라이브로 매체 장치를 이동시켜 데이터를 읽거나 쓸 수 있게 하는 기계 장치가 사용된다. 일반적으로 온라인 저장소와 유사한 안전 특성을 갖는다. 복구 시간이 수 초에서 수 분 정도 걸리는 테이프 라이브러리가 그 예이다.

오프라인

[편집]

오프라인 저장소는 저장 매체에 액세스하기 위해 테이프를 테이프 드라이브에 삽입하거나 케이블을 연결하는 등의 직접적인 작업이 필요하다. 데이터를 쓰고 읽는 제한된 기간을 제외하고는 어떤 컴퓨터를 통해서도 데이터에 액세스할 수 없으므로, 온라인 백업 실패 모드로부터 상당히 안전하다. 액세스 시간은 매체가 현장(on-site)에 있는지 외부(off-site)에 있는지에 따라 달라진다.

원격지 데이터 보호

[편집]

백업 매체는 재난이나 기타 현장 특정적인 문제로부터 보호하기 위해 원격지 금고로 보내질 수 있다. 금고는 시스템 관리자의 홈 오피스처럼 간단할 수도 있고, 백업 매체 보관 시설을 갖춘 재난 대비, 온도 조절, 고보안 벙커처럼 정교할 수도 있다. 데이터 복제본은 원격지에 있으면서 동시에 온라인 상태일 수도 있다(예: 원격지 RAID 미러).

백업 사이트

[편집]

백업 사이트 또는 재난 복구 센터는 재난 발생 시 컴퓨터 시스템과 네트워크를 복구하고 적절하게 구성할 수 있는 데이터를 저장하는 데 사용된다. 일부 조직은 자체 재난 복구 센터를 보유하고 있으며, 다른 조직은 이를 제3자에게 위탁한다. 높은 비용 때문에 백업 자체가 재난 복구 사이트로 데이터를 이동하는 선호되는 방법으로 간주되는 경우는 드물다. 더 일반적인 방법은 재난 복구 데이터를 가능한 한 최신 상태로 유지하는 원격 디스크 미러링이다.

데이터 선택 및 추출

[편집]

백업 작업은 일관된 데이터 단위를 선택하고 추출하는 것으로 시작된다. 현대 컴퓨터 시스템의 대부분의 데이터는 파일이라고 하는 개별 단위로 저장된다. 이 파일들은 파일 시스템으로 구성된다. 특정 시점에 무엇을 백업할지 결정하는 데는 절충안이 필요하다. 너무 많은 중복 데이터를 백업하면 정보 저장소가 너무 빨리 가득 차게 된다. 불충분한 양의 데이터를 백업하면 결과적으로 중요한 정보의 손실로 이어질 수 있다.[45]

파일

[편집]
  • 파일 복사: 파일을 복사하는 것은 백업을 수행하는 가장 간단하고 일반적인 방법이다. 이 기본적인 기능을 수행하는 수단은 모든 백업 소프트웨어와 모든 운영 체제에 포함되어 있다.
  • 부분 파일 복사: 백업에는 특정 기간 동안 변경된 파일 내의 블록이나 바이트만 포함될 수 있다. 이는 필요한 저장 공간을 크게 줄일 수 있지만, 복구 상황에서 파일을 재구성하기 위해 더 높은 정교함이 요구된다. 일부 구현 방식은 소스 파일 시스템과의 통합을 필요로 한다.
  • 삭제된 파일: 의도적으로 삭제된 파일이 의도치 않게 복구되는 것을 방지하기 위해 삭제 기록을 유지해야 한다.
  • 파일 버전 관리: 전체 전용/시스템 이미지만 수행하는 애플리케이션을 제외한 대부분의 백업 애플리케이션은 마지막 백업 이후 수정된 파일도 백업한다. "그렇게 하면 주어진 파일의 여러 버전을 검색할 수 있으며, 하드 디스크에서 파일을 삭제하더라도 [정보 저장소] 아카이브에서 여전히 찾을 수 있다."[4]

파일 시스템

[편집]
  • 파일 시스템 덤프: 블록 수준에서 전체 파일 시스템의 복사본을 만들 수 있다. 이는 "원시 파티션 백업"이라고도 하며 디스크 이미지 생성과 관련이 있다. 이 과정은 대개 파일 시스템을 마운트 해제하고 dd와 같은 프로그램을 실행하는 것을 포함한다.[46] 디스크를 순차적으로 그리고 큰 버퍼를 사용하여 읽기 때문에, 특히 파일 시스템에 작은 파일이 많거나 단편화가 심하거나 거의 가득 찬 경우 이 유형의 백업이 모든 파일을 정상적으로 읽는 것보다 빠를 수 있다. 그러나 이 방법은 유용한 데이터가 없는 빈 디스크 블록도 읽기 때문에, 파일 시스템이 거의 비어 있는 경우에는 기존의 읽기 방식보다 느릴 수도 있다. XFS와 같은 일부 파일 시스템은 사용되지 않는 섹션을 건너뛰면서 고성능으로 디스크를 순차적으로 읽는 "덤프" 유틸리티를 제공한다. 대응하는 복구 유틸리티는 운영자의 선택에 따라 개별 파일이나 전체 볼륨을 선택적으로 복구할 수 있다.[47]
  • 변경 사항 식별: 일부 파일 시스템에는 최근에 변경되었음을 나타내는 각 파일에 대한 보관 속성(archive bit)이 있다. 일부 백업 소프트웨어는 파일 날짜를 확인하고 마지막 백업과 비교하여 파일이 변경되었는지 확인한다.
  • 버전 관리 파일 시스템: 버전 관리 파일 시스템은 파일에 대한 모든 변경 사항을 추적한다. 리눅스용 NILFS 버전 관리 파일 시스템이 그 예이다.[48]

실시간 데이터

[편집]

활발하게 업데이트되고 있는 파일은 백업하기에 어려운 과제이다. 실시간 데이터를 백업하는 한 가지 방법은 일시적으로 정지(quiesce)시키고(예: 모든 파일 닫기), "스냅샷"을 찍은 다음 실시간 작업을 재개하는 것이다. 이 시점에서 스냅샷은 일반적인 방법을 통해 백업될 수 있다.[49] 스냅샷은 종종 카피 온 라이트 메커니즘을 통해 특정 시점에 동결된 것처럼 파일 시스템의 사본을 제시하는 일부 파일 시스템의 즉각적인 기능이다. 파일이 변경되는 동안 스냅샷을 찍으면 사용할 수 없는 손상된 파일이 생성된다. 이는 기존 데이터베이스나 마이크로소프트 익스체인지 서버와 같은 애플리케이션에서 볼 수 있는 상호 연관된 파일들 사이에서도 마찬가지이다.[15] 퍼지 백업(fuzzy backup)이라는 용어는 백업이 정상적으로 실행된 것처럼 보이지만 단일 시점의 데이터 상태를 나타내지 않는 실시간 데이터 백업을 설명하는 데 사용될 수 있다.[50]

정지될 수 없거나 정지되지 않은 데이터 파일에 대한 백업 옵션은 다음과 같다:[51]

  • 열린 파일 백업: 많은 백업 소프트웨어 애플리케이션은 열린 파일을 내부적으로 일관된 상태로 백업하는 기능을 수행한다.[52] 일부 애플리케이션은 단순히 열린 파일이 사용 중인지 확인하고 나중에 다시 시도한다.[49] 다른 애플리케이션은 매우 빈번하게 업데이트되는 열린 파일을 제외한다.[53] 일부 저가용성 대화형 애플리케이션은 자연스럽거나 유도된 일시 정지를 통해 백업될 수 있다.
  • 상호 연관된 데이터베이스 파일 백업: 일부 상호 연관된 데이터베이스 파일 시스템은 데이터베이스가 온라인 상태이고 사용 가능한 동안 "핫 백업"[54]을 생성하는 수단을 제공한다. 여기에는 데이터 파일의 스냅샷과 백업이 실행되는 동안 이루어진 변경 사항의 스냅샷 로그가 포함될 수 있다. 복구 시, 로그 파일의 변경 사항을 적용하여 초기 백업이 끝난 시점으로 데이터베이스 사본을 되돌린다.[55] 다른 저가용성 대화형 애플리케이션은 조정된 스냅샷을 통해 백업될 수 있다. 그러나 진정한 고가용성 대화형 애플리케이션은 지속 데이터 보호를 통해서만 백업될 수 있다.

메타데이터

[편집]

컴퓨터에 저장된 모든 정보가 파일에 저장되는 것은 아니다. 사고 발생 후 전체 시스템을 처음부터 정확하게 복구하려면 이러한 비파일 데이터도 추적해야 한다.[56]

  • 시스템 설명: 사고 후 정확한 대체 장비를 조달하기 위해 시스템 사양이 필요하다.
  • 부트 섹터: 부트 섹터는 저장하는 것보다 새로 만드는 것이 더 쉬울 때도 있다. 보통 일반적인 파일이 아니며, 이것 없이는 시스템이 부팅되지 않는다.
  • 파티션 레이아웃: 원래 시스템을 제대로 재구성하려면 파티션 테이블과 파일 시스템 설정뿐만 아니라 원래 디스크의 레이아웃이 필요하다.
  • 파일 메타데이터: 복구 시 원래 환경을 제대로 재구성하려면 각 파일의 권한, 소유자, 그룹, ACL 및 기타 모든 메타데이터를 백업해야 한다.
  • 시스템 메타데이터: 운영 체제마다 구성 정보를 저장하는 방식이 다르다. 마이크로소프트 윈도우는 일반 파일보다 복구하기 더 어려운 시스템 정보 레지스트리를 유지한다.

데이터 조작 및 데이터 세트 최적화

[편집]

백업 프로세스를 최적화하기 위해 백업되는 데이터를 조작하는 것이 종종 유용하거나 요구된다. 이러한 조작을 통해 백업 속도, 복구 속도, 데이터 보안, 매체 사용 효율을 개선하거나 대역폭 요구 사항을 줄일 수 있다.

자동 데이터 정리

[편집]

오래된 데이터는 자동으로 삭제될 수 있지만, 자동 데이터 "정리(grooming)"를 사용자 정의할 수 있는 엔터프라이즈 클라이언트-서버 백업 애플리케이션과 달리 개인용 백업 애플리케이션에서는 삭제[note 2][57][58]가 기껏해야[59] 전체적으로 지연되거나 비활성화될 수 있을 뿐이다.[60]

압축

[편집]

저장될 소스 데이터의 크기를 줄여 저장 공간을 덜 차지하도록 다양한 방식을 사용할 수 있다. 압축은 테이프 드라이브 하드웨어의 내장 기능인 경우가 많다.[61]

중복 제거

[편집]

유사하게 구성된 워크스테이션을 백업함으로써 발생하는 중복을 줄여 단 하나의 사본만 저장할 수 있다. 이 기술은 파일 또는 원시 블록 수준에서 적용될 수 있다. 이러한 잠재적으로 큰 감소 효과[61]를 데이터 중복 제거라고 한다. 이는 데이터가 백업 매체로 이동하기 전에 서버에서 발생할 수 있으며, 이를 소스/클라이언트 측 중복 제거라고 한다. 이 방식은 백업 데이터를 대상 매체로 보내는 데 필요한 대역폭도 줄여준다. 이 과정은 대상 저장 장치에서 발생할 수도 있으며, 이를 인라인 또는 백엔드 중복 제거라고 한다.

복제

[편집]

때때로 백업은 두 번째 저장 매체 세트로 복제된다. 이는 복구 속도를 최적화하기 위해 아카이브 파일을 재배치하거나, 엔터프라이즈 클라이언트-서버 백업의 디스크-투-디스크-투-테이프(disk-to-disk-to-tape) 기능처럼 다른 위치나 다른 저장 매체에 두 번째 사본을 보관하기 위해 수행될 수 있다.

암호화

[편집]

백업 테이프와 같은 대용량 이동식 저장 매체는 분실하거나 도난당할 경우 데이터 보안 위험이 발생한다.[62] 이러한 매체의 데이터를 암호화하면 이 문제를 완화할 수 있지만, 암호화는 CPU를 많이 사용하는 프로세스로 백업 속도를 늦출 수 있으며, 암호화된 백업의 보안은 키 관리 정책의 보안만큼만 효과적이다.[61]

멀티플렉싱

[편집]

대상 저장 장치보다 백업해야 할 컴퓨터가 훨씬 더 많을 때, 여러 개의 동시 백업을 단일 저장 장치에 사용하는 기능이 유용할 수 있다.[63] 그러나 "멀티플렉싱 백업"을 통해 예약된 백업 윈도우를 채우는 방식은 테이프 대상에 대해서만 사용된다.[63]

리팩토링

[편집]

아카이브 파일 내의 백업 세트를 재배열하는 과정을 리팩토링이라고 한다. 예를 들어, 백업 시스템이 매일 단일 테이프를 사용하여 보호되는 모든 컴퓨터의 증분 백업을 저장하는 경우, 한 대의 컴퓨터를 복구하려면 많은 테이프가 필요할 수 있다. 리팩토링을 사용하여 단일 컴퓨터의 모든 백업을 단일 테이프로 통합하여 "합성 전체 백업"을 만들 수 있다. 이는 영구 증분 방식의 백업 시스템에 특히 유용하다.

스테이징

[편집]

때때로 백업은 테이프로 복사되기 전에 스테이징 디스크에 먼저 복사된다.[63] 이 과정은 때때로 D2D2T라고 불린다. 네트워크 기반 백업 시스템에서 자주 직면하듯이, 최종 대상 장치의 속도와 소스 장치의 속도를 맞추는 데 문제가 있는 경우 유용할 수 있다. 또한 다른 데이터 조작 기술을 적용하기 위한 중앙 집중식 위치의 역할도 한다.

목표

[편집]
  • 복구 지점 목표(RPO): 재시작된 인프라가 반영할 시점으로, "중요 사고로 인해 IT 서비스에서 데이터(트랜잭션)가 손실될 수 있는 최대 목표 기간"으로 표현된다. 본질적으로 이는 복구의 결과로 경험하게 될 롤백이다. 가장 바람직한 RPO는 데이터 손실 이벤트 직전 시점이다. 더 최근의 복구 지점을 달성하려면 소스 데이터와 백업 저장소 간의 파일 동기화 빈도를 높여야 한다.[64]
  • 복구 시간 목표(RTO): 재난 발생 후 비즈니스 기능이 복구될 때까지 경과된 시간이다.[65]
  • 데이터 보안: 소유자의 데이터 접근 권한을 보존하는 것 외에도, 승인되지 않은 접근으로부터 데이터를 제한해야 한다. 백업은 원래 소유자의 의무를 훼손하지 않는 방식으로 수행되어야 한다. 이는 데이터 암호화와 적절한 매체 취급 정책을 통해 달성할 수 있다.[66]
  • 데이터 보관 기간: 규정 및 정책에 따라 백업을 특정 기간 동안 보관해야 하지만 그 이상은 보관하지 말아야 하는 상황이 생길 수 있다. 이 기간 이후에도 백업을 유지하는 것은 불필요한 법적 책임과 저장 매체의 비효율적 사용으로 이어질 수 있다.[66]
  • 체크섬 또는 해시 함수 검증: 테이프 아카이브 파일에 백업하는 애플리케이션은 데이터가 정확하게 복사되었는지 확인하기 위해 이 옵션이 필요하다.[67]
  • 백업 프로세스 모니터링: 엔터프라이즈 클라이언트-서버 백업 애플리케이션은 관리자가 백업 프로세스를 모니터링하고 조직 외부의 규제 기관에 규정 준수를 증명할 수 있는 사용자 인터페이스가 필요하다. 예를 들어, 미국의 보험 회사는 HIPAA에 따라 고객 데이터가 기록 보관 요구 사항을 충족함을 입증해야 할 수 있다.[68]
  • 사용자 주도 백업 및 복구: 하나 이상의 파일에 대한 "양호한" 버전을 실수로 삭제하거나 덮어쓰는 것과 같은 사소한 사고를 방지하거나 복구하기 위해, 관리자가 아닌 컴퓨터 사용자가 파일이나 폴더의 백업 및 복구(반드시 가장 최근의 백업일 필요는 없음)를 직접 시작할 수 있다.

같이 보기

[편집]

각주

[편집]
  1. ↑ “back•up”. 《The American Heritage Dictionary of the English Language》. Houghton Mifflin Harcourt. 2018. 2018년 5월 9일에 확인함.
  2. ↑ S. Nelson (2011). 〈Chapter 1: Introduction to Backup and Recovery〉. 《Pro Data Backup and Recovery》. Apress. 1–16쪽. ISBN 978-1-4302-2663-5. 2018년 5월 8일에 확인함.
  3. ↑ Cougias, D.J.; Heiberger, E.L.; Koop, K. (2003). 〈Chapter 1: What's a Disaster Without a Recovery?〉. 《The Backup Book: Disaster Recovery from Desktop to Data Center》. Network Frontiers. 1–14쪽. ISBN 0-9729039-0-9.
  4. 1 2 3 Joe Kissell (2007). 《Take Control of Mac OS X Backups》 (PDF) Version 2.0판. Ithaca, NY: TidBITS Electronic Publishing. 18–20 ("The Archive", meaning information repository, including versioning), 24 (client–server), 82–83 (archive file), 112–114 (Off–site storage backup rotation scheme), 126–141 (old Retrospect terminology and GUI—still used in Windows variant), 165 (client–server), 128 (subvolume—later renamed Favorite Folder in Macintosh variant)쪽. ISBN 978-0-9759503-0-2. 2020년 12월 1일에 원본 문서 (PDF)에서 보존된 문서. 2019년 5월 17일에 확인함.
  5. ↑ 주 사이트의 완전한 파괴가 복구 사이트의 손실로 이어지지 않도록 물리적으로 멀리 떨어진 곳에 배치한다.
    “.ORG Sponsorship Proposal - Technical Plan - Physical Security”. ICANN.
  6. ↑ McMahon, Mary (2019년 4월 1일). “What Is an Information Repository?”. 《wiseGEEK》. Conjecture Corporation. 2019년 5월 8일에 확인함. In the sense of an approach to data management, an information repository is a secondary storage space for data.
  7. ↑ 제프 프리스. "Online Data Backup Reviews: Why Use an Online Data Backup Service?". Top Ten Reviews. 2016.
  8. ↑ 카일 친. "How to Back Up Your Data: 6 Effective Strategies to Prevent Data Loss". 2024.
  9. ↑ "How do you backup your computer? Windows and Mac drive backup". 2023.
  10. ↑ 스콧 길버트슨. "How to Back Up Your Digital Life". 2024.
  11. ↑ “Five key questions to ask about your backup solution”. 《sysgen.ca》. 23 March 2014. Does your company have a low tolerance to longer "data access outages" and/or would you like to minimize the time your company may be without its data?. 4 March 2016에 원본 문서에서 보존된 문서. 23 September 2015에 확인함.
  12. ↑ “Incremental Backup”. 《Tech-FAQ》. Independent Media. 2005년 6월 13일. 2016년 6월 21일에 원본 문서에서 보존된 문서. 2006년 3월 10일에 확인함.
  13. ↑ Pond, James (2013년 8월 31일). “How Time Machine Works its Magic”. 《Apple OSX and Time Machine Tips》. baligu.com. File System Event Store, Hard Links. 2019년 6월 21일에 원본 문서에서 보존된 문서. 2019년 5월 19일에 확인함.
  14. 1 2 Behzad Behtash (2010년 5월 6일). “Why Continuous Data Protection's Getting More Practical”. 《Disaster recovery/business continuity》. InformationWeek. 2011년 11월 12일에 확인함. A true CDP approach should capture all data writes, thus continuously backing up data and eliminating backup windows.... CDP is the gold standard—the most comprehensive and advanced data protection. But "near CDP" technologies can deliver enough protection for many companies with less complexity and cost. For example, snapshots can provide a reasonable near-CDP-level of protection for file shares, letting users directly access data on the file share at regular intervals--say, every half-hour or 15 minutes. That's certainly a higher level of protection than tape-based or disk-based nightly backups and may be all you need.
  15. 1 2 “Continuous data protection (CDP) explained: True CDP vs near-CDP”. 《ComputerWeekly.com》. TechTarget. July 2010. 2019년 6월 22일에 확인함. ... copies data from a source to a target. True CDP does this every time a change is made, while so-called near-CDP does this at pre-set time intervals. Near-CDP is effectively the same as snapshotting....True CDP systems record every write and copy them to the target where all changes are stored in a log. [new paragraph] By contrast, near-CDP/snapshot systems copy files in a straightforward manner but require applications to be quiesced and made ready for backup, either via the application's backup mode or using, for example, Microsoft's Volume Shadow Copy Services (VSS).
  16. ↑ Pond, James (2013년 8월 31일). “How Time Machine Works its Magic”. 《Apple OSX and Time Machine Tips》. Baligu.com (as mirrored after James Pond died in 2013). 2019년 6월 21일에 원본 문서에서 보존된 문서. 2019년 7월 10일에 확인함. The File System Event Store is a hidden log that OSX keeps on each HFS+ formatted disk/partition of changes made to the data on it. It doesn’t list every file that’s changed, but each directory (folder) that’s had anything changed inside it.
  17. ↑ de Guise, P. (2009). 《Enterprise Systems Backup and Recovery: A Corporate Insurance Policy》. CRC Press. 285–287쪽. ISBN 978-1-4200-7639-4.
  18. ↑ Wu, Victor (2017년 3월 4일). “EMC RecoverPoint for Virtual Machine Overview”. 《Victor Virtual》. WuChiKin. 2019년 6월 22일에 확인함. The splitter splits out the Write IOs to the VMDK/RDM of a VM and sends a copy to the production VMDK and also to the RecoverPoint for VMs cluster.
  19. ↑ “Zerto or Veeam?”. 《RES-Q Services》. March 2017. 2019년 7월 7일에 확인함. Zerto doesn’t use snapshot technology like Veeam. Instead, Zerto deploys small virtual machines on its physical hosts. These Zerto VMs capture the data as it is written to the host and then send a copy of that data to the replication site.....However, Veeam has the advantage of being able to more efficiently capture and store data for long-term retention needs. There is also a significant pricing difference, with Veeam being cheaper than Zerto.
  20. ↑ “Agent Related”. 《CloudEndure.com》. 2019. What does the CloudEndure Agent do?. 2019년 7월 3일에 확인함. The CloudEndure Agent performs an initial block-level read of the content of any volume attached to the server and replicates it to the Replication Server. The Agent then acts as an OS-level read filter to capture writes and synchronizes any block level modifications to the CloudEndure Replication Server, ensuring near-zero RPO.
  21. ↑ Gardner, Steve (2004년 12월 9일). “Disk to Disk Backup versus Tape – War or Truce?”. Engenio. Peaceful coexistence. 2005년 2월 7일에 원본 문서에서 보존된 문서. 2019년 5월 26일에 확인함.
  22. 1 2 3 “Digital Data Storage Outlook 2017” (PDF). 《Spectra》. Spectra Logic. 2017. 7(Solid-State), 10(Magnetic Disk), 14(Tape), 17(Optical)쪽. 2018년 5월 7일에 원본 문서 (PDF)에서 보존된 문서. 2018년 7월 11일에 확인함.
  23. 1 2 3 Tom Coughlin (2014년 6월 29일). “Keeping Data for a Long Time”. 《Forbes》. para. Magnetic Tapes(popular formats, storage life), para. Hard Disk Drives(active archive), para. First consider flash memory in archiving(... may not have good media archive life). 2018년 4월 19일에 확인함.
  24. 1 2 3 4 Jacobi, John L. (2016년 2월 29일). “Hard-core data preservation: The best media and methods for archiving your data”. 《PC World》. sec. External Hard Drives(on the shelf, magnetic properties, mechanical stresses, vulnerable to shocks), Tape, Online storage. 2018년 4월 19일에 확인함.
  25. ↑ “Ramp Load/Unload Technology in Hard Disk Drives” (PDF). 《HGST》. Western Digital. November 2007. 3(sec. Enhanced Shock Tolerance)쪽. 2018년 6월 29일에 확인함.
  26. ↑ “Toshiba Portable Hard Drive (Canvio® 3.0)”. 《Toshiba Data Dynamics Singapore》. Toshiba Data Dynamics Pte Ltd. 2018. sec. Overview(Internal shock sensor and ramp loading technology). 2018년 6월 16일에 원본 문서에서 보존된 문서. 2018년 6월 16일에 확인함.
  27. 1 2 “Iomega Drop Guard ™ Technology” (PDF). 《Hard Drive Storage Solutions》. Iomega Corp. 2010년 9월 20일. 2(What is Drop Shock Technology?, What is Drop Guard Technology? (... features special internal cushioning .... 40% above the industry average)), 3(*NOTE)쪽. 2018년 7월 12일에 확인함.
  28. 1 2 John Burek (2018년 5월 15일). “The Best Rugged Hard Drives and SSDs”. 《PC Magazine》. Ziff Davis. What Exactly Makes a Drive Rugged?(When a drive is encased ... you're mostly at the mercy of the drive vendor to tell you the rated maximum drop distance for the drive). 2018년 8월 4일에 확인함.
  29. ↑ Justin Krajeski; Kimber Streams (2017년 3월 20일). “The Best Portable Hard Drive”. 《뉴욕 타임스》. 2017년 3월 31일에 원본 문서에서 보존된 문서. 2018년 8월 4일에 확인함.
  30. ↑ “Best Long-Term Data Archive Solutions”. 《Iron Mountain》. Iron Mountain Inc. 2018. sec. More Reliable(average mean time between failure ... rates, best practice for migrating data). 2018년 4월 19일에 확인함.
  31. ↑ Kissell, Joe (2011). 《Take Control of Backing Up Your Mac》. Ithaca NY: TidBITS Publishing Inc. 41(Deduplication)쪽. ISBN 978-1-61542-394-1. 2019년 9월 17일에 확인함.
  32. ↑ “Symantec Shows Backup Exec a Little Dedupe Love; Lays out Source Side Deduplication Roadmap – DCIG”. 《DCIG》. 7 July 2009. 4 March 2016에 원본 문서에서 보존된 문서. 26 February 2016에 확인함.
  33. ↑ “Veritas NetBackup™ Deduplication Guide”. 《Veritas》. Veritas Technologies LLC. 2016. 2018년 7월 26일에 확인함.
  34. ↑ S. Wan; Q. Cao; C. Xie (2014). 《Optical storage: An emerging option in long-term digital preservation》. 《Frontiers of Optoelectronics》 7. 486–492쪽. doi:10.1007/s12200-014-0442-2. S2CID 60816607.
  35. ↑ Q. Zhang; Z. Xia; Y.-B. Cheng; M. Gu (2018). 《High-capacity optical long data memory based on enhanced Young's modulus in nanoplasmonic hybrid glass composites》. 《Nature Communications》 9. 1183쪽. Bibcode:2018NatCo...9.1183Z. doi:10.1038/s41467-018-03589-y. PMC 5864957. PMID 29568055.
  36. ↑ Bärwaldt, Erik (2014). “Full Control » Linux Magazine”. 《Linux Magazine》.
  37. ↑ “5. Conditions That Affect CDs and DVDs • CLIR”. 《CLIR》.
  38. ↑ Gérard Poirier; Foued Berahou (2008년 3월 3일). “Journal de 20 Heures”. 《Institut national de l'audiovisuel》. approximately minute 30 of the TV news broadcast. 2008년 3월 3일에 확인함.
  39. ↑ “Archival Gold CD-R "300 Year Disc" Binder of 10 Discs with Scratch Armor Surface”. 《Delkin Devices》. Delkin Devices Inc. 2013년 9월 27일에 원본 문서에서 보존된 문서.
  40. ↑ “Optical Disc Archive Generation 2” (PDF). 《Optical Disc Archive》. Sony. April 2016. 12(World’s First 8-Channel Optical Drive Unit)쪽. 2019년 8월 15일에 확인함.
  41. ↑ R. Micheloni; P. Olivo (2017). 《Solid-State Drives (SSDs)》. 《Proceedings of the IEEE》 105. 1586–88쪽. doi:10.1109/JPROC.2017.2727228.
  42. ↑ “Remote Backup”. 《EMC Glossary》. Dell, Inc. 2018년 5월 8일에 확인함. Effective remote backup requires that production data be regularly backed up to a location far enough away from the primary location so that both locations would not be affected by the same disruptive event.
  43. ↑ Stackpole, B.; Hanrion, P. (2007). 《Software Deployment, Updating, and Patching》. CRC Press. 164–165쪽. ISBN 978-1-4200-1329-0. 2018년 5월 8일에 확인함.
  44. ↑ Gnanasundaram, S.; Shrivastava, A. 편집 (2012). 《Information Storage and Management: Storing, Managing, and Protecting Digital Information in Classic, Virtualized, and Cloud Environments》. John Wiley and Sons. 255쪽. ISBN 978-1-118-23696-3. 2018년 5월 8일에 확인함.
  45. ↑ Lee (2017년 1월 25일). “What to backup – a critical look at your data”. 《Irontree Blog》. Irontree Internet Services CC. 2018년 5월 8일에 확인함.
  46. ↑ Preston, W.C. (2007). 《Backup & Recovery: Inexpensive Backup Solutions for Open Systems》. O'Reilly Media, Inc. 111–114쪽. ISBN 978-0-596-55504-7. 2018년 5월 8일에 확인함.
  47. ↑ Preston, W.C. (1999). 《Unix Backup & Recovery》. O'Reilly Media, Inc. 73–91쪽. ISBN 978-1-56592-642-4. 2018년 5월 8일에 확인함.
  48. ↑ “NILFS Home”. 《NILFS Continuous Snapshotting System》. NILFS Community. 2019. 2019년 8월 22일에 확인함.
  49. 1 2 Cougias, D.J.; Heiberger, E.L.; Koop, K. (2003). 〈Chapter 11: Open file backup for databases〉. 《The Backup Book: Disaster Recovery from Desktop to Data Center》. Network Frontiers. 356–360쪽. ISBN 0-9729039-0-9.
  50. ↑ Liotine, M. (2003). 《Mission-critical Network Planning》. Artech House. 244쪽. ISBN 978-1-58053-559-5. 2018년 5월 8일에 확인함.
  51. ↑ de Guise, P. (2009). 《Enterprise Systems Backup and Recovery: A Corporate Insurance Policy》. CRC Press. 50–54쪽. ISBN 978-1-4200-7639-4.
  52. ↑ “Open File Backup Software for Windows”. 《Handy Backup》. Novosoft LLC. 2018년 11월 8일. 2018년 11월 29일에 확인함.
  53. ↑ Reitshamer, Stefan (2017년 7월 5일). “Troubleshooting backing up open/locked files on Windows”. 《Arq Blog》. Haystack Software. Stefan Reitshamer is the principal developer of Arq. 2018년 11월 29일에 확인함.
  54. ↑ Boss, Nina (1997년 12월 10일). “Oracle Tips Session #3: Oracle Backups”. 《www.wisc.edu》. University of Wisconsin. 2007년 3월 2일에 원본 문서에서 보존된 문서. 2018년 12월 1일에 확인함.
  55. ↑ “What is ARCHIVE-LOG and NO-ARCHIVE-LOG mode in Oracle and the advantages & disadvantages of these modes?”. 《Arcserve Backup》. Arcserve. 2018년 9월 27일. 2018년 11월 29일에 확인함.
  56. ↑ Grešovnik, Igor (April 2016). “Preparation of Bootable Media and Images”. 2016년 4월 25일에 원본 문서에서 보존된 문서. 2016년 4월 21일에 확인함.
  57. ↑ Tridgell, Andrew; Mackerras, Paul; Davison, Wayne. “rsync(1) - Linux man page”. 《linux.die.net》.
  58. ↑ “Archive maintenance”. 《Code42 Support》. 2023.
  59. ↑ Pond, James (2012년 6월 2일). “12. Should I delete old backups? If so, How?”. 《Time Machine》. baligu.com. Green box, Gray box. 2019년 10월 27일에 원본 문서에서 보존된 문서. 2019년 6월 21일에 확인함.
  60. ↑ Kissell, Joe (2019년 3월 12일). “The Best Online Cloud Backup Service”. 《wirecutter》. The New York Times. Next, there’s file retention. 2019년 6월 21일에 확인함.
  61. 1 2 3 D. Cherry (2015). 《Securing SQL Server: Protecting Your Database from Attackers》. Syngress. 306–308쪽. ISBN 978-0-12-801375-5. 2018년 5월 8일에 확인함.
  62. ↑ Backups tapes a backdoor for identity thieves 보관됨 5 4월 2016 - 웨이백 머신 (28 April 2004). Retrieved 10 March 2007
  63. 1 2 3 Preston, W.C. (2007). 《Backup & Recovery: Inexpensive Backup Solutions for Open Systems》. O'Reilly Media, Inc. 219–220쪽. ISBN 978-0-596-55504-7. 2018년 5월 8일에 확인함.
  64. ↑ “Recovery Point Objective (Definition)”. 《ARL Risky Thinking》. Albion Research Ltd. 2007. 2019년 8월 4일에 확인함.
  65. ↑ “Recovery Time Objective (Definition)”. 《ARL Risky Thinking》. Albion Research Ltd. 2007. 2019년 8월 4일에 확인함.
  66. 1 2 Little, D.B. (2003). 〈Chapter 2: Business Requirements of Backup Systems〉. 《Implementing Backup and Recovery: The Readiness Guide for the Enterprise》. John Wiley and Sons. 17–30쪽. ISBN 978-0-471-48081-5. 2018년 5월 8일에 확인함.
  67. ↑ “How do the "verify" and "write checksums to media" processes work and why are they necessary?”. 《Veritas Support》. Veritas.com. 2015년 10월 15일. Write checksums to media. 2019년 9월 16일에 확인함.
  68. ↑ HIPAA Advisory 보관됨 11 4월 2007 - 웨이백 머신. Retrieved 10 March 2007
내용주
  1. ↑ "아카이브"라는 용어의 일상적인 사용과 달리, "아카이브 파일"에 저장된 데이터가 반드시 오래되었거나 역사적 관심사인 것은 아니다.
  2. ↑ Rsync 및 CrashPlan과 같은 일부 백업 애플리케이션은 백업 데이터를 제거하는 것을 "정리(grooming)" 대신 "가지치기(pruning)"라고 부른다.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=백업&oldid=41050011"