이번 편에서는 Bacula가 어떠한 방법으로 백업을 하는지, 그 방법에 대한 개념을 잡아보도록 한다. Bacula는 다소 특이한 방식으로 작동하는데, 처음 보면 뭐가뭔지 이해가 잘 안가고, 언뜻 보면 상당히 복잡해보이기 때문이다. bacula.org에는 이해를 돕기위한 그림이 몇 개 있지만 사실 이게 본인 입장에서는 더 해깔린다. 별것도 아닌건데 어렵게 설명하는 느낌이랄까.

Bacula는 3개의 서비스 데몬과 카탈로그라고 하는 하나의 DB로 구성된다. 결국 총 4개의 서비스 데몬이 필요한 셈인데, 이 4개의 서비스 데몬은 얼마든지 확장이 가능하다. 그렇다면, DB를 제외한 나머지 3개의 서비스 데몬에 대해서 보자.

1. Director Daemon – 클라이언트들과 통신을 한다. 백업 및 복원명령을 직접 제어하며, 공식적으로 하나의 디렉터 데몬은 총 1천여대 정도의 클라이언트를 제어할 수 있다. 포트번호는 9101을 사용한다.
2. File Daemon – Director Daemon으로부터 백업 명령이 들어왔을시, 어떤 파일들을 백업해야하는지 대상 목록을 뽑아낸뒤 해당 파일들을 전송한다. 포트번호는 9102을 사용한다.
3. Storage Daemon – Director Daemon으로부터 백업 명령이 들어왔을시, 파일데몬과 직접 접속하여 파일들이 저장되어야할 백업 장치를 제공하고, 파일을 실제로 저장하는 역할을 수행한다. 포트번호는 9103을 사용한다.

조금 이해가 되실거다. 디렉터 데몬은 하나만 있으면 되지만 규모가 많거나, 혹은 특정한 목적에 의해 서버별로 백업을 나눠서 해야하는 경우라면 디렉터 데몬은 여러 개를 두면 된다. 결국 명령은 디렉터가 내리는 것이므로, 두개의 디렉터에서 하나의 클라이언트에 백업명령을 두번 세번 내리는 것도 가능하다는 얘기다. 물론 그렇게 쓸 일은 없겠지만.

파일데몬의 경우, 대부분의 머신에 설치되는 클라이언트인데, 설정 자체는 아예 손댈 일이 없을 정도로 간단하게 돌아간다. 메모리에 상주해있기만하면 디렉터 데몬에 의해서 알아서 동작하기 때문에 신경쓸 일은 전혀 없다고 봐도 무방하다. 실제로 대부분의 에러는 디렉터 데몬이 돌아가는 서버에서 발생하지, 파일데몬이 설치되어있는 클라이언트에서는 거의 생기지 않는다.

스토리지 데몬은, 머신에 어떤 저장장치가 연결되어있는지를 정의해놓으면 작업별로 특정 장치를 지정할 수 있다. 예를 들어서, 사용자의 FTP 디렉토리는 LTO-5로 백업하고, /etc 디렉토리는 하드디스크에 저장하는 형태도 가능하다. 따라서, 스토리지만 정의해놓으면 디렉터 데몬이 설정대로 파일을 백업해준다. 서버의 규모가 작은 곳이라면, 하나의 머신에 모든 저장장치를 전부 연결하고 디렉터와 스토리지 데몬을 한 서버에서 돌리는 식으로 하면 되겠다. 글쓴이가 일하는 곳에서는 디렉터 데몬은 오픈스택의 한 가상머신에서, 스토리지 데몬은 LTO-5 장치를 연결한 서버에서 운영한다. 그외 모든 물리적인 서버와 오픈스택 가상머신들에 파일데몬을 설치하여 백업 중에 있다. Bacula가 사용하는 CPU 점유율은 무척 낮기 때문에 가상머신에서 돌려도 거의 문제가 없다.

그러면 이제 bacula.org에서 제공하는 그림을 보자.

이제 위의 그림이 쉽게 이해 가실거다. 다만 Admin Workstation이 2대가 보이는 부분은, 관리자의 개인 컴퓨터에서 디렉터 데몬을 통한 모니터링이 가능하다는 것을 보여주는 그림인데, 실제로 3줄짜리 설정파일만 있으면 모니터링이 가능하다. 따라서, 관리자가 여러 명인 상황에서도 각각 자기들의 컴퓨터를 통해서 모니터링이 가능한 것이다.

