이번 편에서는 설정의 최종판, 끝판왕 되시는 Director 데몬이다. 지금까지 쭉 봐왔듯, 스토리지 데몬이나 파일데몬에서는 그다지 설정할 게 없었고, 결국 그 의미는 어디선가는 모든 책임을 지는 무언가가 있다는 의미인 것이다.  앞서 설명했듯, 디렉터 데몬은 지휘소 같은 개념으로서 백업에 관한 모든 명령어를 내리는 데몬이므로 가장 중요한 데몬이다.  역시 마찬가지로 일단 그림부터 보자.

 

딱 봐도 복잡하다.  그냥 봐서는 이해가 안갈거고, 차후에 설명할 CLI툴로 봐도 이해가 안가실 거다.  나중에 GUI툴로 보면 그때 이해가 가실 거다.

디렉터 데몬은 다른 데몬들과 마찬가지로 디렉터, 모니터, 메시지 이 3개의 섹션은 공통적으로 존재하되, 여기서 추가적으로
1. 파일을 저장하는 명령을 내리기 위해 어떤 백업은 어떤 스토리지를 이용할 것인지에 대한 스토리지 데몬 지정
2. 스케쥴 지정
3. Job 지정 (밑에서 따로 설명한다)
4. 어떤 파일들을 백업할 것인지에 대한 백업대상 지정 (FileSet)
5. 파일 데몬이 설치된 클라이언트 지정
6. 각종 에러 및 성공 메시지 처리 지정
7. 파일이 저장될 공간인 Pool 지정 

이렇게 7개의 섹션이 더 존재한다. 따라서, 디렉터 데몬의 설정파일은 프로그래밍 소스코드 마냥 몇백 몇천 라인 정도 되긴 하지만, 규모가 큰 곳에서 같은 일을 하는 컴퓨터가 많을 경우 상당히 효율적으로 백업을 구성할 수 있다. 이 부분에 대해서는 디렉터 데몬 설정파트 이후에 별도로 설명드린다 (설정파일의 분리가 가능하다).  길고 긴 설명을 편하게 하기위해 몇 가지를 정해두고, 전 편에서 설정했던 것들을 다시 짚어본다.

데스크탑 1, 웹서버 1, MySQL DB서버 1, FTP 서버 1.  이렇게 총 4대의 머신이 있고, 여기서 우리는 DB 서버에서 디렉터 데몬을 운영하기로 한다.  스토리지 데몬은 FTP에서 운영하며, 4대 모두 백업이 되어야하므로 파일 데몬은 4대 모두 운영한다.  앞으로 디렉터 데몬은 DIR, 스토리지 데몬은 SD, 마지막으로 파일 데몬은 FD라고 부르도록 한다.

DB서버로 옮겨서 작업을 시작하자.  DIR을 설치하기 전에 MySQL부터 설치한다.  FD은 앞서 이미 설치했으므로 DIR 설치는 금방 끝날 거다.  MySQL DB 서버가 운영 중인 가상머신이나 혹은 이글을 보고 실습 중이신 분이 DIR을 운영하기로 결정한 머신에 접속해서 DIR을 설치한다.

$ sudo apt-get install mysql-server mysql-client
$ sudo apt-get install bacula-director-mysql

설치하는 도중에 MySQL 사용자 생성을 위한 MySQL root의 비밀번호를 묻고나서, DIR의 DB 유저명과 비밀번호 입력을 요구할 것이다.  편한대로 넣으면 되고, 중간에 실수가 있었을시 dpkg-reconfigure bacula-director-mysql 명령어로 정정하면 되겠다.  아니면 MySQL 접속해서 유저와 데이터베이스를 생성해주고난 뒤, DIR의 설정파일에서 직접 수정해주면 된다.  설치가 끝났으면 운영 중인지 확인해보자.

$ ps ax | grep bacula-dir

글쓴이는 netstat -ltnp로 포트가 열려있는지도 꼭 확인해볼 것을 추천한다.  왜냐하면, DB접속에서 에러가 발생할 경우, ps로 확인해보면 디렉터 데몬의 프로세스는 메모리에 떠있지만 실제로 운영은 되지않는 상태가 되기 때문이다.

Bacula를 터미널에서 제어할 수 있는 bconsole이라고 하는 CLI 툴을 설치한다.  일단은 설치만 하고, 운용법은 추후 설명한다.

$ sudo apt-get install bacula-console


