해당 글은 100 퍼센트 정확하지 않을 수 있으며 제가 경험에서 취득한 것들을 정리하는 형태의 글입니다. 그래서 혹시 잘못된 부분을 발견하여 코멘트 주신다면 감사합니다.

해당 시리즈가 업데이트 된다면 업데이트 내용 또한 기록될 것 같습니다.

백업은 아무리 강조해도 지나치지 않는다는 말이 있다. 항상 데이터는 어떠한 이유로든 날아갈 수 있기 때문이다. 주로 사람의 실수 때문에 날아가는 경우가 많지만 컴퓨터 시스템 상의 문제나 화재 등의 재난으로 날아갈 수도 있기 때문이다. 다들 컴퓨터 프로그램이 강제 종료되거나 아니면 OS가 오류가 생겨 재설치를 해봐야했건 경험을 했을 것이다. 혹은 해킹을 당해 데이터를 날려본 경험도 흔친 않지만 해봤을 것이다. 그런 경우에 대비하여 백업은 중요하다. 백업은 성실성의 문제인 편이다. 보통 회사 업무는 어떤 양식을 받아서 그걸 수정하는 류의 일이 많은데 수정하기 전에 다른 이름으로 저장하여 작업 날짜와 작업자 이니셜을 파일 이름 뒤에 붙이는 류의 일도 백업이라고 말할 수 있겠다.

아카이브와는 조금 다른데 아카이브는 보통 장기기록보관, 백업은 예비 데이터라고 생각하면 된다.

생각보다 백업은 유용하고 중요한데 귀찮다. 백업이 성실성의 문제라고 말하는 것과 비슷한 맥락이기도 하다. 스케쥴러 같은 일정시간마다 실행하는 데몬에 올리면 자동으로 되니 확인만 하면 되기도 하기도 하고 말이다. 실제로 서비스의 이중화도 없고, 하드디스크도 10년 넘게 쓴 장비도 백업은 잘 되어 있어 현역으로 돌아가고 있기도 한다.

백업 전략

그렇다면 백업 전략은 어떻게 세우는게 좋을까?

보통 3-2-1 전략을 많이 세운다. 3-2-1 전략은 백업에서 많이 사용되고, 유용하게 사용되는 전략이다.

3은 최소 3개의 복사본이나 3개의 버전을 보유한다는 것을 이야기 한다. 3개가 다 고장나는 경우는 무척이나 드물기 때문이다.

2는 2개의 다른 미디어를 이야기 한다. 아무리 버전이나 복사본을 많이 만들어도, 같은 미디어에 있다면 미디어 자체가 고장나면 소용이 없기 때문이다. 하나의 하드디스크에 파티션을 다르게 한다고 하더라도, 하드디스크 자체가 망가지면 소용이 없다는 뜻이다. 그렇기에 항상 백업 중 하나는 다른 미디어에 보관하는 것이 좋다.

1은 오프사이트 백업을 한 개는 가지고 있어야한다는 뜻이다. 이 오프 사이트는 한 버전 이상의 백업 복사본은 백업본과 다른 물리적 장소에 저장해야한다는 뜻이다. 예를 들어 서버룸이 불이 나거나 정전이 난다던지, 아니면 랜섬웨어가 백업 서버까지 침투하여 일시에 작동한다던지 등의 사태를 예방하기 위해서 필요한 것이다.

말이 3-2-1 해서 어렵지 직접 설명하면 좀 더 이해하기 쉬울 것이다.

원본 웹서버에 하드디스크를 두 개 연결해서 원본 하드디스크에서 미러 디스크로 매일 새벽에 복사하도록 한다. 해당 백업은 작업자가 실수했을 때 유용하게 쓰인다.

원본 웹서버, 원본 디스크에서 백업서버로 중요 디렉토리를 복사해서 압축한다. 매일 백업해서 7일치 정도를 보관한다. 중요 디렉토리에는 아파치 설정, 웹사이트의 원본 주소, DB 덤프 등이 있다. 해당 백업은 서버를 교체하거나, 복구 요청이 들어왔을 때 사용한다.