그러면, 왜 데이터베이스가 필요한지 설명을 할 차례가 왔다. Bacula에는 “카탈로그”라고 하는 일종의 백엔드 서비스가 있는데, 백업되는 파일들의 인덱싱을 한다고 보면 이해가 쉬우실 거다. 즉, 파일 관리의 수월함과 빠른 복원을 위해 백업시마다 파일들에 대한 목록을 DB에 넣어서 관리를 하게되며, 공식적으로 MySQL, PostgreSQL, 그리고 SQLite를 지원한다. 물론, DB가 손상됐을 때를 대비해서 수동으로 복원할 수 있는 방법 역시 제공되는 CLI 툴을 통해 가능하다. 공식적으로는 PostgreSQL을 권장하며, 실제 기업업무용으로 SQLite는 권장하지 않는다.

여기서 어떤 분들은 아마 “어차피 백업된 경로 들어가서 ls 치면 파일목록 다 나올텐데 뭐하러 DB를 쓰는가” 라고 의문점이 생기실텐데, Bacula는 파일의 목록을 DB에 넣고, 실제 파일들은 압축하거나 아니면 그냥 하나의 파일로 묶어서 보관한다. 쉽게 생각해서 tar 명령어처럼 하나의 파일을 만들어서 여기에 몽땅 넣어버리는데, 물론 여기에도 다양한 옵션이 있다. 용어가 해깔릴 수 있으므로, 백업되는 파일들을 몰아넣는 파일을 “볼륨”이라고 부르도록 하자.

1. 볼륨의 용량을 제한할 수 있다. 예를 들어 볼륨 하나당 10기가로 지정해두고 백업을 진행하다 10기가가 넘어가게 되면 또 다른 볼륨을 생성한다.
2. 생성되는 볼륨의 갯수를 제한할 수 있다.
3. 특정 백업분을 삭제할 경우, 사용자는 몇개의 볼륨이 존재하는지, 어떤 파일이 어떤 볼륨에 있는지 상관하지 않아도 된다. 따라서, 목적별로 스토리지를 운영ㅇ할 수 있다.
4. 특정 볼륨에서 특정 백업분만 삭제할 수 있다.
5. 볼륨에 auto-prune을 지원한다.
6. 백업되는 파일들의 유지기간 (Retention) 지정이 가능하며, 기일이 지난 백업분은 Bacula가 알아서 삭제해준다.
7. 특정 백업분을 특정 볼륨에 지정하는 것이 가능하다. 예를 들어, Incremental은 볼륨 AAA, Differential은 볼륨 BBB, Full은 CCC 이런 식으로.
8. 따라서, 백업에 쓸 수 있는 스토리지의 용량이 한정되어있어서 이것을 매번 신경써줘야하는 관리자라면, 이 문제에서 해방될 수 있다.

Bacula의 공식문서에 의하면, 데이터를 저장하는 방식인 Pool이니 Volume이니 하는 것들은 사실상 테이프 백업 장치의 개념을 하드디스크 백업에 적용시키는 거라고 한다. 또한, 하나의 파일로 묶어서 보관한다는게 뭐하러 그렇게 하는건지 다소 이해가 가지않을 수도 있지만, 서버의 보안이 뚫렸거나 관리자가 아닌 유저가 접속해서 백업데이터에 접근하더라도 데이터 자체가 하나 혹은 몇개의 파일에 전부 모아져있기 때문에 내용을 볼 수 없다는 장점이 있다. 따라서, 하나의 파일로 묶는건 보안상 그렇다고 이해하면 되겠다.

스토리지 서버가 다른 곳에 있기 때문에, 재해복구나 Bare Metal Recovery도 가능하다. 평소 서버들을 백업할 때 시스템 전체 (/)를 백업해뒀다면, 나중에 우분투 라이브 씨디 등으로 부팅한뒤 네트워크를 설정해주고 파일데몬을 설치해서 CLI 툴로 복원해주면 되는 것이다.

이것으로 Bacula의 백업 프로세스에 대해서 알아봤다. 복잡해보이지만, 알고보면 무쟈게 간단하다. 정리를 해보자.

1. Bacula는 3가지 서비스 데몬과 데이터베이스로 구성된다.
2. 디렉터 데몬은 일종의 관제탑으로서, 백업/복원/모니터 등등의 모든 작업에 대한 통솔을 한다.
3. 파일 데몬은 어떤 파일이 백업되어야하는지를 목록을 뽑아낸다.
4. 스토리지 데몬은 디렉터 데몬의 백업 및 복원 명령에 의해 저장장치를 제공하고, 데이터를 읽고쓴다.
5. 디렉터 데몬은 백업되는 파일들의 목록과 모든 상황을 데이터베이스에 기록한다.
6. 백업되는 파일들은 볼륨이라는 몇개의 거대한 파일이나 테이프에 기록된다.

다음 편에는 Bacula의 서비스 데몬들을 설치해보도록 한다.