이제 DIR의 설정파일을 보도록 하자.  파일의 위치와 이름은 /etc/bacula/bacula-dir.conf 이다.  디폴트값으로 작성되어 나오는 설정파일의 길이가 300라인이 넘기 때문에 섹션부터 간략하게 살펴본 뒤, 각 섹션별로 다시 차근차근 살펴보자.  섹션부터 나열한다.

Director {}
JobDefs {}
Job {}
FileSet {}
Schedule {}
Client {}
Catalog {}
Messages {}
Pool {}
Console {} 


이제 수정해야할 것을 설명하는데, 위에 나열된 대로 설명하진 않고 글쓴이가 원하는 순서로 설명할 예정이다.  왜냐하면, Jobs, JobDefs, Client, 그리고 FileSet은 항목이 아주 길며, Director, Catalog, Console은 항목이 하나만 있으면 되기 때문에, 일단 하나만 있으면 되는 항목들부터 설명하고, 이후부터 짧은 순서대로 설명하도록 하겠다.  참고로, Bacula의 설정에서는 사실 순서는 아무 상관없다.

1. Director {}
이 항목은 디렉터 데몬, DIR의 기본적인 사항을 설정하는 부분이다.  보통은 건드릴 건 없고 수정해야할 사항은 딱 두가지인데, 하나는 전편에서 우리가 쓸 MySQL DB로 쓸 현재 이 DIR의 서버이름인 dbserver-dir이 Name 항목에 똑같이 되어있는지 확인하고, 다른 하나는 DirAddress 항목에서 만약 내부적으로 쓰이는 FQDN이 있으면 그것을 넣어준다.  없으면 그냥 IP 주소를 넣어준다.  만약 이름을 바꿀 경우, 모든 FD과 SD의 디렉터 이름을 전부 다 바꿔야한다.  그러니, 그냥 우리가 하기로 했었던 이름인 dbserver-dir을 사용하도록 하자.

한 가지 더 수정을 한다면, Maximum Concurrent Jobs라는 항목이 있는데, 말 그대로 "최대 동시 작업수"를 지정하는 항목이다.  따라서 반드시 한 번에 한 서버만 백업이 실행되길 원하거나, DIR을 실행하는 서버의 성능이 떨어진다면 이 숫자를 조절하면 되겠다.


2. Catalog {}
Bacula는 백업하는 데이터를 빠르고 안전하게 관리하기 위해 DB를 사용한다고 앞서 설명했다.  보통은 apt-get으로 설치하면 설치과정 중 DB Username과 Password를 묻게되고, 그 부분이 여기에 저장되게 된다.  따라서, 설치 과정 중 뭔가 잘못됐다고 하더라도 여기서 잘 설정해주면 된다.  보시면 아시겠지만 어려운 건 없다.


3. Messages {}
Bacula는 백업의 성공, 혹은 에러 등에 대해 발생하는 모든 메시지들을 이메일로 보내주는 기능이 있다.  자세히 보면 Messages 섹션은 이름은 같되, 내용은 다소 짧은 같은 이름의 섹션이 하나 더 존재하는데, 하나는 이름이 Standard이며 다른 하나는 이름이 Daemon으로 되어있다.  Standard는 백업 및 복원의 실행 결과에 대한 메시지를 담당하며, Daemon은 그외 DIR, FD, SD간의 통신에 대해 발생하는 에러를 담당한다.

mailcommand 항목에서 smtp 서버의 호스트명만 설정해주면 나머지는 알아서 보내준다.  그리고 mail = root@localhost 항목의 발신자명만 바꿔주면 그외에는 특별히 건드려줄 부분은 없어보인다.


4. Console {}: 놔둔다. 현재로서는 건드릴 게 없다.


5. Storage {}
본격적인 설정의 시작이다.  여기서부터는 환경별로 다양한 설정이 나올 수도 있고, 갖고있는 장치별로 여러가지 설정을 해줄 수 있는 다양한 옵션이 제공되지만, 일단 하나만 명심하자.  Storage 섹션은 "저장장치의 지정"만 한다.  그러니까, 백업에 쓸 장치가 하드디스크인지 아닌지, 그리고 어디에 붙어있고 이름은 뭐고 등에 대한 것만 지정한다는 얘기다.  만약 백업에 쓸 장치가 다른 서버에 붙어있다면, 그 서버에는 SD(스토리지 데몬)만 설치하고 여기 설정파일에는 지정만 해주면 된다는 얘기다.  무척 편하다.  전편에서 설명드렸듯, 이 매뉴얼에서는 FTP 서버로 쓸 머신에 붙어있는 하드디스크 2개를 백업용으로 쓸 예정이다.  현업에 계시는 분들을 위해 이전 편에서 LTO-5의 실제 설정을 올려드렸다.

