1. 개요
백업(Back-up)의 원래 뜻은 어떤 일에 대비해 예비로, 여벌로 만들어 놓은 계획, 지원책 등을 의미한다.[1] 인원 혹은 자원을 보조하거나 긴급 부재 상황에 대비하는 의미로 사용된다.2. 군사 용어
돌격, 수비하는 팀원을 지원사격, 수류탄 투척 등으로 지원하는것을 의미한다. 축구에 비유하자면 이른바 미드필더다. 어느정도는 위 목차의 백업과 의미가 상통한다고도 할 수 있다. 그러나 군사용어로의 통상적인 백업은 지원사격으로 일컬어지는 편이다.적절한 백업은 아군의 생존율을 높이고 적군의 사망율을 높이는 효과가 있다. 2명이상이 동시에, 혹은 순차로 나타난다면 적의 타점은 자연히 분산되고, 이로서 적의 공격을 나눠받거나 적이 빈공간을 헛치게 될 확률을 높이기 때문이다.
또한 팀원 한명이 갖는 공격의 빈틈을 다른 팀원이 매꿈으로써 순간적인 화력을 높일 수 있다. 자신이 죽더라도 계속해서 공격하는 팀원이 있으니 적의 사망율은 높아지게 된다. 협력플레이를 중시하거나, FPS를 즐기는 유저라면 필수적으로 갖춰야 할 기본 센스라 할 수 있다.
그리고 전원이 적진으로 닥돌하는 것은 충분한 백업 화망 구성에 용이하나, 적도 바보가 아닌지라 모 아니면 도 식 한방러쉬가 아닌 한 금물이다.
3. 컴퓨터 용어
전산에서는 컴퓨터 내의 하드디스크 같은 저장장치에 저장된 자료들을 만일의 사태[2]가 발생해 날아가는것에 대비해 중요한 자료들을 따로 복사해 보관하는 것을 의미한다. 복사가 아닌 이동이거나 원본과 별도로 장기 보관하는 게 주목적일 경우 아카이브라고 따로 구별한다. 백업 vs. 아카이브, 차이를 아는 것이 중요한 이유기업에서는 콜드 백업이라고 자기테이프에 백업해서 백업본을 원거리에 있는 다른 센터에 보내기도 한다.[3] 조선왕조실록 등 인쇄본과 인쇄서류을 여러 권 혹은 여러 장 정도 복제[4]하여 한 곳에만 두지 않고 여러 곳에 둔 것도 백업의 일종.
아래는 그 만일의 사태의 예시들. 어디까지나 일부로, 현실에서는 문자 그대로 온갖 이유로 인해 데이터를 날려먹을 수 있다.
- 사람의 실수: 제일 많다! 아래의 모든 재난 상황을 다 합쳐도 사람의 실수에 의한 데이터 유실 건수에 못 미친다.
- 해커의 공격, 또는 관리자나 직원에 의한 고의적인 사보타주. 인재(人災)가 대부분을 차지한다.
- 악성코드: 특히 랜섬웨어에 감염.
- 기억장치의 노후화나 충격으로 인한 손상 : 모든 저장장치에는 저마다의 수명이 존재한다. 하드 디스크는 특히 외부 충격에 취약하며 SSD와 같은 플래시 메모리는 셀 쓰기 횟수 제한이 존재한다. SD카드는 특히 고온의 환경에 노출되거나 소지품 검사용 엑스레이 등의 요인에 의해 데이터가 손상될 위험이 높다.
- 자연재해, 화재, 전쟁(폭격, 핵무기, EMP 등)에 의한 기억장치의 물리적 파손 및 망실:
이건 백업이고 뭐고 관리자 목숨부터 위험하다특히 전자기 펄스에 당하면 백업 수단이 있어도 컴퓨터, 서버, 스마트폰 등 IT장치를 EMP가 미치지 않는 곳에서 새로 들여와야 한다. 이것 때문에 군용 장비들은 EMP 방호 수단을 갖추고 있다. - 전원 공급 이상(낙뢰, 정전, 누전 등): 웬만한 기업에서는 정기적인 백업뿐만 아니라 무정전 전원 장치 등도 구비해서 예상치 못한 전원 이상에 서버가 내려가지 않도록 대비한다.
- 과열[5][6]
- 운영체제 혹은 프로그램의 오류로 인한 강제 종료 또는 버그로 인한 데이터 손상. 대표적인 예시로 블루스크린.
- 도난
- PC 및 스마트폰 기기의 교체
사실 백업의 대상이 되는 것은 다양하다. 중요한 문서가 유실되는 것을 막기 위해 CD에 구워둬도 백업이고, 운영체제를 통째로 뜨는 것(고스트를 사용)도 백업이다. 그리고 백업은 꼭 디스크나 CD에 하라는 법도 없다. 정말로 중요한 문서를 마이크로필름으로 보관하는 것도 일종의 백업이라고 할 수 있다[7].
하지만 백업해 놓고 관리 안 하면 말짱 꽝으로, 백업을 하고 나서 제대로 되었는지 안전점검이 필수다. 일일이 확인하기 힘들면 백업된 용량 및 파일 개수라도 확인하자. 용량이 이상하게 작으면 백업이 잘못된 거다. (예시 - 바로 가기만 복사된 경우) 물론 성공적으로 돌렸더라도 백업경로가 무사한지 자주 확인해야 할 것이다. 백업을 딱 한 부만 만들어놓는것도 일반적으로 돌발상황 발생시 별 도움이 안된다. 운이 좋아 상황발생 직후에 문제를 인지했다면 복구가 가능하지만 많은 경우 상황발생하고 며칠 지나서야 '이거 날아갔네' 하며 땅을 친다[8][9]. 그리고 부랴부랴 백업 확인해보면 이미 자동 백업 시스템이 망가진 데이터를 백업해서 덮어써놨기에 백업 가능한 데이터도 안 남아있는 상황이 된다. 따라서 백업은 최소한 두 부 이상 풀백업으로 갖고 있어야 한다.
2005년 정보통신부에서 발간한 산업체용 백서로 나와있는 백업 가이드라인이 있는데 여기에 다 적기는 너무 많아서 생략한다.
개인도 알고는 있을 필요가 있는 핵심 원칙만 정리한 간단한 가이드는 안전하고 완벽한 백업을 위한 3-2-1 백업 룰를 참고하자.[10]
기업 수준에서는 기본적으로 Daily, Weekly, Monthly 해서 3단계 백업이 권장된다. Daily가 온라인 증분백업, Weekly가 보통 풀 백업이고 Monthly는 오프사이트 백업이다. 빡센 회사는 Hourly로 스냅샷 백업하기도 한다. 오프사이트 백업은 금고 같은 곳에 계속 쌓이는 것이니 논외로 하고 Weekly 백업을 기준으로 하면 보통 4개에서 6개 정도의 풀 백업을 갖게 되는 셈. 일반인 레벨에선 Weekly를 절반으로 쪼개는 정도에서 타협하므로 일반인 기준에서는 풀 백업이 2세트 있게 된다. 풀 백업 1세트는 아래에서 또 설명하겠지만 없는 거나 마찬가지.
그리고 많은 사람이 착각하는데, RAID1은 리던던트지 백업이 아니다! RAID1은 단지 하드가 뻑나는 상황을 버텨낼 수 있을 뿐, 사람의 실수까지 막아내지 못한다. 대부분의 자료 유실은 사람의 실수에서 비롯된다는 점을 명심하자. 덧붙여, 랜섬웨어에 걸려 파일이 변조되었을 때, RAID1 상태로는 랜섬웨어 걸리기 이전 파일은 유실된다. 따라서 개인 레벨의 적당한 백업의 경우, RAID1보다는 무료 파일 동기화 프로그램 등을 이용해서 적당히 수작업으로 백업하는 게 훨씬 낫다.
만일의 사태가 발생했을 경우 초보자들은 닥치고 복구를 때리는 경우가 많은데, 위에서 언급된 것처럼 백업까지 깨져있는 경우 사태만 더 악화시키는 경우가 있다. 백업을 덮어쓰기 전에 망가진 자료라도 따로 풀 백업을 하나 떠 놓고 작업하는 게 정석이자 상식이다.
한때 인터넷상에서 소위 알바들에게 게시글이 포풍삭제 당할 때 대처법으로 닥치고 백업이란 말도 있었다.
스마트폰은 공장 초기화 때문에 백업을 할때는 되도록 복사를 사용하자[11]. 대안으로 갤럭시라면 Smart Switch를 쓰거나 Send Anywhere 어플을 사용해도 된다(단, 데이터를 주의할 것).
또한 바탕 화면에 수많은 파일을 가득 깔아놓고 쓰는 습관 역시 백업에 하등 도움되지 않는다. 또한 자료 유실 가능성도 높고 아무래도 헷갈릴 가능성도 높다. 바탕화면 내용을 복사하다가 자칫하면 바로가기만 복사되는, 즉 깡통만 복사되는 경우가 비일비재하다(...) 바탕화면 내용을 탐색기(Windows 7 기준)에서 모두 선택 후 일반 폴더로 드래그할 경우 기본 설정이 무려 바로 가기 만들기(...)이기 때문에 많이 저지르는 실수다. 복사 후 용량을 확인하면 간단히 해결될 문제다. 바로 가기의 용량은 일반적으로 4KB 내외라는 점을 명심하자.
윈도우 사용자는 운영체제에서 권장하는 경로에 개인 데이터를 저장하는 게 좋다. 예를 들어 탐색기에서 보이는 '문서', '사진', '비디오' 폴더 들을 말한다. 여기에 보관된 데이터는 윈도우 OS 자체에서 절대 건드리지 않고, 윈도우 자체 백업 소프트웨어가 최우선으로 백업하는 폴더들이며 원드라이브 등의 클라우드 동기화 소프트웨어가 가장 처음 동기화를 설정하는 폴더이다. 단점이라면 랜섬웨어 등의 악성코드가 가장 처음 작업을 시작하는 폴더이기도 하다는것.
백업을 제대로 하려면 구매해야 할 저장장치의 전체 용량은 저장할 데이터 용량의 최소 네 배이다. 저장할 원본 데이터의 디스크 용량이 아닌 원본 데이터의 용량이다. 원본 디스크가 1TB여도 백업 대상이 되는 데이터가 1GB이면 원본 데이터 용량은 1GB로 계산한다. 원본 데이터와 풀 백업 두 부, 그리고 증분 백업을 위한 저장소 공간을 모두 합치면 원본 데이터 크기의 네 배에서 다섯 배 사이가 나온다. 또한 원본과 백업은 물리적으로 서로 다른 저장소에 위치해야 하므로 하드디스크는 최소 두 개가 필요하다. 하드디스크의 물리적 손상도 고려하면 세 개 이상, 원본 데이터의 크기가 디스크 하나에 다 담기지 않아 RAID를 돌린다면 원본 디스크 갯수의 세 배를 구매하든지 아예 LTO테이프 백업을 고려해야 한다. 백업 소프트웨어가 압축을 지원한다고는 하지만 요즘 대용량 데이터는 이미 압축돼있어서 추가적인 압축이 거의 되지 않으므로 큰 도움이 되지 않는다.
각종 매체에서는 특히 SF에 자주 등장하는데, 가장 많이 백업되는 데이터는 강인공지능의 소스 코드 또는 사람의 인격이다.
3.1. 방법
- 새 하드를 구입한 후 기존 하드의 파일을 새 하드에 수작업 복사
(복붙)
간과하기 쉽지만 예로부터 가장 확실하고 간단한 방법. 매체별 특성상 장기간 보관에는 SSD보다 HDD가 권장된다.
간혹 이런 방식의 백업을 얕잡아 보는 경우가 있는데 말도 안되는 소리다. 중요한 데이터일수록 다루기 조심스러울 뿐더러 특정 소프트웨어나 클라우드를 사용한다 해도 그 과정에서 어떤 변수가 생길지 장담할 수 없기 때문이다.
오히려 일반인의 경우는 사진이나 영상, 작업물 등을 백업할 때 별도 전문지식의 필요 없이 다른 하드에 복사한다는 것만으로 최악의 상황을 방지하기에 효과적이라 할 수 있다. 실제론 백업까지 고려하는 사용자가 많지 않은 만큼 입문하기 좋은 방법.
물론 사용 환경이나 직업 특성상 주기적인 데이터 보존이 필요할 경우 백업 관련 학습은 필수다. - 아카이빙 프로그램 (타르볼, rsync 등)을 이용한 수동 백업
아카이빙이란 현재 사용하지 않는 데이터를 압축파알처럼 묶어서 다른 저장 매체로 옮기는 작업이다. 그냥 백업 명령어에서 끝이면 수작업 백업에 비해 잘난 게 거의 없지만, 이 방법의 진가는 작업 스케줄러와 연동된다는 점으로, 수동 백업과 작업 스케줄러의 연동으로 간단하게 윈도에서는 전문 프로그램의 지원이 필요한 수준의 작업을 한 방에 끝마칠 수 있다. 다만 백업 프로그램은 아니기 때문에 추천하지 않는다. - 작업 스케줄러를 사용한 반자동 백업
작업 스케줄러를 통해 특정 시간마다 cmd 스크립트를 작동시켜 백업하는 방식이다. 윈도에서는 백업할 내용이 늘어날 때마다 스케줄러를 뜯어고쳐야 하기 때문에 권장되지는 않는다.
반면 POSIX에서는 명령어 백업이 끝판왕인 것과 마찬가지로 이 역시 백업의 끝판왕 중 하나이다. POSIX계는 cron이나 systemd 등의 작업 스케줄러의 사용이 훨씬 간편하고 타르볼이나 rsync라는 백업 종결자가 기본 명령어로 존재하기 때문에 작업 스케줄러와 간단하게 연동이 되어서 오히려 서버 백업에 있어서 제일 현실적이고, 제일 먼저 고려되는 방법이다. 물론 이도 풀 시스템 백업에 있어 고려되는 방법일 뿐, 파일의 변화를 추적하는 증분 백업에 있어서는 전문 백업 소프트웨어나 ZFS 등 백업 특화 파티션의 사용이 훨씬 낫다. - 파일 동기화 프로그램
바로 위 방법들에서 발전한 방식으로, 본격적인 백업을 구축하기엔 귀찮은 개인 수준에서는 최선의 방법이다. 좋은 프로그램들은 동기화 조건이나 작업 예약 설정도 세세하게 조절할 수 있기 때문에 자동 백업이든 수동이든 편하게 할 수 있다. - 버전 관리 시스템
서브버전, Git 등의 버전 관리 시스템은 특정 폴더의 모든 파일의 변경/추가/삭제를 완벽히 추적할 수 있게 해 준다. 다만 버전 관리 시스템의 특성상 오래된 자료를 지우기가 상당히 힘들다. 사실 버전 관리 시스템은 백업용으로 설계된 것도 아니라 다른 해법을 찾아보는 게 좋다. 나무위키도 이 방식을 사용한다. - 운영체제의 백업 기능(추천)
본래 운영체제들은 시스템의 운용이 목적이지만 운용을 돕기 위한 시스템의 유지/보수기능도 통합적으로 가지고 있는데, 그 일환으로 운영체제에서 백업을 지원하기도 한다.
윈도우의 경우 98, ME, NT도 지원하고 있으며, XP의 경우 사용자의 문서[12]만 백업할수도 있고, 사용자가 원하는 드라이브를 통째로 백업하여 이미지 형태로 저장할수 있다. 비스타부터는 엔터프라이즈 이상에서 백업 및 복원 기능을 제어판에서 지원하는데, XP보다 기능이 좀 더 늘어났다. Windows 10부터는 아예 파일 자체를 복사하고 버전별 기록만 따로 관리하는 식으로 변경되었는데, 이 때문에 백업 하드만 따로 뽑아서 다른 데 붙이더라도 파일을 복구할 수 있을 정도로 안정성이 크게 늘어났다.
애플의 경우, Mac OS X Leopard 10.5 버전부터 타임머신이라는 이름으로 지원하고 있다. 우선 지정한 드라이브의 모든 내용을 백업하고 나중에 수정할 내용이 생기면 수정할 내용을 백업한 이미지에 자동으로 추가해준다. 타임 캡슐이라는 장비를 이용하여 무선 백업도 지원한다.
리눅스의 btrfs[13] 파일시스템이나 솔라리스의 ZFS 파일 시스템도[14] 스크립트만 짜주면 MAC의 타임머신 기능을 거의 똑같이 구현할 수 있다. - 전문 백업 소프트웨어
고스트나 트루이미지같은 백업 소프트웨어. 이외에도 기업에서 사용하는 전문 백업 소프트웨어들이 있다. 개인 사용자가 쓰기에는 너무 강력한 게 문제. 일반인용으로 만들어진 전문 백업 소프트웨어는 Macrium Reflect(윈도우 기반), Clonezilla(리눅스 기반) 등 무료인것도 많다.
3.2. 이렇게는 하지 말자
아래는 초보자가 저지르기 쉬운 잘못된 백업 관리방법의 예시들이다. 거의 다 위의 3개-2종류-1개 다른 곳의 원칙을 안 지키는 예시이다.- 원본 데이터와 백업 데이터를 같은 저장소에 해놓는 경우.
- 백업을 한 부만 떠놓는 경우.
- 백업을 두 부만 떠놓는 경우.
- 싸구려 CD에 백업
- SMR 기반 외장 하드디스크 혹은 외장 SSD에 백업하기
SMR는 가격이 저렴한 대신 속도와 안정성이 떨어진다. 자료 이동용으로 쓸만할지도 모르나 중요 데이터 백업용으로는 부적합하다. 외장 SSD 역시 마찬가지다. 물론 자주 들고 다니지 않고 그다지 중요하지 않는 데이터을 백업하는 용도라면 SMR 외장하드나 외장 SSD라도 상관없다. - RAID가 백업이라고 굳게 믿기
- 고장났을 때 백업을 무작정 덮어쓰기
- 중요한 자료를 클라우드 컴퓨팅에만 암호화 없이 보관
- 중요하지 않지만 보존이 필요한 대용량의 자료__(판권이 만료된 애니메이션 등)를 클라우드에 보관. 클라우드의 용량은 가격 대비 크지 않다. 그렇기 때문에 이렇게 보존 우선 순위가 낮으면서 용량이 큰 데이터를 클라우드에 저장하는 건 뻘짓이다.
이건 백업이 아니라 스냅쇼팅이라고 부른다. 스냅쇼팅은 스냅쇼팅에 적합한 전문 소프트웨어가 다 있어서 수동으로 스냅쇼팅을 하면 하드 용량이 못 버티고, 사람에 의한 실수는 저지할 수 있지만 진정한 자연재해로부터는 버틸 수가 없다.
별도의 백업 소프트웨어를 사용하는 경우에 해당한다. 백업 자체가 실패할 위험 때문에 백업을 딱 한 부만 떠놓으면 안 된다. 풀 백업 중에 백업 소프트웨어가 뻗어버리면 해당 백업본은 쓸모없는 데이터 덩어리가 된다. 더 나쁜 점은, 백업이 실패했다는 건 높은 확률로 원본 데이터가 파손됐기 때문이라는 것. 즉 망가진 원본+망가진 백업이라는 나쁜 시너지가 발생해서 복원 가능한 데이터가 안 남게 된다. Windows 10의 백업 기능을 사용한다면 주 데이터가 오염되었을 때 그냥 파일 복사하듯이 복구만 하면 되기 때문에 거대 규모의 기업용이 아닌 이상 상관없는 얘기.
전문 백업의 영역으로 가면 이것도 문제다. 백업이 두 개밖에 없으면 하나는 실패하고 하나는 성공할 가능성이 있는데, 일반 사용자 레벨에서는 뭐가 성공한 건지 알 수가 없다. 반면 백업이 세 개가 있는 상황에서 하나가 실패했다면 세 개 모두의 체크섬을 돌려 보면 하나만 다른 게 있을 거고, 그렇다면 그 백업을 유사시에 파기하면 그만이다. 물론 천재지변이 일어나면 두 개가 페일나서 이조차도 의미없을 수도 있지만 증분백업을 빡세게 돌리면 이 단점도 상쇄할 수 있으며 상식적으로 원본 포함 네 개 중 두 개가 뻑날 가능성 보다 세 개 중 한 개가 뻑날 가능성이 높지 않겠는가?
출처불명의 저가CD는 데이터를 오래 보관하지 못한다. 비싼 CD/DVD가 괜히 비싼 게 아니다. 잘 모르겠으면 CD를 햇빛에 비춰보자. 반투명해 보이면 싸구려일 확률이 높다. 이런건 백업용이 아니라 자료 이동용으로나 쓰자.
이도 저도 모르겠으면 검증된 메이커를 쓰자. 검증된 메이커의 검증된 형식[15]의 디스크는 적어도 랜섬웨어 따위로부터는 버틸 수 있는 저항성을 자랑한다.
RAID는 서비스 가용성을 위한 기술이지 백업의 기술이 절대 아니다. RAID 어레이에 있는 파일 하나가 손상되면 전체 어레이에 손상된 파일이 기록된다.
이것도 위에 나와있지만, 고장난 데이터도 엄연히 데이터이다. 닥치고 복구 눌렀다가 더 망가졌다고 징징대봐야 늦는다. 고장난 데이터라도 백업(풀 백업)해놓고 복구를 시도하자. 수틀리면 그걸 덮어쓰면 된다.
백업에 앞서, 보안 관점에서 민감한 자료를 평문 상태로 인터넷에 띄운다는 생각 자체가 심하게 문제있는 사고방식이다. 요즘 클라우드 서비스는 기본적으로 모든 통신을 암호화하기는 하지만 해커에게는 매스커레이딩/바이패스라는 악랄한 한 수가 있다. 클라우드 백업 시스템이 여러분의 소중한 자료를 해커에게 고스란히 갖다 바칠 것이다.[16]
따라서 클라우드 백업은 추가 백업으로만 사용하고, 조금이라도 유출을 걱정할 만한 데이터는 7zip 압축의 비밀번호 걸기 등으로 따로 암호화할 필요가 있다. 물론 해당 자료에 보안에 민감한 내용이 전혀 없다면 상관없다.
백업 관점에서도 생각해보면, 클라우드 회사도 생각지도 못한 실수를 할 수 있고, (실제 서버 렌탈 서비스 업체 퍼스트서버(FirstServer)에서 5천여 기업 데이터를 유실시키는 사고를 냈다.) 클라우드에 비구름이 끼거나, 불이 나기도 한다. 다른 건물에 2중 3중 백업을 하긴 하지만, 뭔가 소프트웨어적으로 꼬이게 될 경우 데이터는 있는데 주인을 찾을 수 없어서 돌려주지 못하는 사단이 나는 경우도 있다. 개인의 백업보다야 안전하겠지만 100% 믿을 것은 못 된다는 점을 명심하자. 물론 비지떡 같은 싸구려 서비스들 대신 AWS, 구글, MS 등 보안이나 안정성으로 업계 끝판왕인 글로벌기업의 서비스를 돈 들여 쓴다면 상당부분 상쇄되는 단점들이다. 만약에 이 회사들이 털렸다고 한다면 이건 마치 슈퍼맨이나 아이언맨이 외계인 침략자에게 패배했다는 수준의 가정이다.
사고가 아니라도 클라우드 서비스의 제약때문에 백업이 되다 마는 사단도 나기도 한다. 제공 용량 이상의 파일 동기화를 하지 않는건 당연하고, 몇 GB 용량 이상의 파일은 제껴놓고 백업한다든가, 하루 몇 GB의 대역폭만큼만 백업하다 만다든가 하는 일이 빈번하다. 물론 이 문제도 돈만 들이면 무제한 용량, 테라바이트급 단일 파일 업로드, 무제한 대역폭의 이용이 가능하다.
- 중요하지 않고 재다운로드가 가능해서 보존가치가 없으며 저용량인 자료__라면 클라우드에 보관해도 상관은 없다. 사실 하드디스크를 차지하는 대부분의 것들은 음악, 영화 같은 다운받은 것들일지도 모른다. 이러한 것들을 따로 구분해서 저장하고 클라우드에 사본 올려두면 자신이 신경써서 백업해야 할 데이터 용량이 확 줄어든다. 두배 세배 백업 가능해진다. 정말이지 개인이 작성한 문서라봐야 모으고 모아도 용량은 얼마 안되고, 디카/폰카로 찍은 사진/동영상 정도가 하드를 채워나가긴 하지만 매일 100MB씩 찍어도 1년 40GB 채울까말까한다. 이런 경우는 그냥 클라우드에 넣으면 그만이다.
참고로 리눅스 사용자는 cp(copy) 말고 rsync 사용하는 게 좋다. 풀 백업 뜰 때마다 한세월 하는 것에서 해방된다. rsync는 복구에도 사용한다. 단 명령어 한 글자 차이로 이상한 데다가 복구해놓거나 하므로 연습은 필수이다. 그런데 rsync는 명령어 이름에서 유추할 수 있듯 자료 동기화용 소프트웨어이다. 완전히 백업용으로 설계된 소프트웨어로는 rsnapshot이 있다[17]. rsnapshot은 백업된 자료를 복구할 때 별도의 소프트웨어가 필요없고 그냥 파일 복사 명령으로 복구가 가능한 등의 많은 장점이 있다. 백업 데이터 압축 기능을 제공하지 않는다는 단점이 있긴 하지만, 동영상 등 이미 압축된 데이터를 백업하는 경우에는 좋은 선택이 될 수 있다.
3.2.1. RAID와 백업의 차이에 관한 기술적인 추가 설명
RAID를 사용할 경우, 데이터를 추가로 저장하기에 백업과 같다고 착각을 할 수 있다. 하지만 RAID에는 백업에 필수적인 요소인 무결성 보장이 포함되어 있지 않다. 디스크에 저장되어 있는 데이터는 물리적으로 손상될 가능성이 항상 존재하는데, RAID는 데이터 손상여부를 검증하지 않는다.만약, 디스크 3장을 RAID1으로 묶어서 데이터가 3중으로 저장이 되었다 했을 때, RAID는 디스크가 죽지 않는 한 3개의 데이터가 전부 무조건 옳다고 가정하고 읽는다. 심지어 데이터 3개가 전부 다를 때도!!
이는 RAID라는 기술 자체가 리던던시를 위한 것이라 디스크가 죽더라도 다른 디스크가 이어 받아서 요청을 처리할 수 있어야 한다는 요구사항만 만족시키면 되기 때문이다. 그 데이터가 옳은 데이터인지 판단하는건 RAID의 영역이 아니다.
여기에, ECC라는 기술을 추가로 사용하여 어느 데이터가 옳은 데이터인지 판단하고, 옳지 않은 데이터는 다른 데이터를 통해 복구할 수가 있어야 제대로 된 백업으로 기능하게 된다.
따라서, 제대로 구성한다면 '백업 = RAID(리던던시,이중화,패리티) + ECC'이며, RAID만으로는 ECC 기능이 없어서 백업을 대체할 수 없다.
주로 하드웨어 레벨에서 구현되는 RAID와 달리, ECC는 보통 파일시스템과 같은 소프트웨어 레벨에서 구현이 된다. Btrfs와 ZFS의 경우에는 bit rot 방지 대책이 있어서 파일의 일부분이 1비트 오류가 났을 경우 복구가 가능하며, WinRAR의 경우에는 Recovery Record를 통해 압축 파일의 몇%가 깨져도 복구가 가능하며, 오픈소스 중에서는 par2라는 포맷이 존재한다. 프로그램을 직접 개발한다면 CRC32나 MD5 체크섬을 확인하고 Reed-Solomon ECC 알고리즘을 통해 깨진 데이터를 복구하는 식으로 개발이 가능하다.
ECC 소프트웨어 기술의 발달로, RAID는 오히려 사양길을 걷고 있다. btrfs와 zfs같은 파일시스템과 minio, ceph같은 클러스터 파일시스템의 경우 RAID를 쓰지 않는 것이 오히려 권고사항이다. ECC 시스템을 제대로 설계할 경우, RAID0 어레이가 깨지는 극단적인 상황에서도 모든 파일을 복구할 수 있을 정도이므로, 데이터의 무결성을 보장하는데는 RAID보다 ECC가 중요하다.
문서에서 설명하고 있는 내용에 빗대어 쉽게 이야기하면, RAID는 단순무식하게 파일이 깨진지 확인도 안 하고 복사하여 저장하는 것이고, ECC는 백업한 파일이 옳은지 검증하고 잘못된 파일은 다른 백업으로 복구하는 정책을 마련하는 것으로 볼 수 있다.
3.3. 랜섬웨어에 대응하기 위한 백업 가이드
랜섬웨어에 감염될 경우 로컬 하드 디스크에 저장된 파일 뿐만 아니라 USB메모리, 외장하드, 드롭박스 등 클라우드에 저장된 데이터, 그리고 네트워크 드라이브에 연결된 모든 파일을 전부 감염시키며 만약 이들 대상을 스캔하면서 백업 리포지토리가 발견되면 전부 삭제해버리는 행동을 한다. 이런 악랄한 공격에서조차 살아남기 위해서는 많이 귀찮겠지만 아래 제시하는 방법을 이용할것. 단점은 전부 적지 않은 돈이 든다. 가장 싼 2번 방법조차 1년간 데이터 보호를 해 주는 댓가가 HDD를 하나 사는 가격에 맞먹는다. 말 그대로 보험인 셈.그런데 이 방법으로도 USB메모리나 외장하드의 데이터는 못 지키는 경우가 많다. 이동이 잦은 특성상 일일이 백업 소스 지정을 할 수 없는 경우가 많기 때문이다. 그럼 어쩌라고? 다행히 2번 방법에 언급된 백블레이즈와 크래시플랜은 이런 데이터를 백업해주는 서비스를 제공한다. 또는 만약 3번 방법을 적용할 수 있는 전문가를 보유한 기업 또는 본인이 그런 전문가라면 스크립트를 짜넣거나 고급 설정을 만져서 외장하드도 백업할 수 있을 것이다...
하지만 사실 데이터 유실이 아니라 단순 랜섬웨어의 예방에 가장 효과적인건 무분별한 다중백업 행위보다도 기본적인 백업에 더한 철저한 권한 분리 뿐이다.
윈도우고 유닉스고 상관없이 미디어 매체에 '쓰기'를 할 수 있는 계정을 따로 만들어 두고 평상시에 쓰는 계정에는 읽기와 실행 권한만을 지정해 둔다면 애초에 랜섬웨어고 나발이고 관리자 권한을 탈취한게 아니면[18] 랜섬웨어를 실행한 사용자의 권한만을 가지게 되므로 아무것도 할 수 있는게 없어진다. 물론 그 계정의 home 디렉토리나 내 문서 폴더안에 있는 파일들이야 박살이 나겠지만, 무분별하게 구글 드라이브, 외장하드, SD카드, USB 플래시 메모리등 별의 별곳에 데이터를 기껏 나눠 놓고서는 꼽고 사용하던 와중에 랜섬웨어에 걸려서 태반이 박살나거나 아니면 특정 기간(1주일 등) 동안은 잠복해서 가능한 한 많은 매체와 로컬 네트워크 상의 기기들을 모조리 감염시켜 두다가 터트리는 형태의 제로 데이 공격에는 권한 분할 없이는 속수무책이다.
항상 보안의 가장 기본은 적절한 권한 설정이고, 데이터 관리의 기본은 백업이니 둘을 적절하게 고려하지 않으면 결과는 치명적인 사태로 돌아올 수 있음을 염두에 두어야 한다.
3.3.1. 오프라인(격리 Isolate) 저장소 이용
백업을 DAT나 LTO 등의 테이프로 해서 금고에 넣어버리는 방법이다. 기업에서나 사용할 만한 방법인데 기업 감염 사례가 피해가 몹시 크기에 적어둔다. 하드디스크에 백업해서 금고에 넣는 방법은 비추천. 금고 안에 습기라도 차는 날에는 끝장난다.[19] 테이프는 이런 악조건에서 훨씬 잘 버틴다. 그리고 미래에 HDD인터페이스가 변경돼[20] 연결을 못 하게 되는 사태가 발생할 수도 있다. CD나 DVD는 매체의 염료가 안정성이 떨어져 역시 비추. 정 광학 매체를 쓰겠다면 M-DISC라고 하는 무기물 재료 기반 DVD가 있긴 하다. 이 놈은 보존기간 1000년이라는 무식한 내구성을 자랑한다. 참고로 LTO 테이프의 보존기간은 20년 보증. 다만 랜섬웨어에 대비하는 차원에서 단기간(5~15년 이내) 보존용 백업이 목적이라면 일본제[21] 공DVD, 공CD, 공BD[22]도 나름 저렴하면서 안정적인 백업 방법이 될 수 있다. 특히 기업용이 아닌 개인용 차원에서 백업하는 것이라면 이쪽이 비용 대 효용 측면에서 낫다. 랜섬웨어 대비용으로는 외장하드보다 더 나을 수 있다. DVD/BD-R의 경우 단 한번만 기록되기 때문에 랜섬웨어가 디스크의 데이터까지 건드릴 수 없기 때문.개인이 하는데는 속도와 가격면에서 외장하드만한 게 없지만, 조심할 점이 조금 있다. 외장하드 몇개를 준비해서 돌아가면서 일정 주기로 연결해서 백업하고 분리해놓으면 된다. 계속 연결해놓으면 랜섬웨어에 같이 걸리므로 반드시 분리 보관하고, 백업/복원해야 할 때는 모든 인터넷 연결을 끊고 GParted Live CD 같은 최소 실행 환경에서 작업하자. 리눅스에서 시행하는 자세한 방법으로는 DD 항목 참조.
3.3.2. 전문 클라우드 백업 서비스 이용
Backblaze나 CrashPlan 등의 클라우드 백업 서비스를 이용한다. 이들 백업 서비스는 과거 버전의 자료를 복구하는 기능을 제공하기 때문에 랜섬웨어가 날려버린 파일도 과거 버전을 뒤져서 복구 가능하다.하나 주의할 점이 있는데, 발급된 보안 키를 잃어버리면 안 된다. 이들 클라우드 백업 서비스는 고객에게 발급한 보안 키를 사용해 로컬에서 암호화를 해서 자사의 데이터센터로 데이터를 전송하는 구조다. 데이터의 주인이 본인인 걸 증명했다고 해도 보안 키를 분실했다면 회사 입장에서도 고객의 데이터를 복호화해줄 수가 없다. 국가기관이 작정하고 덤벼들어도 힘들다. 물론 암호화를 옵션에서 끌 수도 있다. 암호화를 꺼도 데이터 전송은 암호화 채널을 사용한다. 저쪽 목적지 데이터센터 안에서 암호화된 상태로 저장되느냐 아니냐의 차이.
3.3.3. 권한이 분리된 백업 서버 이용
이건 아예 백업 서버가 별도로 필요하다. 위의 두 방법에 비해 들어가는 비용는 넘사벽으로 올라간다. 하지만 가장 강력한 보호 방법이기도 하다. NAS사용자 중 시놀로지 제품을 사용하는 경우에는 설정을 잘 만져주면 이 3번 방법을 적용할 수 있다. 능력이 되면 라즈베리 파이 사용해서 만들 수도 있다.제아무리 랜섬웨어라도 마법을 부리는 게 아니므로 서버 레벨의 보안은 뚫지 못한다. 애초에 그게 가능한 랜섬웨어라면 구글이나 아마존 서버를 감염시켜서 대박을 노리지 쪼잔하게 일반 사용자 PC를 감염시키고 있진 않을 것이다. NAS의 설정을 조작해 개인별로 계정을 발급하고 독립된 개인 공간을 할당한다. 이렇게 하면 랜섬웨어가 작동해도 해당 개인의 폴더만 날아간다. 공유 드라이브는 읽기 전용으로 설정하고 관리자만이 쓰기 권한을 갖던지 아니면 스틱키비트(퍼미션 1777, 1775, 1755, 스틱키비트가 적용된 폴더는 다른 사람이 쓴 파일을 임의로 삭제할 수 없다)를 폴더에 적용해놓으면 역시 자기가 올린 파일만 감염돼서 날아간다. 권한이 분리 안된 백업서버는 인터넷나야나 랜섬웨어 감염 사태처럼 없는 거나 다름없다.
일단 여기까지 한 다음에 NAS시스템 내부에서만 동작하는 봇 계정을 하나 만든다. 봇 계정이므로 패스워드는 초강력한 랜덤 패스워드를 부여하거나 아예 네트워크 접속 자체를 막을 것. 봇 전용으로 해야지 이걸 누가 접속할 수 있게 해놓으면 위에서 기껏 분리해 놓은 격리구역이 다 소용없어진다. 이 봇이 특정 주기마다(NAS의 쓰기 부하에 따라 1시간에서 1일) 모든 사용자의 계정 폴더를 스냅샷하게 만들어라. 스냅샷 기능이 없다면 증분 백업을 구동하도록 만든다. 스냅샷은 Btrfs나 ZFS 같은 파일시스템을 사용하는 NAS라면 가능하고 일반 ext4 파일시스템이라면 btrfs업그레이드 패치를 받던가 NAS에서 백업 주기를 1시간, 증분 백업 설정을 해 둔다. ext4라도 LVM Snapshot을 사용할 수 있다.
그리고 랜섬웨어에 감염됐을 경우 감염된 컴퓨터를 싹 밀어버리고 해당 사용자의 계정에 있는 파일을 랜섬웨어 감염 시점 이전으로(증분 백업 기록을 보면 언제 감염됐는지 쉽게 알 수 있다. 감염 시점에 증분 용량이 갑자기 뛰어오른다) 롤백한다. 그러면 피해를 1시간 이내로 제한할 수 있다. 일반적으로 1시간에서 1일 정도는 작업을 날려먹어도 괜찮은 시간일 것이다. 만약 분 단위도 중요한 작업을 하는 경우라면(예를 들어 실험실에서 데이터 수집중이거나) 애초에 인터넷에 연결조차 하지말고 써라.
맥에서 사용 가능한 대체재로는 타임머신이라는 백업 소프트웨어가 있다. 하지만 랜섬웨어가 시스템 관리자 권한까지 뚫어버리면(OS취약점을 이용하면 가능하다) 타임머신도 삭제해버린다. 타임머신을 외부 저장 장치에 저장한 후 분리시켜 놓거나, 외부 NAS에 지정한 다음에 NAS의 봇으로 또 한번 백업하게 해야 그제야 랜섬웨어로부터 완전 방호가 가능해진다.
3.3.4. 드롭박스나 구글 문서를 이용한 백업
잘 모르는 사람이 많은데, 드롭박스는 올라간 파일의 과거 버전을 일정 기간 가지고 있다. 파일을 하나하나 일일이 복구해야 하는 게 문제지만 아예 손놓고 있기보다는 파일 몇 개라도 복구하는 편이 낫지 않겠는가? 물론 복구 성공률이나 작업 효율은 전문 백업 소프트웨어나 백업 전문 클라우드 서비스에 비해 매우 낮으니 여기에 너무 의존하지는 말자.참고로 파일 과거 버젼을 유지하는 방법은 구글 문서(Google Docs)에서도 제공하는 방법이니 이쪽을 이용하는 것도 괜찮을 수 있다. (다만 인터페이스가 약간 복잡해서, 버젼 방식으로 저장하려면 매번 업로드할 때마다 버젼 업데이트라는 걸 이용해야 한다.) 물론 폴더에 암호를 건다거나 그런 것은 힘들지만, 드롭박스 같이 허가된 계정에 한해서 접근하게 하는 등의 방식을 이용하는 건 충분히 가능하다.
[1] 예시: We need a backup now!![2] 데이터를 다루는 관리자나 관계자들은 이를 "재해"라고 한다.[3] 이것을 "소산"이라 한다.[4] 이 때 필사, 활자, 타자기, 복사기 등이 사용된다. 요즘이야 기술의 발전으로 복사기, 전산화한 후에 그 데이터를 백업하기 또는 인쇄하기 같은 편리한 방법을 주로 쓰고, 그 이외의 방법은 잘 안쓰긴 하지만.[5] 개인 레벨에서는 청소를 게을리해서 먼지가 쌓이거나 컴퓨터를 지나치게 혹사할 때만 발생하지만, 대규모의 장비를 지속적으로 유지해야 하는 서버실이나 회사 등에서는 공조기가 고장나면 하드디스크가 너무 뜨겁게 달아올라 장비가 꺼지거나 데이터가 손상되는 경우도 있다.[6] HDD의 경우는 물론 방심하면 안되겠지만 그래도 기계적으로 사용되는 하드 디스크라 가장 조심해야 할 충격과 충돌 등을 겪지만 않으면 크게 문제될 건 없지만 SSD의 경우 반대로 충격엔 어느 정도 내성이 있어도 아직까진 온도에 약하므로 더더욱 조심해야 한다.[7] 보통 마이크로필름화하는 건 백업보다는 아카이빙으로 분류하지만...[8] PC사용자 기준으로 팁을 알려주자면 원본 폴더와 백업한 폴더의 속성에 들어가서 용량의 마지막 세 자리(...693바이트 같이)가 동일한지 확인하면 유용하다. 어지간하면 첫 자리 ~ 끝 자리 모두 확인하자. 그리고 파일, 폴더 개수도 확인할 것. 단, 디스크 용량은 포멧 형식에 따라 달라지기 때문에 의미없다. 하지만 할당 단위 크기가 같다면 이것도 확인해보자.[9] 개인용 PC를 쓰는 사람은 상황 발생하자마자 바로 알 수도 있지만 서버 돌리는 사람은 며칠 지나서 알아채는 경우도 흔하다.[10] 검색하기조차 귀찮은 사람을 위해 요약하면 백업은 적어도 세 개를 적어도 두 형태의 매체(예: 둘을 블루레이에 백업했으면 적어도 하나는 HDD나 Secure Digital 등을 사용하자)에 적어도 하나는 다른 곳에(몸에 휴대, 전당포, 직장, 금고 등...) 보관해야 한다는 원칙이다.[11] MTP의 오류로 파일을 이동시키면 파일만 삭제되고 이동이 안 될 때가 많다.[12] 즐겨찾기, 내문서, 그리고 가장 중요한 사용자 프로필 정보 등[13] btrfs는 아직 정식버전이 등장하지 않았고, 에러 레커버리 같은 매우 중요한 기능이 여전히 빠져있기때문에 중요자료에 사용은 절대 비추천이다.[14] 현존하는 가장 진보된 파일 시스템이다. 리눅스/BSD에도 포팅되어있지만, 솔라리스에서 가장 잘 작동한다. btrfs 정식버전이 등장하기 전까지 경쟁자는 없을 것으로 예상된다. 다만, ZFS는 대단위 엔터프라이즈급을 바라보고 나온 파일시스템이라, 데스크탑에서는 오버킬이라 볼 수 있는 수준의 데이터 안정성을 제공하며 좋은 퍼포먼스를 위해서는 메모리를 상당히 많이 할당해야 하고 SSD를 전용캐시로 사용하는등의 흠좀무한 세팅을 지원한다. 물론, 저런 흠좀무한 세팅을 사용할시 퍼포먼스와 안정성은 일반 파일 시스템과는 비교불가이며, 고가의 하드웨어 레이드카드급이다.[15] 예를 들어 블루레이는 LTH 방식이 악명이 높다. 특별히 LTH라고 안 써 있는 HTL 방식의 디스크가 더 초도기록이 느리고 더 오래되었지만 자료 보존성이 좋다.[16] 전문업체 끼고 하는 클라우드 백업은 예외. 이건 보안전문가가 케어해주는거니까 어느 정도는 믿을만하다.[17] rsnapshot 자체는 거대한 스크립트 뭉치에 불과하다. 내부적으로 유닉스의 기본 쉘 명령어를 조합해서 작동하며 그 중 핵심 소프트웨어가 rsync이다[18] 윈도우에서 관리자 권한을 묻는 UAC(사용자 계정 컨트롤) 창이 뜰때 제발 아무 생각 없이 확인만 연타하지 말자. 반드시 지금 어떤 프로그램에 권한을 부여하려 하는지를 적절하게 고려해야 한다. 유닉스도 아무데나 sudo를 남발하다 보면 박살나는건 아무리 유닉스라도 똑같다.[19] 사실 끝장난다는 것은 좀 과장이고 복구가 가능하긴 하다. 다만 복구 비용이 좀 들어가고, 복구율이 100%가 아니라는 게 문제이지만.[20] 2000년대 중반까지만 해도 IDE 방식의 HDD가 일반적이지만, 2017년 현재는 SATA 방식으로 물갈이되었다.[21] 일본제가 아니더라도 버바팀 제품도 품질이 괜찮은 편이다.[22] 일반인 수준에서는 라이터가 비싸긴 하지만 10만원 내외에 2~10년간 랜섬웨어 저항성을 가지는 나쁘지 않은 선택지이다. 저장해야 할 파일 단위가 하나에 수백 메가에서 수 기가를 가볍게 넘나드는 2021년 현재에는 특히 DVD보다 보존연한이 약간 짧지만 단순 랜섬웨어 저항 목적이라면 편의성이 높다.