그리고 마지막으로 3개월에 한 번씩 백업 서버에 있는 것을 오프라인 사이트로 보관한다. 백업 서버에 HDD를 HDD 도커로 연결하여 백업한다. HDD는 충격에 약하기도 하고, 이 HDD도 고장날 수 있으므로 HDD 두 세트를 번갈아 가며 사용한다. 그러면 HDD 한 세트는 6개월마다 업데이트 된다. 해당 백업은 최악의 경우, 랜섬웨어로 문제가 생겼을 경우 등에 사용한다.

레이드, RAID

레이드라는 것도 있던데 그걸 쓰면 안되나요? 안타깝게도 레이드는 백업이 아니다. 레이드는 디스크를 효율적으로 쓰기 위해 묶는 기술인데 디스크의 신뢰성을 높이는 기술이다. 데이터 쓰기 읽기가 실시간으로 이루어지고, SYNC가 종종 깨지며, 깨졌을 경우 귀찮은 점에서 백업과 다르다. RAID가 메인이었던 글은 아니기에 나중에 내용을 덧붙여보겠다.

백업에 쓰면 유용한 툴

백업에 기본인 3-2-1에 대해 설명한 걸 보다가 백업 디렉토리와 원본 디렉토리의 다른 부분만 가져오면 좋겠다는 생각을 할 수 있을 것이다. 그런데 그러기 위해서는 우리가 흔히 쓰는 복사 명령어로는 어렵다. 복사 명령어는 통째로 복사하기 때문에 중복되는 부분은 복사를 안할 건지 덮어쓸 건지 선택해야한다. 이게 한 두 개 파일이면 모를까 1TB씩 되는 파일들을 그러기는 어렵다.

그래서 rsync와 rclone 이란 툴이 있다. 둘다 변경 분에 대해서만 바꾸는 sync가 가능하기 때문에 사용하기 매우 편리하다.

rsync보다는 rclone이 좀 더 현대적이다. 여기서 현대적이란 말은 좀 더 사용하기 편하고 세련됐다는 뜻이기도 하다.

설정 방법은 따로 적어두지 않으려고 한다. 설정은 경우에 따라 무수히 많은 경우에 수가 있기 때문이다. 그래도 rsync 같은 경우에는 홈페이지에 자동화 스크립트에 대한 예제가 나와있다. 물론 설정에 대한 문서 또한 존재한다.

쉡스크립트 예제 : https://rsync.samba.org/examples.html

설정 문서 : https://download.samba.org/pub/rsync/rsyncd.conf.5

rsync 를 처음 셋팅 할 때 헷갈릴 수 있는데 rsync는 xinted 데몬과 연동해서 쓰거나(/etc/xinetd/rsync) 설정 필요, ssh로 접속하여 사용할 수 있다(명령어 사용시 옵션 -e ‘ssh -p 포트번호’ 필요)

rclone 은 좀 더 현대적이라고 이야기 했다. 그래서 확실히 rsync는 메일링 리스트를 운영하는 방면, rclone는 포럼을 운영한다. 아직 Golang을 잘 모르고 Go 예찬론자는 아니지만, rsync에 C가 주로 쓰인것에 비해 (https://github.com/WayneD/rsync) rclone은 Golang이 주로 쓰인 것 또한 현대적이다.(https://github.com/rclone/rclone) 본디 rclone은 클라우드 스토리지로의 백업을 위해 나왔다. 지원되는 클라우드 스토리지는 우리가 흔히 쓰는 구글 드라이브나 드롭박스도 있고, 아마존 S3, 메가 드라이브, 원드라이브, SMB, FTP, Storj, 백블레이즈 B2도 있다. 물론 로컬간의 복사도 가능하다. 그리고 rclone은 원격지의 드라이브를 가상 파일시스템(vfs)로 마운트해서 쓰는 것도 가능하다. 주변의 평을 들어보면 rsync 보다는 rclone이 빠르고, 효율적인 이야기를 많이 들었다. rclone으로 원격 서버를 로컬로 옮겨오는 방법은 여러개가 있지만 그 중에서 많이 쓰이는 것은 SFTP, VFS가 있다.