일단, 첫번째 하드디스크인 sda1은 OS용이므로 백업용도로는 건드리지 않기로 하자.
두번째 하드디스크인 sdb1은 /mnt/backup-1에 마운트 되어있다.  이것을 우리는 "Server Backup"이라는 이름을 붙이고, bacula라는 디렉토리를 만들어서 서버를 백업하는 용도로 사용하도록 하자.
세번째 하드디스크인 sdc1은 /mnt/backup-2에 마운트 되어있다.  이것을 우리는 "User Data Backup"이라는 이름을 붙이고, 역시 마찬가지로 bacula라는 디렉토리를 만들어서 FTP의 자료들을 백업하는 용도로 사용하도록 하자. 

이름을 정할 때 공란이 있을 경우, 반드시 쌍따옴표로 묶도록 한다. 

이 단계에서는 전편의 FTP 서버에 미리 설정해놓은 SD 설정파일의 Storage 섹션 내용이 필요하다.  비교해보자.  같은 항목끼리는 같은 색으로 표시했다.

FTP - SD (bacula-sd.conf) DB Server - DIR (bacula-dir.conf)

Storage {
  Name = ftp-sd
  SDPort = 9103
  WorkingDirectory = "/var/lib/bacula"
  Pid Directory = "/var/run/bacula"
  Maximum Concurrent Jobs = 20
  SDAddress = 10.211.55.34
}

Director {
Name = dbserver-dir
Password = "ZZzIzaBzvGSK5DU74h-RoEy9QXvAVXyyW"
}


Device {

  Name = FileStorage-1
  Media Type = File
  Archive Device = /mnt/backup-1/bacula
  LabelMedia = yes;
  Random Access = Yes;
  AutomaticMount = yes;
  RemovableMedia = no;
  AlwaysOpen = no;
}

 

Device {
  Name = FileStorage-2
  Media Type = File
  Archive Device = /mnt/backup-2/bacula
  LabelMedia = yes;
  Random Access = Yes;
  AutomaticMount = yes;
  RemovableMedia = no;
  AlwaysOpen = no;
}

