문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 백업 (문단 편집) === 이렇게는 하지 말자 === 아래는 초보자가 저지르기 쉬운 잘못된 백업 관리방법의 예시들이다. '''거의 다 위의 3개-2종류-1개 다른 곳의 원칙을 안 지키는 예시이다.''' * 원본 데이터와 백업 데이터를 같은 저장소에 해놓는 경우. 이건 백업이 아니라 '''스냅쇼팅'''이라고 부른다. 스냅쇼팅은 스냅쇼팅에 적합한 전문 소프트웨어가 다 있어서 수동으로 스냅쇼팅을 하면 하드 용량이 못 버티고, 사람에 의한 실수는 저지할 수 있지만 진정한 자연재해로부터는 [[버틸 수가 없다]]. * 백업을 한 부만 떠놓는 경우. 별도의 백업 소프트웨어를 사용하는 경우에 해당한다. 백업 자체가 실패할 위험 때문에 백업을 딱 한 부만 떠놓으면 안 된다. 풀 백업 중에 백업 소프트웨어가 뻗어버리면 해당 백업본은 쓸모없는 데이터 덩어리가 된다. 더 나쁜 점은, 백업이 실패했다는 건 높은 확률로 원본 데이터가 파손됐기 때문이라는 것. 즉 망가진 원본+망가진 백업이라는 나쁜 시너지가 발생해서 복원 가능한 데이터가 안 남게 된다. Windows 10의 백업 기능을 사용한다면 주 데이터가 오염되었을 때 그냥 파일 복사하듯이 복구만 하면 되기 때문에 거대 규모의 기업용이 아닌 이상 상관없는 얘기. * 백업을 두 부'''만''' 떠놓는 경우. 전문 백업의 영역으로 가면 이것도 문제다. 백업이 두 개밖에 없으면 하나는 실패하고 하나는 성공할 가능성이 있는데, 일반 사용자 레벨에서는 뭐가 성공한 건지 알 수가 없다. 반면 백업이 세 개가 있는 상황에서 하나가 실패했다면 세 개 모두의 체크섬을 돌려 보면 하나만 다른 게 있을 거고, 그렇다면 그 백업을 유사시에 파기하면 그만이다. 물론 천재지변이 일어나면 두 개가 페일나서 이조차도 의미없을 수도 있지만 증분백업을 빡세게 돌리면 이 단점도 상쇄할 수 있으며 상식적으로 원본 포함 네 개 중 두 개가 뻑날 가능성 보다 세 개 중 한 개가 뻑날 가능성이 높지 않겠는가? * 싸구려 CD에 백업 출처불명의 저가CD는 데이터를 오래 보관하지 못한다. 비싼 CD/DVD가 괜히 비싼 게 아니다. 잘 모르겠으면 CD를 햇빛에 비춰보자. 반투명해 보이면 싸구려일 확률이 높다. 이런건 백업용이 아니라 자료 이동용으로나 쓰자. 이도 저도 모르겠으면 '''검증된 메이커를 쓰자'''. 검증된 메이커의 검증된 형식[* 예를 들어 블루레이는 '''LTH''' 방식이 악명이 높다. 특별히 LTH라고 안 써 있는 '''HTL''' 방식의 디스크가 더 초도기록이 느리고 더 오래되었지만 자료 보존성이 좋다.]의 디스크는 적어도 [[랜섬웨어]] 따위로부터는 버틸 수 있는 저항성을 자랑한다. * SMR 기반 외장 하드디스크 혹은 외장 SSD에 백업하기 SMR는 가격이 저렴한 대신 속도와 안정성이 떨어진다. 자료 이동용으로 쓸만할지도 모르나 중요 데이터 백업용으로는 부적합하다. 외장 SSD 역시 마찬가지다. 물론 자주 들고 다니지 않고 그다지 중요하지 않는 데이터을 백업하는 용도라면 SMR 외장하드나 외장 SSD라도 상관없다. * [[RAID]]가 백업이라고 굳게 믿기 RAID는 서비스 가용성을 위한 기술이지 백업의 기술이 절대 아니다. RAID 어레이에 있는 파일 하나가 손상되면 전체 어레이에 손상된 파일이 기록된다. * 고장났을 때 백업을 무작정 덮어쓰기 이것도 위에 나와있지만, 고장난 데이터도 엄연히 데이터이다. 닥치고 복구 눌렀다가 더 망가졌다고 징징대봐야 늦는다. 고장난 데이터라도 백업(풀 백업)해놓고 복구를 시도하자. 수틀리면 그걸 덮어쓰면 된다. * 중요한 자료를 [[클라우드 컴퓨팅]]에만 [[암호화]] 없이 보관 백업에 앞서, 보안 관점에서 민감한 자료를 평문 상태로 인터넷에 띄운다는 생각 자체가 심하게 문제있는 사고방식이다. 요즘 클라우드 서비스는 기본적으로 모든 통신을 암호화하기는 하지만 해커에게는 매스커레이딩/바이패스라는 악랄한 한 수가 있다. 클라우드 백업 시스템이 여러분의 소중한 자료를 해커에게 고스란히 갖다 바칠 것이다.[* 전문업체 끼고 하는 클라우드 백업은 예외. 이건 보안전문가가 케어해주는거니까 어느 정도는 믿을만하다.] 따라서 클라우드 백업은 추가 백업으로만 사용하고, 조금이라도 유출을 걱정할 만한 데이터는 [[7zip]] 압축의 비밀번호 걸기 등으로 따로 암호화할 필요가 있다. 물론 해당 자료에 보안에 민감한 내용이 전혀 없다면 상관없다. 백업 관점에서도 생각해보면, 클라우드 회사도 생각지도 못한 실수를 할 수 있고, (실제 서버 렌탈 서비스 업체 퍼스트서버(FirstServer)에서 5천여 기업 데이터를 유실시키는 사고를 냈다.) [[http://www.zdnet.co.kr/news/news_view.asp?artice_id=20130610090358|클라우드에 비구름이 끼거나]], [[http://www.yonhapnews.co.kr/society/2014/04/20/0701000000AKR20140420062851061.HTML|불이 나기도 한다]]. 다른 건물에 2중 3중 백업을 하긴 하지만, 뭔가 소프트웨어적으로 꼬이게 될 경우 데이터는 있는데 주인을 찾을 수 없어서 돌려주지 못하는 사단이 나는 경우도 있다. 개인의 백업보다야 안전하겠지만 100% 믿을 것은 못 된다는 점을 명심하자. 물론 비지떡 같은 싸구려 서비스들 대신 [[Amazon Web Services|AWS]], [[Google Cloud Platform|구글]], [[Microsoft Azure|MS]] 등 보안이나 안정성으로 업계 끝판왕인 글로벌기업의 서비스를 돈 들여 쓴다면 상당부분 상쇄되는 단점들이다. 만약에 이 회사들이 털렸다고 한다면 이건 마치 [[슈퍼맨]]이나 [[아이언맨]]이 [[에일리언 아포칼립스|외계인 침략자에게 패배]]했다는 수준의 가정이다. 사고가 아니라도 클라우드 서비스의 제약때문에 백업이 되다 마는 사단도 나기도 한다. 제공 용량 이상의 파일 동기화를 하지 않는건 당연하고, 몇 GB 용량 이상의 파일은 제껴놓고 백업한다든가, 하루 몇 GB의 대역폭만큼만 백업하다 만다든가 하는 일이 빈번하다. 물론 이 문제도 돈만 들이면 무제한 용량, 테라바이트급 단일 파일 업로드, 무제한 대역폭의 이용이 가능하다. * 중요하지 않지만 보존이 필요한 대용량의 자료__(판권이 만료된 애니메이션 등)를 클라우드에 보관. 클라우드의 용량은 가격 대비 크지 않다. 그렇기 때문에 이렇게 보존 우선 순위가 낮으면서 용량이 큰 데이터를 클라우드에 저장하는 건 '''뻘짓'''이다. * 중요하지 않고 재다운로드가 가능해서 보존가치가 없으며 저용량인 자료__라면 클라우드에 보관해도 상관은 없다. 사실 하드디스크를 차지하는 대부분의 것들은 음악, 영화 같은 다운받은 것들일지도 모른다. 이러한 것들을 따로 구분해서 저장하고 클라우드에 사본 올려두면 자신이 신경써서 백업해야 할 데이터 용량이 확 줄어든다. 두배 세배 백업 가능해진다. 정말이지 개인이 작성한 문서라봐야 모으고 모아도 용량은 얼마 안되고, 디카/폰카로 찍은 사진/동영상 정도가 하드를 채워나가긴 하지만 매일 100MB씩 찍어도 1년 40GB 채울까말까한다. 이런경우는 그냥 클라우드에 넣으면 그만이다. 참고로 [[Linux|리눅스]] 사용자는 cp(copy) 말고 rsync 사용하는 게 좋다. 풀 백업 뜰 때마다 한세월 하는 것에서 해방된다. rsync는 복구에도 사용한다. 단 명령어 한 글자 차이로 이상한 데다가 복구해놓거나 하므로 연습은 필수이다. 그런데 rsync는 명령어 이름에서 유추할 수 있듯 자료 동기화용 소프트웨어이다. 완전히 백업용으로 설계된 소프트웨어로는 rsnapshot이 있다[* rsnapshot 자체는 거대한 스크립트 뭉치에 불과하다. 내부적으로 유닉스의 기본 쉘 명령어를 조합해서 작동하며 그 중 핵심 소프트웨어가 rsync이다]. rsnapshot은 백업된 자료를 복구할 때 별도의 소프트웨어가 필요없고 그냥 파일 복사 명령으로 복구가 가능한 등의 많은 장점이 있다. 백업 데이터 압축 기능을 제공하지 않는다는 단점이 있긴 하지만, 동영상 등 이미 압축된 데이터를 백업하는 경우에는 좋은 선택이 될 수 있다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기