이번 편에서는 설정의 최종판, 끝판왕 되시는 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 { Device { Device { |
Storage { Name = “Server Backup” SDAddress = 10.211.55.34 SDPort = 9103 Password = “ZZzIzaBzvGSK5DU74h-RoEy9QXvAVXyyW” Device = FileStorage-1 Media Type = File } Storage { |
매치되어야하는 항목들 (순서 관계 없음)
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
으로 작동 중인지 확인해보자.
다음 편에서는 실제로 백업을 실습해본다. 현재로서는 이해가 되지않는 항목이 있더라도 그냥 넘어가도록 하자.
http://jswlinux.tistory.com/159 << 여기로 댓글남겼는데 블로그 이전하셨다하셔서 여기에도 남깁니다!
ㅠㅠ도움부탁드려요!!
안녕하세요!
bacula를 도입하던중 난관에 부딪혀 질문 댓글 남깁니다.
제 bacula가 병렬/동시백업(concurrent backup)시 잘 작동하지 않는것같은데요.
예를들면 job1과 job2가 있고, 이 둘은 각각 fullbackup하는데 4분, 5분 소요됩니다.
bconsole에서 status dir을 쳐보면 두 job이 동시에 running되는것이 확인되는데요.
동시에 backup이되다보니 두 job의 종료시점이 다르더라도, 최대 7~8분정도 소요될것으로 예상했습니다.
그런데 동시에 작업을 시작한 후 job1이 4분후에 먼저 끝나고, job2는 job1이 끝나고나서 5분후에 종료됩니다.
보이기만 running이 동시에되고 시간은 총 9분이걸리니 따로돌리는것과 같네요. (두 job의 우선순위 Priority는 같습니다.)
아래는 제가 동시백업을 위해 변경한 conf내용입니다.
## bacula-dir.conf
Director section's option Maximum Concurrent Jobs = 20
Client section's option Maximum Concurrent Jobs = 20
Storage section's option Maximum Concurrent Jobs = 20
## bacula-sd.conf
Storage section's option Maximum Concurrent Jobs = 20
Device secsion's option Maximum Concurrent Jobs = 20
## bacula-fd.conf
FileDaemon section's option Maximum Concurrent Jobs = 20
빛과같은 조언 부탁드립니다ㅠㅠ
안녕하세요.
답장 드렸습니다.
제가 달았던 답변이 사라졌습니다
테스트해보고 1주일후에 알려드리기로 했는데, 뭘 알려드리기로 했는지 정확히 기억나질 않습니다.
생각나시면 말씀해주세요.
10여일갈 운영해본 결과 알려드립니다.
설정 내용은 아래와 같습니다.
Client {
Name = 111.111.111.111
Address = 111.111.111.111
FDPort = 9102
Catalog = MyCatalog
Password = “1234567890”
File Retention = 7 days
Job Retention = 7 days
AutoPrune = yes
}
Pool {
Name = 111.111.111.111-pool
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 7 days
File Retention = 7 days
Job Retention = 7 days
LabelFormat = “111.111.111.111.public-”
UseVolumeOnce = yes
# Maximum Volume Bytes = 100G
Maximum Volumes = 15
}
– 백업본 저장기간은 7일로 맞게 되었습니다.
– UseVolumeOnce = yes 이거 사용하지 마라 하셔서 주석처리했더니, 기존 볼륨에 파일을 백업하더군요. 저의 경우에는 Maximum Volume Bytes 설정이 없어서 볼륨을 건너뛰지 않고, 한번만 사용하게 하였습니다. 전 이게 보기 좋아서..^^
알려주신 덕분에 운영을 잘 하고 있습니다. 전에 알려드리기로 했던거 빼먹었으면 알려주세요.. 다시 확인해보겠습니다.
안녕하세요.
현재 블로그가 운영되고 있는 서버의 디비가 SQL Injection 공격을 받아서 최근 2주 간의 데이터가 전부 날아갔습니다. 원래 매일 백업이 되고있었는데, 아무래도 공격자가 일부러 백업이 되지않게끔 테이블을 건드려놓고 기다린듯 싶네요. 제 서버가 아니고 저도 무료로 얻어쓰고있는 입장이라 어쩔 수가 없네요.
암튼 다시 알려주셔서 감사합니다.
댓글이 안달립니다~ 테스트
제가 달았던 답변이 사라졌습니다
테스트해보고 1주일후에 알려드리기로 했는데, 뭘 알려드리기로 했는지 정확히 기억나질 않습니다.
생각나시면 말씀해주세요.
10여일갈 운영해본 결과 알려드립니다.
설정 내용은 아래와 같습니다.
Client {
Name = 111.111.111.111
Address = 111.111.111.111
FDPort = 9102
Catalog = MyCatalog
Password = “1234567890”
File Retention = 7 days
Job Retention = 7 days
AutoPrune = yes
}
Pool {
Name = 111.111.111.111-pool
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 7 days
File Retention = 7 days
Job Retention = 7 days
LabelFormat = “111.111.111.111.public-”
UseVolumeOnce = yes
# Maximum Volume Bytes = 100G
Maximum Volumes = 15
}
– 백업본 저장기간은 7일로 맞게 되었습니다.
– UseVolumeOnce = yes 이거 사용하지 마라 하셔서 주석처리했더니, 기존 볼륨에 파일을 백업하더군요. 저의 경우에는 Maximum Volume Bytes 설정이 없어서 볼륨을 건너뛰지 않고, 한번만 사용하게 하였습니다. 전 이게 보기 좋아서..^^
알려주신 덕분에 운영을 잘 하고 있습니다. 전에 알려드리기로 했던거 빼먹었으면 알려주세요.. 다시 확인해보겠습니다.
디비가 날아가다니.. 안타까운 일이 있었군요 ㅠㅠ
지난번에 기억이 안나서 말씀을 못드렸는데, 드디어 생각이 났습니다.
동시 백업 설정을 했던게 있는데, 동작이 안됐습니다.
설정은.
Director {
Name = backup-dir
DIRport = 9101
QueryFile = “/opt/webapps/bacula-9.0.6/etc/query.sql”
WorkingDirectory = “/opt/webapps/bacula-9.0.6/bacula/bin/working”
PidDirectory = “/var/run”
Maximum Concurrent Jobs = 20
Password = “11111111111”
Messages = Daemon
}
Autochanger {
Name = File1
Address = backup
SDPort = 9103
Password = “11111111111”
Device = FileChgr1
Media Type = File1
Maximum Concurrent Jobs = 10
Autochanger = File1
}
아래와 같은 메시지만 계속 나오지, 실제 백업수행은 안되더라구요.
12-Dec 22:24 backup-sd JobId 206: JobId=206, Job 111.111.111.111-job.2017-12-12_22.10.00_37 waiting to reserve a device.
같은 시간대에 다른 클라이언트도 위와 같은 메시지가 나왔습니다.
동시 진행을 하려고 하는데, 뭔가가 수행이 안되어 안되는 것 같고.. 잘 모르겠네요.
계속 알아보고 있는데, 조언이 될만한게 있으면 부탁드립니다.
감사합니다.
올려주신 설정만으로는 파악하기가 어렵습니다. 그 이유는, 스토리지 설정은 sd와 dir 둘 다 있어야하거든요. 일단 Autochanger 항목이 있는 것을 봐서는 SD의 설정파일을 올려주신 듯 한데요, 백업 장치를 지정하려면 Autochanger {}, 그리고 Device {} 이렇게 두개의 설정이 있어야합니다. 제가 관리하는 하드디스크 백업장치의 설정을 드리자면,
Storage { 생략하겠습니다 }
Director {
name = xxx-dir
이하 생략하겠습니다
}
Director {
Name = storage-mon
이하 생략하겠습니다
}
Autochanger {
Name = “FileChanger”
Device = ZFS-1
Changer Command = “”
Changer Device = /dev/null
}
Device {
Name = ZFS-1
Media Type = File
Archive Device = /srv/backup
Label Media = yes
Random Access = yes
Automatic Mount = yes
Removable Media = no
Always Open = no
Maximum Concurrent Jobs = 10
}
로 구성되어있으며, DIR 서버에서의 스토리지 설정은 다음과 같습니다.
Storage {
Name = FileStorage_1
Address = ***
SDPort = 9103
Password = “”
Device = “ZFS-1”
Media Type = File
Heartbeat Interval = 300
Maximum Concurrent Jobs = 10
TLS Enable = yes
TLS Require = yes
TLS CA Certificate File = “/opt/bacula/etc/certs/CA_Bacula.crt”
TLS Certificate = “/opt/bacula/etc/certs/modgud.crt”
TLS Key = “/opt/bacula/etc/certs/modgud.key”
}
아래는 위의 스토리지를 사용하는 Job을 위한 Pool 설정입니다.
Pool {
Name = “InstancesBackup”
AutoPrune = yes
PoolType = “Backup”
Recycle = yes
Storage = “FileStorage_1”
VolumeRetention = 1 months
File Retention = 1 months
Job Retention = 1 months
Maximum Volumes = 100
Maximum Volume Bytes = 50G
Label Format = InstancesBackup-
}
설정들을 천천히 살펴보셔야하는 게, DIR-SD-FD가 서로 다 동일한 항목을 가리키고 있어야하는 겁니다.
1. SD에서 Autochanger의 Device는 Device{}의 Name을 가리키고 있어야하며,
2. DIR에서 스토리지 설정의 Device는 SD의 Device{} Name을 가리켜야하며,
3. DIR에서 Pool 설정의 Storage는 DIR의 Storage{}에서 Name과 일치해야합니다.
다시 한 번 천천히 보시고 시도해보세요.