Storage {
  Name = "Server Backup"
  SDAddress = 10.211.55.34

  SDPort = 9103
  Password = "ZZzIzaBzvGSK5DU74h-RoEy9QXvAVXyyW"
  Device = FileStorage-1
  Media Type = File

Storage {
  Name = "User Data Backup"
  Address = 10.211.55.34
  SDPort = 9103
  Password = "ZZzIzaBzvGSK5DU74h-RoEy9QXvAVXyyW"
  Device = FileStorage-2
  Media Type = File
}

 

 

 

 

 

 

 

 

 



 

매치되어야하는 항목들 (순서 관계 없음)
1. SD IP 주소 및 포트번호 = DIR에 정의된 SD의 IP 주소 및 포트번호
2. SD 디렉터 패스워드 = DIR 스토리지 패스워드 (위의 표에서는 나오지 않았지만, SD 디렉터의 이름은 DIR 디렉터의 이름과 반드시 맞아야한다.) 
3. SD 디바이스 이름 = DIR 스토리지 디바이스 이름
4. SD 미디어 타입 = DIR 미디어 타입

이것까지만 하고 스토리지 데몬의 동작을 확인해봤으면 좋겠지만, 스토리지 항목과 연계된 다른 항목들에서 에러가 발생하기 때문에 어쩔 수 없이 다른 항목들의 설정을 모두 마쳐야한다.

 

6. Pool {}
Pool은 다소 이해하기가 어려울 수 있다.  전편에서 설명했지만, Bacula는 백업되는 파일들을 Tarball처럼 하나의 파일로 묶고 이것을 마치 테이프 장치에 백업하는 것처럼 다룬다고 했다.  다시 상기시켜드리자면, 백업되는 파일의 목록들을 데이터베이스에 저장하고, 실제 파일들은 내용을 볼 수 없도록 보안상 하나의 파일로 합쳐서 보관을 하게 된다.  이 합쳐진 파일을 Volume이라고 부르는데, 동일한 목적을 갖고 생성된 Volume들을 하나로 묶어서 Pool이라고 부른다.  이것이 다소 불편할 수도 있긴 하겠지만 편한 경우가 더 많다는 것을 설명드리고 싶다.  또한, DB가 망가진 상황을 대비하여 수동으로 복구할 수 있는 툴도 제공되고 있으니 너무 걱정하지 않아도 된다.  

쉽게 생각하면, 테이프 장치 생각하시면 된다.  각각의 볼륨이 각각의 테이프라고 생각하시면 되겠다.  볼륨 개념은 Bacula가 백업수행을 테이프 장치에 한다는 것을 기본 작동모델로 삼았다고 이전 편에서 설명드렸다.

예를  들어서, 1TB짜리 하드디스크가 하나 있고 여기에 내가 가진 모든 것을 백업하려고 한다고 가정하자.  사진이 대략 30기가, 음악이 대략 20기가, 각종 프로그램들 모아놓은게 100기가, 동영상 500기가, 그리고 앱스토어에서 다운받아놓은 앱들이 30기가 있다고 치자.  그러면 각각의 목적에 맞는 Pool들을 생성해서 관리하는 것을 생각해볼 수 있는데, 혹시 모르니까 하나의 Pool은 최대 용량을 10GB짜리 볼륨으로 관리한다고 치자.  그렇다면,

1. 아이폰/안드로이드 앱용 Pool 10GB x 8 vols = 80GB (앱이 아무리 많더라도 80기가 이상의 공간은 쓰고싶지 않다는 의미)
2.  사진용 Pool 10GB x 8 vols = 80GB
3.  프로그램용 Pool 10GB x 20 vols = 200GB
4.  동영상용 Pool 10GB x 50 vols = 500 GB
5.  음악용 Pool 10GB x 4 vols = 40GB

이렇게 해서 대략 900GB 정도의 백업공간을 맞춰놓았다.  그런데 생각해보니, 음악은 어차피 아이튠즈에서 구입한거니까 날아가더라도 다시 다운받으면 되고 모바일용 앱도 마찬가지고해서, 여기에다 용량을 주는게 좀 아깝다고 치자.  그래서 백업주기를 30일로 맞춰놓고 공간을 적당하게 주면, Bacula가 30일짜리 싸이클을 한 번 돌면서, 30일 이전의 자료는 알아서 자동으로 삭제를 해주므로 원하지 않는 자료들이 불필요한 공간을 차지하는 것을 방지하는 좋은 방법이 될 수 있는 것이다.  참고로, 본인이 근무하는 곳에서는 서버 백업용으로 총 10개의 볼륨에 볼륨 하나당 용량을 50기가 정도로 맞춰놨다.  이제 내용을 살펴보자.  위의 설명을 이해했 으면 이제 이 설정은 눈에 쉽게 들어오실 거다.   설명을 해보면,

Pool {
  Name = "For ServerFiles" Pool 이름을 For ServerFiles이라는 지정한다.
  Pool Type = Backup # 용도는 백업이다.  백업 외에 Archive, Cloned, Migration, Copy, Save 등의 특수한 타입이 있다.
  Recycle = yes # 위에서 설명한 대로, 지정한 주기가 끝나면 다시 처음부터 되돌아가는 "재활용 주기"를 지정한다.  테이프로 생각하면, 다시 처음으로 감는다고 생각하면 된다.
  AutoPrune = yes # 볼륨 내에서 주기가 지난 파일들을 자동으로 삭제해주는 옵션이다.
  Volume Retention = 365 days # 볼륨 자체의 주기를 지정한다.  이 예제에서는 365일이 지정되어있다.  이것은, 최근 1년간 사용되지 않는 볼륨이 있을시 볼륨을 비워버린다.
  Maximum Volume Bytes = 50G # 이 Pool에서 사용할 볼륨들의 최대 크기를 지정한다.  여기서는 50GB로 지정되어있다.
  Maximum Volumes = 100 # 이 Pool에서는 볼륨의 최대 갯수를 100개로 제한한다.  따라서, 이 Pool의 최대 사이즈는 50G x 100 = 5TB 정도 되겠다. 
  Storage = "Server Backup" # 이 Pool은 용도가 서버백업용이므로 저장장치로는 SD의 첫번째 백업장치로 마운트 되어있는 /mnt/backup-1/bacula를 사용한다 (위의 표 참고).
}

 

7. Schedule {}
스케쥴은 별로 설명할 게 없다.  Bacula의 설정이 워낙 직관적이기 때문에 딱 보면 누구나 알 수 있기 때문이다.   일단, 기본값으로 설정되어진 스케쥴 중 하나를 설명드린다.

Schedule {
  Name = "WeeklyCycle" # 이름을 지정한다.  지금껏 따라오신 분들은 눈치채셨겠지만, Bacula에서 이름은 아주 중요하다.  밑에서 설명할 Job/JobDefs에서 쓰이게 된다.
  Run = Full 1st sun at 23:05 # 매월 첫째주 일요일 밤 11시 5분에는 "전체 백업"을 실시한다.
  Run = Differential 2nd-5th sun at 23:05 # 매월 둘째주부터 5째주까지 일요일 밤 11시 5분에는 변경분에 대한 백업을 실시한다.
  Run = Incremental mon-sat at 23:05 # 매주 월요일부터 토요일 밤 11시 5분에는 증분 백업을 실시한다.
}

위의 예제처럼 꼭 전체/변경/증분을 모두 넣어야하는 건 아니다.  여러가지 스케쥴 세트를 만들고, 각 서버별로 백업을 하면 된다.  예를 들어, DB서버는 매일 밤 10시마다 무조건 전체백업을 실시하고, 데스크탑 종류는 월 1회만 전체백업, 그외는 증분백업만 실시하고, 개발서버는 무조건 증분백업만 실시하게끔 해서 목적별로 다양한 스케줄 세트를 지정해서 사용할 수 있다.

참고하시라는 차원에서 설정 몇 줄을 더 보여드린다.
Run = Full 1st,3rd sat at 02:00
Run = Full Hourly at 0:05 # 매시 5분
Run = Incremental on 1 at 2:05
 # 매월 1일

 

8. FileSet {}
이 섹션은, "어떤 파일들이 백업되어야하는가"를 직접 지정하는 부분이다.  기본값으로 나온게 카탈로그 백업 밖에 없으므로, 글쓴이가 관리하는 서버의 FileSet 예제 하나를 보여드린다.  이름은 Standard Backup FileSet이라고 해놨는데, 이 FileSet의 목적은 특별히 백업되어야할 게 없는 평범한 서버를 지정하기 위해서다.

FileSet {

  Name = "Standard Backup FileSet" # 이름을 지정한다.  역시, 밑에서 설명할 Job/JobDefs에서 쓰인다.

  Include { # 백업 작업시 포함되어야할 내용을 기술한다.

    Options {

      signature = MD5 # 파일검증을 MD5로 한다.  다른 옵션으로는 SHA1을 쓸 수 있다.

      compression = GZIP # 파일을 압축한다.  다른 옵션으로는 LZO가 있다.  만약, 테이프 장치를 사용할 예정이라면, 사용 중인 테이프 장치가 자체 압축을 지원한다면 이 옵션은 끄는게 좋다.

    }

    File = /home # 백업되어야할 목록을 기록한다.

    File = /etc
    File = /var 

  }
  Exclude {
 # 백업시 제외되어야할 목록을 기록한다.
    File = /var/run
  } 

}

 

클라이언트가 윈도우 서버일 경우, Microsoft 제품의 운영체제가 경로에 사용하는 백슬래시 (\)를 슬래시 (/)로 바꿔주거나 혹은 백슬래시를 두 개 붙여주면 된다..
예)
File = "C:/Program Files/Microsoft SQL Server"
File = "C:\\Program Files\\Microsoft SQL Server" 

FileSet의 설명은 이게 전부다.  역시 느끼는 거지만, 정말로 쉽다.  사실 이거 말고도 엄청나게 많은 옵션이 있는데, 몇 가지 유용해보이는 것만 소개해드리고 더 궁금하신 분은 아래의 링크를 참고하시면 되겠다.
http://www.bacula.org/5.2.x-manuals/en/main/main/Configuring_Director.html

hfsplussupport=yes # MacOSX의 HFS+ 파인더 정보를 지원한다.
aclsupport=yes # POSIX ACL을 지원한다.
wildfile = "*.gz"  # 와일드카드를 사용한다.  확장자가 gz인 파일들을 포함하거나 제외시킨다.
wildDir = "[A-Z]:/Documents and Settings/*/Application"
RegexDir = "^/home/[c-z]" # 정규식을 사용하여 파일 및 디렉토리들을 포함/제외 한다.
Exclude = yes # 이 옵션이 Include 섹션에 사용됐을 경우, wildfile / wildDir, RegexDir에 정의된 파일은 제외시킨다.
xattrsupport=yes
 # xattr을 지원한다.  다만, 이 옵션의 스트림 포맷은 OS간에 서로 호환이 되지않으므로 다른 OS간에는 지원되지 않는다.
xattr 지원되는 OS: AIX, Darwin, FreeBSD, IRIX, Linux, NetBSD, Solaris, Tru64 

다른 예제를 몇 개 더 보자.  /home을 백업하는데, *.c는 제외하도록 한다.  FIleset { 부분과 Name은 건너뛰고 Include만 보여드린다.
Include {
    Options {
        wildfile = "*.c"
        Exclude = yes
    }
    File = /home
}

이번에는, 확장자가 Z인 파일들과 gz인 파일들만 백업해보자.

Include {
    Options {
        wildfile = "*.Z"
        wildfile = "*.gz"

    }
    Options {
        Exclude = yes
        RegexFile = ".*"
    }

    File = /home
}

참고로 Include {} 항목 내에서의 Exclude = yes가 아닌, Exclude {} 항목의 경우는 정규식이나 와일드 카드 등으 표현식은 지원되지 않는다.

 

 

9. JobDefs {} / Job {}

실제로 작업을 실행하는 부분이다.  물론 위의 항목들이 하나라도 준비가 안되면 백업이 진행되지 않긴 하지만, 나중에 설명할 GUI 프로그램인 Bacula Admin Tool을 써보면 그때 알게된다.  여기가 바로 백업을 실행하는 부분이다.  일단 예제를 먼저 보자.  JobDefs부터 시작한다.  아래의 예제는 글쓴이가 관리하는 LDAP 서버들의 백업을 위한 설정이다.

JobDefs {

  Name = "LDAP JobDefs"

  Schedule = "Standard"

  Type = Backup

  Messages = Standard

  Pool = Volume_File

  FileSet = "LDAP Backup FileSet"

  ClientRunBeforeJob = "/usr/local/sbin/ldapbackup.sh"

}

JobDefs는 공통적인 작업에 대한 부분을 정의해놓는 섹션인데, 따라서 JobDefs는 있어도 되고 없어도 된다.  다만, 수많은 서버들이 공통적이거나 중복되는 설정이 많다면 그것을 모아서 하나로 정의할 수 있는 편의를 제공해준다는 점 정도로 보면 되겠다.

 

10. Client {}

백업이 되어야할 클라이언트에 대한 주소와 이름 등을 지정해주는 부분이다.  특별한 건 없다.

Client {
  Name = "Desktop"
  Address = "192.168.0.100"
  Catalog = "MySQL"
  FdPort = 9102
  MaximumConcurrentJobs = 1 // 동시에 백업될 수 있는 최대 접속수를 지정한다.
  Password = "desktop-bacula" // 패스워드의 형식은 따로 없다.
} 

 

모든 설정이 끝났다.  일단은 테스트를 위해 최소한으로만 설정해보자.  쉬운 테스팅을 위해서 글쓴이는 비밀번호를 전부 쉽게 바꿔버렸다.  bacula-dir.conf 전체내용을 보자.

Director {
  Name = dbserver-dir
  DIRport = 9101
  QueryFile = "/etc/bacula/scripts/query.sql"
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/var/run/bacula"
  Maximum Concurrent Jobs = 1
  Password = "dir"
  Messages = Daemon
  DirAddress = 10.211.55.33
}

JobDefs {
  Name = "DefaultJob"
  Type = Backup
  FileSet = "Full Set"
  Storage = "Server Backup"
  Messages = Standard
  Priority = 10
  Write Bootstrap = "/var/lib/bacula/%c.bsr"
  Schedule = "WeeklyCycle"
}

Job {
  Name = "DBServer Backup"
  JobDefs = "DefaultJob"
  Pool = Server
  Client = "DBServer"

}

Job {
  Name = "FTP Backup"
  JobDefs = "DefaultJob"
  Client = "FTP Server"
  Pool = "User Data"

}

Job {
  Name = "WEB Backup"
  JobDefs = "DefaultJob"
  Pool = Server

  Client = "Web Server"
}

Job {
  Name = "Desktop Backup"
  JobDefs = "DefaultJob"
  Client = "Desktop"
  Pool = Server

}

Job {
  Name = "BackupCatalog"
  Client = "DBServer"
  Type = Backup
  Level = Full
  Messages = Standard
  FileSet = "Catalog"
  Pool = Server
  Schedule = "WeeklyCycleAfterBackup"
  RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup.pl MyCatalog"
  RunAfterJob = "/etc/bacula/scripts/delete_catalog_backup"
  Write Bootstrap = "/var/lib/bacula/%n.bsr"
  Priority = 11
}


FileSet {
  Name = "Full Set"
  Include {
    Options {
      signature = MD5
    }
    File = /
  }
  Exclude {
    File = /var/lib/bacula
    File = /sys
         File = /run
    File = /proc
    File = /tmp
    File = /.journal
    File = /.fsck
  }
}

Schedule {
  Name = "WeeklyCycle"
  Run = Full 1st sun at 23:05
  Run = Differential 2nd-5th sun at 23:05
  Run = Incremental mon-sat at 23:05
}

Schedule {
  Name = "WeeklyCycleAfterBackup"
  Run = Full sun-sat at 23:10
}

FileSet {
  Name = "Catalog"
  Include {
    Options {
      signature = MD5
    }
  File = "/var/lib/bacula/bacula.sql"
  }
}

Client {
  Name = "DBServer"
  Address = 10.211.55.33
  FDPort = 9102
  Catalog = MyCatalog
  Password = "dbserver"
  File Retention = 30 days
  Job Retention = 6 months
  AutoPrune = yes
}

Client {
  Name = "FTP Server"
  Address = 10.211.55.34
  FDPort = 9102
  Catalog = MyCatalog
  Password = "ftpserver"
  File Retention = 30 days
  Job Retention = 6 months
  AutoPrune = yes
}

Client {
  Name = "Web Server"
  Address = 10.211.55.35
  FDPort = 9102
  Catalog = MyCatalog
  Password = "webserver"
  File Retention = 30 days
  Job Retention = 6 months
  AutoPrune = yes
}

Client {
  Name = "Desktop"
  Address = 10.211.55.32
  FDPort = 9102
  Catalog = MyCatalog
  Password = "desktop"
  File Retention = 30 days
  Job Retention = 6 months
  AutoPrune = yes
}


Storage {
  Name = "Server Backup"
  Address = 10.211.55.34
  SDPort = 9103
  Password = "storage"
  Device = FileStorage-1
  Media Type = File
}

Storage {
  Name = "User Data Backup"
  Address = 10.211.55.34
  SDPort = 9103
  Password = "storage"
  Device = FileStorage-2
  Media Type = File
}


Catalog {
  Name = MyCatalog
  dbname = "bacula"; DB Address = "127.0.0.1"; dbuser = "bacula"; dbpassword = "bacula"
}

Messages {
  Name = Standard
  mail = root@localhost = all, !skipped
  operator = root@localhost = mount
  console = all, !skipped, !saved
  append = "/var/lib/bacula/log" = all, !skipped
  catalog = all
}


Messages {
  Name = Daemon
  # mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula daemon message\" %r"
  mail = root@localhost = all, !skipped
  console = all, !skipped, !saved
  append = "/var/lib/bacula/log" = all, !skipped
}

Pool {
  Name = Server
  Pool Type = Backup
  Storage = "Server Backup"
  Recycle = yes
  AutoPrune = yes
  Maximum Volume Bytes = 50G

  Volume Retention = 365 days
}

Pool {
  Name = "User Data"
  Pool Type = Backup
  Storage = "User Data Backup"

  Recycle = yes
  AutoPrune = yes
  Volume Retention = 365 days
  Maximum Volume Bytes = 50G
  Maximum Volumes = 100
}


Console {
  Name = dbserver-mon
  Password = "eIHC8_gqenYpPFXbCc6-r0lFHx9B5azJ9"
  CommandACL = status, .status
}

 

내용이 길어서 상당히 복잡해보이지만 하나만 기억하자.  "모든 설정은 Name이 매치된다".  추후에 설정을 나누는 법에 대해서 다루겠다.

간단하게 설명을 하자면,
1. JobDefs에서 DefaultJob이라는 기본 백업룰을 하나 만들고 공통적인 사항은 모두 넣었다.  
2. 각 클라이언트별로 Job을 생성해주되 BackupCatalog라는 별도의 카탈로그 백업 Job을 생성해줬다.  이 백업은 DefaultJob과는 내용이 완전히 다르기 때문에 JobDefs가 필요하지 않다.
3. 백업되어야할 파일들(FileSet)은 일단 Full Set과 Catalog, 이렇게 두개만 만들었다.  당연한 얘기지만 여러개의 파일셋을 만들고 상황별로 백업이 가능하다.
4. 스토리지는 이전 편의 예제에 설명했듯이, 두 개의 스토리지를 만들어서 하나는 서버백업용, 나머지 하나는 유저 데이터 백업용으로 한다고 했다.
5. Messages란의 mailcommand는 주석처리 했다.  일단 테스팅용이므로 메일은 생략한다.

이제 DIR을 재시작해서 에러가 있는지 확인하자.  위의 설정을 그대로 쓴다면 에러없이 재시작이 가능할거다.  netstat으로 작동 중인지 확인해보자. 

 

다음 편에서는 실제로 백업을 실습해본다.  현재로서는 이해가 되지않는 항목이 있더라도 그냥 넘어가도록 하자.

블로그 이미지

Seowon Jung jswlinux

Seowon Jung의 잡동사니 보관소

댓글을 달아 주세요

  • weblegend 2015.01.02 23:19  댓글주소  수정/삭제  댓글쓰기

    yubikey 서버측 인증 어플리케이션이나 알고리즘은 직접 만들어줘야 하나요? 서버 어플리케이션도 포함되어 있나요?
    프로그램을 해 넣을 수 있다는게 매력포인트네요.ㅋ.
    회사에서 사용한다면 usb잊어버리거나 부서지면 어떻하나요?

    • Seowon Jung jswlinux 2015.01.05 12:42 신고  댓글주소  수정/삭제

      안녕하세요. 코멘트를 다른 글에 달아주셨네요.

      일단, yubikey의 인증서버는 yubikey 회사에서 기본으로 제공하는 서버를 쓸 수 있고, 사내에 내부 인증서버를 둘 수도 있습니다. 이 인증서버는 yubikey를 제작한 회사인 yubico에서 vmware 이미지가 올라와있으므로, 이것을 그대로 사용하실 수 있습니다.

      USB로 되어있는 키를 잃어버리시면 방법이 없겠죠. 집 대문키 잃어버리면 자물쇠 뜯어내지 않으면 못들어가는 것처럼 이것도 마찬가지입니다. 다만, 리눅스의 경우 로그인시 pam.d 설정을 통해서 패드워드와 키 둘 다 쓸 수 있게끔 해놓으면 대비가 되겠네요.

      도움이 되셨길 바랍니다.

  • weblegend 2015.01.02 23:43  댓글주소  수정/삭제  댓글쓰기

    페이지에 나와있는 방식을 보니까 U2F가 챌린지 응답 방식으로 되어있네요
    salt 같은 임의의 난수들을 서버에서 받는 과정등이 중간자 공격 등으로 보안이 취약해 지지 않을까요?
    물론 yubikey 디바이스의 OTP 알고리즘을 커스터마이징하면 보안에 강할 수 있겠지만, 암호 생성방식이 파악당한다면 뚫리지 않을까요?
    다른 OTP인증 방식도 예외가 아니겠지만요.

    • Seowon Jung jswlinux 2015.01.05 12:47 신고  댓글주소  수정/삭제

      안녕하세요. 코멘트를 다른 글에 달아주셨네요.

      일단 암호생성방식이 파악되면 뚫리지않을 암호는 세상 어디에도 없겠죠? 그래서, yubikey 홈페이지에서 문서를 보시거나, 펌웨어 업데이트용 프로그램을 받아서 보시면 아주 다양한 방법으로 암호화를 할 수 있게 제공해줍니다. 너무나도 옵션이 다양해서 키 없이 암호를 알아내긴 어렵지 않나 싶습니다.

      아무래도 궁금하신 부분은, yubikey 펌웨어 업데이트용 프로그램을 써보셔야 이해가 가실 것 같네요. 가격이 얼마 안하니까 하나 구입해서 써보시는 걸 추천해드립니다.

      도움이 되셨길 바래요.

  • 2015.06.30 16:54  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • Seowon Jung jswlinux 2015.07.01 08:41 신고  댓글주소  수정/삭제

      안녕하세요 namoo님

      백업서버가 여러 곳에 나뉘어져있거나 여러 장치가 한 서버에 연결되어있더라도, Bacula의 스토리지 데몬이 설정된대로 잘 제어해주기 때문에 충돌은 나지 않습니다. 그냥 디렉토리 지정해준다고 생각하시면 되겠습니다.

      기본적으로 Bacula는 오픈소스 소프트웨어이므로 사용 자체는 무료입니다. 별도의 특별한 플러그인이 필요하시면 그때 상용지원버전을 구입하셔도 됩니다. 상용버전 안내 홈페이지는 여기를 참고하세요: http://www.baculasystems.com/

      좋은 하루 되세요.