간헐적 단식이라는 것을 시작한지도 이제 3개월이 지나고 4개월 째에 접어든다.  이 글을 처음 읽으시는 분이라면  1개월 실행경과에 대해 적은 글을 먼저 보고 오시라.


http://jswlinux.tistory.com/entry/%EA%B0%84%ED%97%90%EC%A0%81-%EB%8B%A8%EC%8B%9D-1%EB%8B%AC-%EC%8B%A4%ED%96%89-%EA%B7%B8-%EA%B2%B0%EA%B3%BC


1개월 실행한 이후의 글쓴이의 체중은 72키로에서 줄지않고 있다고 적었고, 지금도 여전히 72에서 73키로를 왔다갔다 한다.  다만, 개인적인 사정으로 1일 1식을 1개월 정도 실행한 이후부터 지금까지 수많은 일이 있었는데, 그것에 대한 기록을 남기고자 한다.  혹은 누군가에게 도움이 될 수도 있을테고.


내 블로그 제어판에서 유입 통계나 키워드를 보면 간헐적 단식이나 단식에 대한 통계가 꽤 많았다.  그 유입경로를 따라가보면 대부분 네이버 검색화면이 뜨는데, 같이 뜨는 글들을 보면 간헐적 단식에 대해서 제대로 알고 하자! 내지는, 단식 3일, 10일 등등의 글들이 대부분이었다.  참고로, 글쓴이는 제대로 알고 시작하지도 않았고, 위의 1개월 실행경과를 보면 알겠지만 영양의 균형도 맞추지 않고 그냥 하고싶은대로 했다.


간헐적 단식이라고하기에는 좀 뭐시기한게, 글쓴이 입장에서는 간헐적 단식이 아닌 간헐적 취식 내지는 폭식이 되어버렸기 때문에 이제 이 간헐적 단식이라는 단어는 글쓴이에게 맞지않는 상황이 되어버렸다.  1일 1식을 하니까 간헐적 단식은 확실히 맞지않지.  어찌됐든...


1개월차 막바지쯤에 시작했었던 운동을 적어본다.

1.  유산소 운동은 전혀 하지 않았다.

2.  아령의 무게는 20 파운드 (약 9 kg)

3.  운동은 2일에 한 번씩만 했고, 절대로 더 이상 하거나 덜 하지 않았다.  "부위별로 골고루"도 아닌, 하고싶은 것만 했다.

4.  집에서만 했으며, 잠자기 전인 밤 11시나 12시에 했다.

5.  아래는 실행했었던 운동의 순서와 내용이다.  총 6개의 동작,

허벅지 운동 20개씩 3세트 => 대자로 누워서 아령을 양손에 쥐고 팔을 편채로 그걸 정면으로 들어올리는 운동 10개씩 3 세트 => 윗몸일으키기 20개씩 3세트 => 선채로 아령 들고 하늘을 향해 쭉 뻗기 10개씩 3세트 => PT체조 8번 20회씩 3세트 => 아령 들어올리기 10개씩 3세트


만 하고 끝냈다.  총 소요시간은 대략 40분 정도이며, 운동을 마치고는 물 이외에는 입에 대지않고 샤워하고 바로 잠을 잤다.  조금 무리해서 하다가 혈당이 떨어져서 머리가 핑핑 돌아도 당분 섭취는 절대 하지 않았다.


살이 적당히 빠지고나니까 조금만 해도 확실히 팔 근육은 달라지긴 하더라.  문제는 근력운동을 하면 근육이 붙고 무게가 점점 늘어나야하는게 상식인데, 아령의 무게는 전혀 늘리지못한채 가끔 컨디션 좋은 날에는 세트당 10개씩 하던걸 12개씩 하는 정도 밖에 안됐다.


아는 동생 말로는, 근육을 키우려면 단백질 섭취는 필수로 해야한단다.  운동에서 가장 중요한 3가지가 첫째는 쉬는 것, 둘째는 먹는 것, 마지막이 운동이라고 하더라.  그래서 아령 무게는 늘리지도 못하고 계속 힘들기만 했던 것 같다.


아무튼 7월 중순경부터 시작한 1일 1식은 9월 초까지 계속 했다가 갑자기 1일 1식 하던 걸 3주간 중단해야할 위기가 왔다.  9월 둘째주는 미국 뉴저지로 출장을 가야했으며 거기가면 분명 다른 사람들과 저녁을 먹어야할테고, 그 다음주는 동생네 가족이 여행을 오기로 해서 역시 마찬가지로 1주일 내내 하루 2끼를 같이 먹어야하고, 동생이 돌아가기 하루 전에 스위스로 출장을 가서 또 그쪽 사람들과 어울려야했다.  그래서 3주 동안 거의 내내 하루 2끼 이상을 먹을 것이라 예상했다.


일단 미국 뉴저지 출장은 그런대로 괜찮았다.  호텔에서 별도로 식사가 제공되지 않았던 관계로, 교육을 진행하는 회사에서 점심만 제공해줬는데, 그냥 그것만 먹고 다른건 특별히 먹지않았다.  다만 운동은 1주일간 전혀 하지않았다.


뉴저지를 갔다온 뒤 한국에서 동생네 식구가 휴가를 왔고,  6일 동안 엄청 먹었다.  거의 매일 2끼씩 먹었으며 전부 기름진 음식들 위주로 먹었던 것 같다.


동생이 돌아가기 하루 전날 나는 스위스로 출장을 떠나야만 했다.  스위스에서 머물렀던 호텔에서는 아침식사가 제공됐는데, 빵과 함께 누텔라, 버터, 딸기쨈, 커피, 오렌지 쥬스가 나왔다.  빵이 생각보다 맛있는데다 식사가 포함된 것이다보니 다같이 아침을 먹으러 나왔다.  나도 안나가기 좀 그래서 그냥 눈치껏 어울렸다.  점심도 느끼한 음식으로 매일 먹었고, 저녁은 2일 정도 맥주를 마시면서 같이 어울렸다.  게다가, 초콜렛의 나라에 갔는데다 초콜렛을 워낙 좋아하다보니 안먹을 수가 없겠더라.  저녁마다 매일 초콜렛 하나씩 해치웠다.  초콜렛이 많이 쌌다.  운동은 전혀 안했다.


이로써 매우 규칙적이어서 알람이 울리기도 전에 잠에서 깨던 내 생활패턴에 3주간 큰 변화가 생겼고, 2주는 거의 매일마다 2끼씩 꼬박꼬박 먹었다.  심각한 체중증가가 예상됐었다.  스위스에서 집에 도착해서 그날 잠자고 다음날 일어나자마자 바로 했던 것은 몸무게를 재는 것이었는데, 결과는 놀라웠다.  체중이 전혀 늘지않았던 것이다.  오히려 몇백 그램 정도는 줄어있는 상태였다.


아무래도 약 한 달간 꾸준히 근력운동을 해왔던 것이 아무래도 살이 잘 찌지 않는 체질, 그러니까 기초대사량을 많이 늘린게 아닐까 하고 추측은 했지만, 어찌됐건 결과는 많이 놀라운 편이었다.  동생이 온 후부터 스위스에 가서까지는 정말 많이 먹었기 때문이다.


스위스에서 돌아온 이후 지금까지 대략 3주가 지났고, 현재의 몸상태는

1.  체중은 역시 그대로다.  아무래도 더 이상의 체중 변화는 없을 듯 싶다.

2.  셀룰라이트처럼 보이는 살들과 여전히 축 늘어져서 잘 빠지지 않는 뱃살 역시 그대로이며
3.  동생이 온 뒤로부터 스위스 출장까지 너무나도 많이 먹었던 바, 지금은 배가 고프면 먹는게 먼저 생각난다.


운동은,

1.  지금은 윗몸일으키기를 33개에서 35개씩 3세트, 그러니까 거의 100개 이상을 하며,

2.  아령은 20파운드에서 25파운드 (11.3 kg)짜리로 늘려서 시작한지 약 1주일 정도가 지났다.

3.  아무래도 하루에 한 끼만 먹다보니 단백질이 모자라서 근육이 안생기는 것 같아, 단백질 보충제를 운동 직후에 먹고있다.

4.  2일에 한 번, 40분씩하는 근력운동은 꼭 지켜오고 있다.
5.  사실, 운동을 한 3일 정도 안하면 몸이 왠지 좀 찌뿌둥한게 여기저기 쑤시는거 같다.


정도가 되겠다.  예전에 올린 포스팅을 보면 배가 고파도 아무렇지 않았는데, 지금은 먹을 것부터 먼저 생각나고 "어차피 며칠 또 1일1식하면 원래대로 돌아오는데 뭐" 라고 생각하곤 그냥 먹어버린다.......


단백질 보충제의 힘인지, 운동을 꾸준히 해줘서 그런건지는 모르겠지만, 일단 거울로 보면 확실히 신체의 변화가 생기긴 했다.  몸에 이 가기 시작한 것이다.  사진 공개한다.



사진으로는 팔과 어깨가 제대로 나오지 않았지만, 팔과 어깨만큼은 거울로 비춰지는 모습이 완전 근육맨이다.  볼 때마다 기분이 좋다.  아랫배에는 여전히 살이 많고, 이건 이전 포스팅에 썼듯, 단시간 내의 급격한 체중감량 때문인지뭔지, 살이 늘어난 것 같은게 도저히 빠질 것 같지 않다.  윗몸일으키기를 100개 이상 하는데도 여전히 그대로다.  아무래도 "40분"짜리 근력운동으로는 단기간 내에 효과를 보기 힘들지 않나 싶다.  하지만, 글쓴이는 이 정도로도 충분히 만족한다.  옷 입으면 보통 체형이기 때문이다.  사진을 좀 많이 올리고 싶은데, 혼자서 좋은 각도로 사진 찍기가 어려웠다.



이제는 간헐적 단식에 대한 포스팅은 당분간 하지 않을거다.  어차피 변화가 없으니.  본 블로그 유입경로를 보니까 간헐적 단식에 대해서 알아보다가 오시는 분이 많더라.  유입경로를 따라가서 봤더니 대부분의 블로그 글들이 "간헐적 단식 36시간 경과" 정도의 글들이더라.  36시간이면 3일인데...  글쓴이는 지금 1일 1식으로 3개월째다.


지금은 1일 1식 그 자체에는 너무 목매지 않기로 했다.  1주일에 2-3일 정도는 저녁에 음식이 급 땡기면 그냥 먹기로 결정했고, 그럴때는 또 그걸 먹어야 먹고사는 즐거움이 있지않나 생각한다.  어차피 그렇게 먹어봐야 하루나 이틀 정도 1일1식하면 다시 전부 다 빠진다 => 지금은 이렇게 생각하기로 했다.  마음이 무지 편하다.


아무래도 동생휴가부터 스위스까지 먹는 즐거움을 너무 많이 느껴서, 이제는 먹는 것에 대한 자제력이 좀 떨어져있긴 하지만, 적당한 운동을 병행해주니까 왠만큼 먹어봐야 거의 변화가 없고 그 다음날 1일 1식으로 인해 다시 체중이 원상태로 돌아온다는 즐거움이 있기에 글쓴이 나름대로는 즐기면서 하고있다.  다른 직원들은 오늘 설탕섭취는 여기서 끝낸다거나, 오늘은 밥을 조금만 먹어야한다거나 하는 둥의 말을 해도 난 아랑곳하지 않고 그냥 먹고싶은걸 막 먹는다.  기름지든 짜든 달든 먹고싶으면 그냥 먹는다.  어차피 1일1식 하니까 뭘 먹든 별로 신경이 안쓰이는 거다.  



지금은 체중을 줄인다기보다는, 건강을 유지하려는 목적으로 1일 1식을 하기로 했다.  체중도 더 이상 재지않기로 했다.  3개월이 넘도록 체중변화 없이 그대로다.  뚱뚱에서 평범으로 돌아왔고 가슴-어깨-팔에는 근육도 상당히 많이 붙었다.  게다가 잠잘 때 코고는 것도 이제 없고, 잠자면서 숨을 종종 못쉬는 현상도 없으며, 역류성 식도염도 완전히 없어졌기 때문에, 단식은 분명 건강에 도움이 된다고 믿는다.  더위를 많이 타는데도 이제는 확실히 많이 안타는 체질로 바뀌기도 했다.  또한, 근력운동을 하다보니, 근육은 같은 양의 지방보다 무거우므로 사실 아주 천천히 나도 모르게 지방이 빠지고 그 자리를 근육이 채우는 중일지도 모른다.


어디선가 본건데, 글쓴이처럼 사무실에 가만히 앉아있는 사람들이나, 집에서 뒹굴뒹굴하는 사람들의 경우는 하루 소모칼로리의 숫자가 생각보다 훨씬 적은데, 한국 성인남자의 하루소비 칼로리가 대충 남자는 2,500, 여자는 2,000 정도 된다.  하지만, 집에서 뒹굴뒹굴하게되면 남자든 여자든 하루에 소모하는 칼로리가 대략 1,500 내지는 1,200 정도 밖에 안된다.  이 정도면, 사이즈 큰 햄버거 세트 하나면 끝이다.  그러면 하루에 한끼를 먹어도 그게 정상인거다.  가만히 앉아서 일하는 직장인의 경우 역시, 남자는 그래봐야 1,800 정도에, 여자는 1,500 정도라고 한다.  그래서 기초대사량이 중요한거다.  여성분들이 근력운동하면 우락부락해질까봐 걱정하는데, 내가 알기로 적당한 근력운동은 몸의 라인을 예쁘게 만들어준다고 알고있다.


글쓴이가 의학적인 상식이 있다거나, 체육학, 생리학 등에 지식이 있는 사람은 아니지만, 1일 1식을 3개월 이상 해온 경험자로써, 꼭 중요하다고 믿는 것들을 나열해본다.


1.  하루에 한끼를 먹든 두끼를 먹든, 늘상 먹는 식사만큼은 반드시 정확한 시간을 지킨다.

=>  이거, 개인적으로 최고로 중요하다고 본다.  이전 포스팅에도 적었지만, 글쓴이는 직원들과 점심을 같이 먹어야하기 때문에 점심을 선택했고 12시에서 1시 반 사이에는 반드시 먹고있다.  우리 몸에게 이 시간에는 항상 음식물이 들어온다는걸 알려주는건 "매우매우" 중요하다고 생각한다.  이건 반드시 지켜야한다.

2.  단식을 하면 근육도 같이 빠지고, 근육이 빠지면 기초대사량이 줄기 때문에 결국 단식은 하나마나가 된다.

=> 따라서, 30분이라도 근력운동은 꼭 해줘야한다.  굳이 헬스장을 찾을 필요도 없다.  글쓴이처럼 집에서 해도 된다.  매일 하는 것은 절대 금물이고, 2일에 한 번 아니면 3일에 한 번씩만 하자.  단, 자세와 호흡은 중요하니까 처음에는 서점 등에서 헬스 책 하나 빌려놓고 보면서 하는 것을 권한다.  또한, 글쓴이처럼 극단적인 1일 1식을 하려는 분이라면 단백질 보충제를 운동 후에 꼭 섭취해야한다.  단백질이 없으면 운동을 해도 근육이 늘지 않는다.  운동을 안하더라도 단백질 보충제를 섭취하는 걸 권한다.  체중이 빠져도 단백질 공급이 원활하지 않으면 건강에 좋지않고, 근육이 빠지면 1일1식은 하나마나다.

3.  우리 몸의 메카니즘은, 늘상 일정한 음식물이 들어오다가 어느시기에 갑자기 폭풍섭취를 하게되면 비정상적인 섭취로 보고 여기서 섭취되는 칼로리는 전량 폐기시킨다고 한다.  즉, 몸에 안쌓인다는 거다.  그러니, 1주일에 하루 정도는 고칼로리 음식을 먹어도 되며, 글쓴이는 1주일에 3일 정도는 저녁에 먹고싶은걸 막 먹었다.  저녁에 식사약속이 있으면 절대 사양하지 않고 가서 열심히 먹었다.  물론 체중 변화야 다음날 일어나자마자 바로 재면 많이 늘어나있기야 하겠지만, 하루이틀 지나면 다시 원상태로 돌아온다.  사실 1일1식 한달만 하면, 먹는 양이 줄어서 폭풍섭취는 커녕 남들 먹는만큼 먹지도 못한다.



어차피 1일 1식 한다고해서 내 스스로가 스트레스 받아가면서 하는 것도 아닌만큼, 뭔가가 엄청 먹고싶을 땐 팍팍 먹고, 그렇지 않으면 자제력 지키면서 참으면 절대로 체중변화는 없다.  



방명록에 질문 남기시면 아는데까지 최대한 답변 드리도록 하겠다.

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

CephBacula에 이어서 이번 오픈소스 프로그램 매뉴얼은 PyKota라고하는 생소한 프로그램이다.  일단 소개부터 드리자면, PyKota는 이름에서 봐도 알 수 있든 파이썬으로 작성되어있는, 어느 유저어떤 프린터기얼마나 사용하는지 기록을 남기며, 프린터기 사용을 제한하는 일을 하는 프로그램이다.  본 매뉴얼은 리눅스 터미널 사용에 익숙하며 데이터베이스 혹은 LDAP에 대해서 이해하고 있어야만 한다.

매 매뉴얼마다 얘기하지만 이번 매뉴얼에도 언급한다.

이전 매뉴얼들을 페이스북에 공유하면서 다른 분들과 나눴던 대화 중 역시 가장 기억에 남는건, "다른 상용 프로그램과의 비교"였다.  글쓴이가 매뉴얼을 작성하는 이유는 "글쓴이가 현재 사용 중인 너무나도 좋은 오픈소스 프로그램을 많이들 모르고 계셔서"이다.

글쓴이가 근무하는 하와이 주립대학교는 하와이 주 정부의 "교육부"에 해당하는 곳으로, 몇 년 전까지만 해도 주 정부에서 예산이 지원됐었는데 갑자기 "너네는 알아서 잘 살아라" 라고 일방적으로 통보하고 예산지원을 끊어버렸다.  그 이후 주립대학교의 학비가 큰 폭으로 상승됐고 장학금 등도 많이 줄었다.  이래저래 학교가 돈이 없다.  꼭 이러한 이유만은 아니겠지만, 어찌됐든간에 글쓴이가 근무하는 곳에서는 어떠한 시스템을 구축하고자 할 때는 너무나도 당연히 오픈소스부터 알아본다.  상용 프로그램이야 찾으면 얼마든지 널리고 널렸고, 없다고 한들 돈 주면 다 해결되는게 지금 세상이지 않나.  일단, 오픈소스를 찾고 그것을 기술지원해주는 업체에 기술지원비를 지불하여 서비스를 받는 식으로 이용하는 중이다.  말 나온김에 나열을 해보자면

OpenStack - Mirantis
OpenLDAP - Symas
LDAP Account Manager - LAM Pro
Firewall - pfSense
ownCloud - ownCloud Enterprise
Backup - Bacula Systems

정도가 되겠다.  좌측이 프로그램 이름이고, 우측이 기술지원 업체명이다.  모두 오픈소스 프로그램이다.  이들은 모두 오픈소스 프로그램을 바탕으로해서 자기들만의 패치를 더하는 제품을 내놓거나, 아예 처음부터 제품개발을 오픈소스로 하고 상용버전은 별도로 유지보수하는 식으로 한다.

이만하면 설명이 충분히 됐으니, 더 이상 상용 프로그램과 비교하는 분이 없으면 한다.  다시 한 번 강조하지만, 매뉴얼을 쓰는 목적은 좋은 오픈소스를 알리고자함이다.  어차피 상용은 그만큼 매뉴얼도 잘 되서 나오니까 이렇게 매뉴얼 작성하는 것도 필요없겠지만.  솔루션 필요할 때마다 아예 상용만 찾는 회사들도 있다.  그런 회사에서 근무하시는 분이라면 본 매뉴얼은 필요없을 거다.

 

글쓴이의 상사가 이런 얘길 했다.  "우리 College 내에서 어떤 교수는 분명 프린터기를 엄청나게 쓰고있는데, 우리는 그걸 파악조차 하고있지 못하다.  물론, 우리가 그들의 프린터기 사용을 제한할 수 없지만 적어도 누가 얼만큼을 쓰는지는 좀 알고있어야할 필요가 있어보인다." 라고 하면서 이 PyKota라는 프로그램에 대해서 알아보라고 했다.  본인이 근무하는 곳은 College Of Education으로서, 한국으로 치자면 "교육대학"쯤 되겠다.  그러니까, 하와이 주립대학교 교육대학이다.  교육대학의 총 교수진과 직원의 수는 대략 400여명 정도이고, 주립대학교 내의 대학들간의 교수진/직원 정보는 절대로 공유하지 않는다.  따라서, 글쓴이는 교육대학만 관리하고 그외 자연대학, 경영대학 등은 전혀 모른다.  알 방법도 없다.

본격적으로 시작해보자.  사실 2006년을 끝으로 개발이 중단된 것으로 보이지만 작동이 잘 되기 때문에 전혀 문제가 없다.  글쓴이가 테스팅한 환경은 우분투 10.04와 12.04 64비트 서버였으며 현재 대학 내 전체 사무실로의 적용을 준비 중이다.

PyKota는 다소 부적절한 용어를 섞어서 한 문장으로 설명하자면 "조낸 어렵고 조낸 복잡하며 조낸 잘만들어진" 프로그램이다.  처음 이것을 설치할 때엔 뭐 이딴 프로그램이 다 있나 싶을 정도로 이해하기도 어렵고 설명도 제대로 안되어있는 불친절한 프로그램이라고 생각했으며, 실제로 이것을 이용해서 프린트를 성공적으로 하게된 데에만 무려 1주일이라는 시간을 투자했다.  시간 들인 것과는 다르게, 핵심만 뽑아서 설명하면 한 편의 매뉴얼로 충분하므로 이 매뉴얼은 나눠서 설명하지 않는다.  이것 때문에 얼마나 스트레스 받았는지는 IRC에 자주 오신 분들이라면 글쓴이가 불평하는걸 여러 번 보셨을 거다.

PyKota는 프린터기 사용을 기록하기 위해 PostgreSQL, MySQL 등의 데이터베이스와 LDAP을 지원하는데, LDAP을 지원하는 것이 글쓴이에게 가장 핵심적인 요소였다.  하와이 주립대학교의 모든 인적정보는 LDAP으로 관리하기 때문이다.  데이터베이스를 이용한 설정은 LDAP에 비해서 쉽고 간단하기 때문에 설명하지 않는다.  게다가 하다하다 안되면 로컬에서 테스트를 해보는 것도 가능하지만, 반대로 LDAP은 인적정보를 포함한 상태로 로컬서버를 구축하는 것이 쉽지않기 때문에 훨씬 어렵다.  따라서, 본 매뉴얼은 DB를 이용한 설명은 생략하고 LDAP을 이용한 구축만 설명드린다.

먼저 PyKota의 동작원리부터 보자.

보고 자시고 할 것도 없이 간단하다.  한 가지 특이한 점은, 사용자의 프린트 요청을 CUPS가 바로 받는 게 아니라 PyKota가 바로 받는다는 점이다.

설치를 시작하자.  설치에 들어가기에 앞서 글쓴이의 테스팅 환경은 Ubuntu 12.04 64bit server, OpenLDAP에 start_tls, 그리고 HP LaserJet 4000라는 리눅스에서 특별한 드라이버 설치없이 사용가능한 투박한 프린터기다.

1.  아래의 두 파일들을 다운로드 한다.
$ wget http://www.pykota.com/software/pykota/download/tarballs/pykota-1.26_fixes_official.tar.gz
$ wget http://www.pykota.com/software/pkipplib/download/tarballs/pkipplib-0.07.tar.gz

 

2.  필수패키지를 설치할 차례다.
$ sudo apt-get install cups cups-client python-dev python-jaxml \ 
  python-reportlab python-reportlab-accel python-ldap python-osd \
  python-egenix-mxdatetime python-imaging python-pysnmp4 \
  python-chardet python-pam pkpgcounter

 

3.  대략 500메가가 넘는 패키지들이 설치될 거라고 나온다.  설치가 끝났으면 pkipplib부터 압축을 풀자.
$ tar xfz pkipplib-0.07.tar.gz

 

4.  pkipplib을 설치한다.  간단하다.
$ cd pkipplib-0.07/; sudo python setup.py install

 

5.  이제 PyKota의 압축을 풀자.  PyKota 패키지에서 프로그램이 빠진 것을 체크해주는 간단한 스크립트가 있으니 이걸 이용한다.
$ tar xfz pykota-1.26_fixes_official.tar.gz
$ cd pykota-1.26_fixes_official
$ python ./checkdeps.py

실행하고나면 뭔가 많이 나온다. 

Checking PyKota dependencies...
Checking for Python-PygreSQL availability : NO.
ERROR : Python-PygreSQL not available !
PygreSQL is mandatory if you want to use PostgreSQL as the quota database backend.
See http://www.pygresql.org
Checking for Python-SQLite availability : NO.
ERROR : Python-SQLite not available !
Python-SQLite is mandatory if you want to use SQLite as the quota database backend.
See http://www.pysqlite.org
Checking for MySQL-Python availability : NO.
ERROR : MySQL-Python not available !
MySQL-Python is mandatory if you want to use MySQL as the quota database backend.
See http://sourceforge.net/projects/mysql-python
Checking for Python-egenix-mxDateTime availability : OK
Checking for Python-LDAP availability : OK
Checking for Python-OSD availability : OK
Checking for Python-SNMP availability : OK
Checking for Python-JAXML availability : OK
Checking for Python-ReportLab availability : OK
Checking for Python-Imaging availability : OK
Checking for Python-Psyco availability : NO.
ERROR : Python-Psyco not available !
Python-Psyco speeds up parsing of print files, you should use it.
See http://psyco.sourceforge.net/
Checking for Python-pkpgcounter availability : OK
Checking for Python-PAM availability : OK
Checking for Python-pkipplib availability : OK
Checking for Python-chardet availability : OK
Checking for GhostScript availability : OK
Checking for SNMP Tools availability : OK
Checking for Netatalk availability : OK

메시지를 보면 PygreSQL, SQLite, MySQL, Psyco가 없다고 뜬다.  본 매뉴얼에서는 데이터베이스를 이용하지 않고 LDAP을 이용할 거라서 메시지는 무시해도 된다.  Python-Psyco의 경우 공식 매뉴얼에 의하면 32비트 컴퓨터에서만 필요하다고 써있다 (그렇다고 필수는 아니다).  따라서 글쓴이는 64비트 서버를 운영하는 관계로 패스했다.

 

6.  설치를 시작하자.
$ sudo python setup.py install 

 

7.  CUPS에게 PyKota의 존재를 알려야한다.
$ sudo cp /usr/local/share/pykota/cupspykota /usr/lib/cups/backend
$ sudo chmod 755 /usr/lib/cups/backend/cupspykota 

 

8.  PyKota를 위한 유저를 생성하고 설정파일을 복사해주자
$ sudo adduser --system --group --home /etc/pykota --gecos PyKota pykota
$ sudo chown pykota:pykota /etc/pykota/pykota.conf /etc/pykota/pykotadmin.conf
$ sudo usermod -aG lpadmin pykota

 

9.  cups의 설정파일을 수정해줘야한다.  이 매뉴얼을 보고 연습하시는 분이 localhost에서 하신다면 필요없지만, CUPS의 웹인터페이스에 localhost가 아닌 remote로 접속하려면 해야한다.  구글링하면 방법이 나오지만, 일단 간단하게나마 중요부분만 올려드린다.
Port 631
Listen /var/run/cups/cups.sock  (Listen localhost는 삭제한다.  Listen 127.0.0.1이 있으면 그것도 삭제한다)

Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseLocalProtocols CUPS dnssd
BrowseAddress @LOCAL
BrowseWebIF Yes
BrowseRemoteProtocols

WebInterface Yes

이후 <Location>에는 Allow from IP주소를 모든 Location 항목마다 넣어주자.  <Policy> 항목에는 필요없다.

 

10.  CUPS를 재시작하고 웹브라우저를 열어서 포트번호 631로 접속해보자.  상단 Administration 클릭하면 아이디랑 비번을 물어볼 거다.  그건 CUPS가 설치되어있는 서버의 유저명과 비번을 입력하면 된다.   그리고나서 Add Printers를 클릭하여 프린터기를 추가한다.  주의할 점은 Share this printer를 반드시 선택해야한다는 점이며, 프린터기의 이름은 중요하다 (프린터기의 이름에는 공백을 허용하지 않는다).

 

11.  작동이 잘되면 이제 본격적으로 PyKota의 설정을 할 차례다.  먼저, Admin 파일부터 수정한다.  Admin 파일은 관리자 계정을 지정하는 역할 이외에는 없다.  따라서 데이터베이스로 운영하실 분이라면 파일을 열어서 계정만 설정해주고, LDAP을 하실 분이라면 LDAP의 기본 정보만 넣어주면 된다.  글쓴이의 파일을 일부만 수정한채 그대로 올려드린다.

$ sudo vi /etc/pykota/pykotadmin.conf
[global]

storagebackend: ldapstorage
storageserver: ldap://ldap.server.address
storagename: dc=abc,dc=com
storageadmin: cn=admin,dc=abc,dc=com
storageadminpw: AdminPassword

주의하실 점은, PyKota는 파이썬으로 작동하므로 라인 맨 앞에 공백이 있으면 안된다.

 

12.  가장 어려운 항목은 pykota.conf 파일이다.  무려 1,400라인이나 된다.  물론 대부분은 주석이지만, 복잡한 건 사실이다.  DB는 위와 마찬가지로 유저이름과 비번만 넣어주면 알아서 테이블 생성하고 관리하니까 큰 문제 없는데 LDAP은 아무래도 좀 다르니 설명 드린다.

/usr/local/share/pykota/ldap 디렉토리에 가면 LDAP 스키마 파일과 LDIF 샘플 파일이 있다.  이걸 보시면 뭐가 필요한지 LDAP 관리자라면 바로 파악하실 수 있을텐데, 일단 top에 ou=pykota를 하나 만들고 그 아래로
ou=billingcodes
ou=gquotas
ou=jobs
ou=lastjobs
ou=printers
ou=uquotas

가 반드시 필요하며, 아파치 디렉토리 스튜디오에서 보는 화면은 다음과 같다. 

 

다음은 유저에 해당하는 부분의 스크린샷이다.

Balance가 -4.0인 것은 신경쓰지 말되, 신경써서 봐야할 곳은 pykotaLimitBypykotaUserName이다.  밑에서 따로 설명한다.

글쓴이의 설정파일을, 주석처리된 부분 제외하고 올려드린다.  참고로, 글쓴이는 유저의 프린터기 사용 자체는 제한하지 않는다는 점을 명심하자.

[global]
storagebackend: ldapstorage
storageserver: ldap://ldap.server.com
storagename: dc=abc,dc=com
storageuser: cn=pykotastorage,dc=abc,dc=com
storageuserpw: pykota_storage_password
ldaptls: Yes
cacert: /etc/ssl/certs/your_certification.crt
userbase: ou=people,dc=abc,dc=com
userrdn: uid
balancebase: ou=people,dc=abc,dc=com
balancerdn: uid
groupbase: ou=groups,dc=abc,dc=com
grouprdn: cn
printerbase: ou=printers,ou=pykota,dc=abc,dc=com
printerrdn: cn
jobbase: ou=jobs,ou=pykota,dc=abc,dc=com
lastjobbase: ou=lastjobs,ou=pykota,dc=abc,dc=com
billingcodebase: ou=billingcodes,ou=pykota,dc=abc,dc=com
userquotabase: user
userquotabase: ou=uquotas,ou=pykota,dc=abc,dc=com
groupquotabase: group
groupquotabase: ou=gquotas,ou=pykota,dc=abc,dc=com
newuser : below
newgroup : below
usermail : mail
groupmembers: memberUid
storagecaching: No
disablehistory: No
logger: system
debug : Yes
logourl : http://www.pykota.com/pykota.png
logolink : http://www.abc.com/
smtpserver: localhost
maildomain: example.com
usernamecase: native
privacy : no
onbackenderror : nocharge
keepfiles : no
accounter: software()
skipinitialwait : no
preaccounter: software()
onaccountererror: stop
admin: Administrator
adminmail: admin@abc.com
mailto : both
balancezero: 0.0
gracedelay : 7
poorman : 1.0
poorwarn : Your Print Quota account balance is low.
Soon you'll not be allowed to print anymore.
softwarn: Your Print Quota Soft Limit is reached.
This means that you may still be allowed to print for some
time, but you must contact your administrator to purchase
more print quota.
hardwarn: Your Print Quota Hard Limit is reached.
This means that you are not allowed to print anymore.
Please contact your administrator at root@localhost
as soon as possible to solve the problem.
policy : external(/usr/local/bin/pkusers --add --skipexisting --limitby noquota $PYKOTAUSERNAME && /usr/local/bin/edpykota --add --skipexisting --printer $PYKOTAPRINTERNAME $PYKOTAUSERNAME)
policy: deny
maxdenybanners: 0
enforcement : strict
trustjobsize : yes
denyduplicates : no
duplicatesdelay : 0
noprintingmaxdelay : 60
statusstabilizationloops : 5
statusstabilizationdelay : 4.0
snmperrormask : 0x4FCC

 

13.  위의 10번에서 CUPS의 프린터기 추가가 성공적으로 됐으면, 해당 프린터기에 해당하는 설정을 pykota.conf 파일에 넣어줘야하는데, 아래의 명령어를 실행하면 된다.  솔직히 왜 이걸 유저가 하게했는지 이해가 안가는 명령어다.

$ sudo /usr/local/bin/pkturnkey --doconf

대략 다음과 비슷하게 나올 거다.

INFO: Please be patient...
INFO: Don't worry, the database WILL NOT BE MODIFIED.
INFO: Extracting all print queues.
INFO: pkprinters --arguments /tmp/pkprinters.args
INFO: Simulation terminated.

--- CUT ---
# Here are some lines that we suggest you add at the end
# of the pykota.conf file. These lines gives possible
# values for the way print jobs' size will be computed.
# NB : it is possible that a manual configuration gives
# better results for you. As always, your mileage may vary.
#
[FS-2000D]
preaccounter : software()
accounter : hardware(snmp)

맨 아래 빨갛게 처리해놓은 3줄을 복사해서 /etc/pykota/pykota.conf 파일 맨 아래에 삽입하면 된다.  역시 주의할 점은 라인마다 맨 앞에 공백이 있으면 안된다는 점이다.

 

14.  CUPS에 등록된 프린터기의 설정을 변경해야한다.  유저가 프린트를 하면 이것을 PyKota가 가로채서 먼저 작업을 하고 CUPS에 전달하는 역할을 하게하는 부분이다.  먼저 CUPS 서비스 데몬부터 중지시키고나서 설정파일을 열여본다.
$ sudo service cups stop
$ sudo vi /etc/cups/printers.conf

파일을 열어서 DeviceURI라고 적힌 라인을 찾아보면 아래와 비슷하게 되어있을 거다. 
DeviceURI socket://192.168.0.181

다음과 같이 고친다. 
DeviceURI cupspykota://socket://192.168.0.181 

프린터기가 여러 대라면 모두 바꿔야한다.  다 수정했으면 CUPS를 다시 시작해준다.
$ sudo service cups start 

 

15.  이제 이 프린터기를 데이터베이스나 LDAP에 등록시켜서 PyKota에 의해 이용현황이 통계되도록 해야한다.  10번에서 추가했었던 프린터기의 이름을 다시 한 번 확인한다.  
$ sudo /usr/local/bin/pkprinters --add --cups -D "프린터기의 설명" --charge 1 "Printer_Name"

프린터기의 설명은 편한대로 넣고, "Printer_Name" 부분은 CUPS에 등록된 프린터기의 이름을 넣는다.  여기서 charge 1이라는 옵션은, 이 프린터기에서 프린트를 한 장 출력할 때 얼마의 비용(cost)을 청구할 것인가를 정하는 부분이다.  예를 들어서, 컬러 프린터기는 1.2배 정도 비싸게 하고싶다거나, 흑백 프린터기는 0.8 정도로 20% 싼 비용을 청구하게 할 수도 있다.  비용이라고 해서 이게 꼭 돈을 의미하는 것은 아니며, 일종의 "포인트" 정도의 개념으로 볼 수 있다.  글쓴이처럼 학교에서 근무하는 분이라면 프린터기마다 비용을 정할 수도 있고, 학생과 교수를 구분하기 위한 group코드나 billing 코드를 설정할 수도 있다.

프린터기가 제대로 추가됐는지 확인해보자.
$ pkprinters -l

FS-2000D [Printer description] (0.0 + #*1.0)
Passthrough mode : OFF
Maximum job size : Unlimited
Routed through PyKota : YES

빨갛게 표시된 부분이 YES로 안되어있으면 /etc/cups/printers.conf 설정이 잘못된 거다.

 

16.   이제 사용자를 확인해볼 차례다.  PyKota를 사용하는 가장 큰 이유가 되는 곳이다.  다시 한 번 상기시켜드린다.  12번에서 pykotaLimitBy와 pykotaUserName을 신경써서 봐야한다고 설명했다.  DB 사용자라면 사용자를 수동으로 추가시켜줘야하며, LDAP 유저라면 필요없다.  DB사용자를 위한 사용자 추가방법을 설명해드릴건데, LDAP 유저에게도 필요한 사항이 나오니 건너뛰지말고 보시길 바란다.

PyKota에서는 사용자에게 프린트 사용제한을 5가지로 한다.  첫번째로는 프린터기별로 쿼타 (Quota)를 지정해서 지정된 쿼타를 모두 소모하면 프린터기가 작동되지 않는 방식이 있고 (quota), 두 번째는 사용자별로 포인트 (Balance)를 충전해서 포인트를 모두 소모하면 작동을 거부하는 방식이 있으며 (balance), 세 번째로는 쿼타 무시 (noquota), 네 번째는 포인트 무시 (nochange), 마지막은 프린트 금지가 되겠다 (noprint).  쿼타나 포인트 무시를 설정하더라도 프린터기 사용 자체는 모두 기록된다는 점을 알아두자.

사용자 추가는 /usr/local/bin/pkusers --add username 으로 가능하다.  pkusers를 입력해보면 다양한 옵션이 제공되는데, 포인트 충전식으로 지정하고, 유저를 생성하면서 동시에 10 포인트를 충전해주고, 포인트를 넘어서 프린터기를 이용할시 할증료로 2.5배를 청구하며, 프린터기는 hp4000만 이용할 수 있게 하겠다고 치면,

$ pkusers --add username --limitby balance --overcharge 2.5 --balance +10.0 --printer hp4000 UserName

이라는 명령어로 유저를 생성할 수 있다.  물론, 유저만 먼저 추가하고 나중에 설정을 변경하는 것은 edpykota 라는 명령어로 가능하다.  여기서 LDAP 유저가 알아야할 점은, 위의 명령어는 실행할 필요가 없으며 (이미 유저가 있으므로), 12번 스크린샷에서 나오듯 사용자의 pykotaLimitBy 값을 위에 나열한대로 적절한 값으로 수정하면 되겠다.  위의 예제에서 나와있는 것에 해당하는 옵션들은 스크린샷을 보시면 모두 있으니까 해결이 가능해보이는데, pykotaUserName라는 것만 다르다는 것을 볼 수 있다.  물론 위의 예제에는 --printer와 옵션이 매치되는 것도 알 수 있다.  LDAP 유저는 이용가능한 프린터기의 목록을 ou=uquotas에 기록하는데, 이것도 스크린샷을 통해 알아보자.

위의 스크린샷의 pykotaUserName과 12번 uid=username,ou=peoplepykotaUserName의 문자열이 같음을 알 수 있다.  즉, ou=uquotas에서 cn을 하나 생성하고 위의 스크린샷처럼 attr.을 추가하면 pykotaUserName으로 sysadmin이라고 되어있는 사용자만이 Wist_235라는 프린터기를 사용할 수 있게 허가하는 것이다.

프린트를 실행했는데 뭔가 잘 안된다면, pykota.conf 파일을 열어서 debug = Yes로 되어있는지 확인한 뒤, tail -f /var/log/syslog 열어놓고 나오는 로그를 보면 상세한 이유가 나온다.  대부분은 LDAP에 필요한 필수 Attributes를 넣지않아서일거다.

 

17.   이제, 다른 제약사항을 걸어보자.  /etc/pykota/pykota.conf 파일을 열어보자.
a.  askconfirmation 이라는 항목을 찾아가면 주석처리되어있는 아주 긴 라인이 하나 있는데, 이것의 주석을 풀면 프린트를 하려고 할 때마다 Yes, No를 묻게 할 수 있다.
b.  policy 항목을 찾아가면 external(/usr/local/bin/pkusers --add …… 라인이 있는데, 이것은 uquotas에는 유저가 있는데 실제 사용자는 없을 때 유용하게 쓸 수 있다.  예를 들자면, 유저가 이미 존재하면 건드리지말되, 없으면 추가하면서 일단 무제한으로 프린트를 할 수 있게 하며, pykotaPrintName 설정되어있는 프린터기를 기본으로 사용하게끔 한다고 친다면,

policy : external(/usr/local/bin/pkusers --add --skipexisting --limitby noquota $PYKOTAUSERNAME && /usr/local/bin/edpykota --add --skipexisting --printer $PYKOTAPRINTERNAME $PYKOTAUSERNAME)

라고 설정할 수 있다.
c.  policy: deny 를 설정하면, 조건이 맞지않는 프린트 요청은 모두거부한다.
d.  banner 항목을 설정하면 인쇄되는 종이마다 상/하단에 특정 메시지를 찍을 수 있다.  (startingbanner, endingbanner)
e.  smtpserver를 설정하면 인쇄 거부시 해당 사용자에게 이메일을 발송한다.

 

18.  마지막 순서로, 해도되고 안해도 되는 부분이다.  웹CGI 스크립트를 설치해서, 인쇄사용량에 대한 리포트를 뽑아보거나, 인쇄 전 내가 프린트하려는 파일이 몇 장이나 나오는지에 대한 간단한 스크립트가 있다.  솔직히 그닥 쓸만하진 않다.

아파치와 관련 모듈을 설치하고, CGI 스크립트를 복사해준다.

# apt-get install apache2 pwauth
# a2enmod authnz_external
# mkdir /usr/lib/cgi-bin/pykota/ 
# cp /usr/local/share/pykota/cgi-bin/* /usr/lib/cgi-bin/pykota/ 
# cp /usr/local/share/pykota/stylesheets/pykota.css /var/www/

/etc/apache2/sites-enabled/000-default 파일을 열어서 <Directory /usr/lib/cgi-bin> 섹션 안에 다음을 삽입한다.

<Directory "/usr/lib/cgi-bin/pykota"> 
  AllowOverride None 
  Options +ExecCGI -Multiviews +SymlinksIfOwnerMatch 
  Order allow,deny 
  AuthType Basic 
  AuthName "Restricted Server" 
  AuthBasicProvider external 
  AuthExternal pwauth 
  Require valid-user 
  Allow from all 
</Directory>

AddExternalAuth pwauth /usr/sbin/pwauth
SetExternalAuthMethod pwauth pipe

CUPS를 재시작한다.
# /etc/init.d/apache2 restart

CGI에 접속되는지 확인해보자.
http://machine_ip/cgi-bin/pykota/pykotme.cgi 
http://machine_ip/cgi-bin/pykota/printquota.cgi 
http://machine_ip/cgi-bin/pykota/dumpykota.cgi

 

 

19.  다음은 공식 매뉴얼을 볼 수 있는 주소다.

http://ftp.psu.ac.th/pub/pykota/latest/pykota/stable/pykota-1.26_official/docs/pykota.pdf

 

끝.

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

이번 편에서는 복원에 대해서 알아보자.  방법 자체는 백업과 크게 다르진 않은데, DIR에 Job으로 정의해놓을 경우 지정된 시간에 지정된 복원을 수행하는 것이 가능하다.  예를 들자면, 매일 같은 상태로 복원되어야만 하는 컴퓨터들이 여러대 혹은 수십 수백대가 있다면 이것들을 일괄처리할 수 있다는 장점이 있다.  설정은 전부 다 같고 Job {} 섹션에서 Type = Backup을 Type = Restore로 넣어주기만 하면 되니까 이것의 실습은 생략하고, bconsole을 이용한 복원을 실습해보도록 한다.

일단 Bacula는 최소 하나 이상의 복원 Job을 정의해야만 수동 복원작업이 작동가능하도록 되어있다.  /etc/bacula/bacula-dir.conf 파일을 열어서 최소한의 설정만 넣어주면 되므로, 다음의 내용을 삽입하고 데몬을 재시작해주자.

Job {
  Name = "Restore"
  Type = Restore
  Messages = Standard
  Pool = Server
  Client = "DBServer"
  FileSet = "Full Set"
}

sudo service bacula-director restart

 

위에 정의해놓은대로만 복원작업이 작동되는건 아니다.   bconsole을 이용하여 원하는 클라이언트에 원하는 파일을 복원할 수 있다.  Bacula의 복원은 원하는 파일을 원하는 위치에 꽂아넣을 수 있다는 장점이 있다.  bconsole에서 restore를 입력해보자.  

*restore
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"

First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.

To select the JobIds, you have the following choices:
1: List last 20 Jobs run
2: List Jobs where a given File is saved
3: Enter list of comma separated JobIds to select
4: Enter SQL list command
5: Select the most recent backup for a client
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Select full restore to a specified Job date
13: Cancel
Select item: (1-13):

차례대로 보자.

1. 마지막 20개 작업 나열
2. 파일이 백업된 장소로 작업 나열
3. 작업별 ID 번호를 콤마 기호로 나열하여 입력
4. SQL 쿼리를 사용한 목록 나열
5. 클라이언트의 가장 최근 작업을 선택 => 가장 많이 쓰인다.
6. 클라이언트의 특정 시간대 이전 작업 선택
7. 복원할 파일명을 직접 입력
8. 특정 시간대 이전에 백업된 파일 중 복원할 파일명을 직접 입력
9. 클라이언트의 가장 최근 백업 ID 찾기
10. 특정 시간대 이전 클라이언트의 가장 최근 백업 ID 찾기
11. 특정 백업 ID에 백업된 디렉토리명 입력
12. 특정 일자로 전체 복원
13.  취소

 

이전의 예제에서 우리는 FTP 서버를 백업했으므로 5번 메뉴를 이용하여 복원을 해보자.  참고로 입력을 잘못 했을 경우 점 (.)을 찍으면 언제든지 취소할 수 있다.

Select item: (1-13): 5
Defined Clients:
  1: DBServer
  2: Desktop
  3: FTP Server
  4: Web Server
  5: dbserver-fd
Select the Client (1-5): 3
Automatically selected FileSet: Full Set
+-------+-------+----------+-------------+---------------------+------------+
| JobId | Level | JobFiles |  JobBytes   |     StartTime       | VolumeName |
+-------+-------+----------+-------------+---------------------+------------+
|   5   |   F   |  55,461  | 982,708,126 | 2013-06-25 05:03:10 |  Server-1  |
+-------+-------+----------+-------------+---------------------+------------+
You have selected the following JobId: 5

Building directory tree for JobId(s) 5 ... +++++++++++++++++++++++++++++++++++++++++++
48,147 files inserted into the tree.

You are now entering file selection mode where you add (mark) and
remove (unmark) files to be restored. No files are initially added, unless
you used the "all" keyword on the command line.
Enter "done" to leave this mode.

cwd is: /

몇몇개의 단순한 유닉스 명령어가 지원된다.  어떤 명령어가 지원되는지 궁금하면 역시 마찬가지로 탭키를 입력하면 보여준다.   파일의 목록을 나열해보자.

ls

bin/
boot/
dev
etc/
home/
initrd.img
lib/
lib64/
lost+found
media/
mnt/
opt
root/
run
sbin/
selinux
srv
sys
usr/
var/
vmlinuz
$

실습에서는 /etc/bacula/bacula-fd.conf 파일을 /tmp 위치로 복원하는 것을 해보자.

$ cd etc/bacula
cwd is: /etc/bacula/
$ ls
bacula-fd.conf
bacula-sd.conf
bacula-sd.conf.dist
common_default_passwords
scripts/
$ mark bacula-fd.conf
1 file marked.
$ done
Bootstrap records written to /var/lib/bacula/dbserver-dir.restore.1.bsr

The job will require the following
  Volume(s) Storage(s) SD Device(s)
===========================================================================

  Server-1 Server Backup FileStorage-1

Volumes marked with "*" are online.


1 file selected to be restored.

Run Restore job
JobName: Restore
Bootstrap: /var/lib/bacula/dbserver-dir.restore.1.bsr
Where: *None*
Replace: always
FileSet: Full Set
Backup Client: FTP Server
Restore Client: FTP Server
Storage: Server Backup
When: 2013-06-25 06:31:54
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*

OK to run? (yes/mod/no): mod
Parameters to modify:
  1: Level
  2: Storage
  3: Job
  4: FileSet
  5: Restore Client
  6: When
  7: Priority
  8: Bootstrap
  9: Where
  10: File Relocation
  11: Replace
  12: JobId
  13: Plugin Options
Select parameter to modify (1-13): 9
Please enter path prefix for restore (/ for none): /tmp
Run Restore job
JobName: Restore
Bootstrap: /var/lib/bacula/dbserver-dir.restore.1.bsr
Where: /tmp
Replace: always
FileSet: Full Set
Backup Client: FTP Server
Restore Client: FTP Server
Storage: Server Backup
When: 2013-06-25 06:31:54
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): yes
Job queued. JobId=6

이제 제대로 실행되는지 보자.

*status dir
dbserver-dir Version: 5.2.5 (26 January 2012) x86_64-pc-linux-gnu ubuntu 12.04
Daemon started 25-Jun-13 06:15. Jobs: run=1, running=0 mode=0,0
Heap: heap=286,720 smbytes=77,288 max_bytes=9,888,526 bufs=270 max_bufs=295

Scheduled Jobs:
Level Type Pri Scheduled Name Volume
===================================================================================
Incremental Backup 10 25-Jun-13 23:05 DBServer Backup Server-1
Incremental Backup 10 25-Jun-13 23:05 FTP Backup *unknown*
Incremental Backup 10 25-Jun-13 23:05 WEB Backup Server-1
Incremental Backup 10 25-Jun-13 23:05 Desktop Backup Server-1
Full Backup 11 25-Jun-13 23:10 BackupCatalog Server-1
====

Running Jobs:
Console connected at 25-Jun-13 06:17
No Jobs running.
====

Terminated Jobs:
JobId Level Files Bytes Status Finished Name
====================================================================
1 Full 0 0 Error 25-Jun-13 03:34 BackupClient1
3 Full 0 0 Cancel 25-Jun-13 04:56 FTP_Backup
4 Full 10 7.737 K OK 25-Jun-13 04:58 FTP_Backup
5 Full 55,461 982.7 M OK 25-Jun-13 05:06 FTP_Backup
6 1 974 OK 25-Jun-13 06:32 Restore

====
You have messages.
*

Running에는 아무 것도 뜨지않았지만 message가 있다고 나오는걸 보니 작업이 끝난 것 같다.  확인해보자.

*messages
25-Jun 06:32 dbserver-dir JobId 6: Start Restore Job Restore.2013-06-25_06.32.45_03
25-Jun 06:32 dbserver-dir JobId 6: Using Device "FileStorage-1"
25-Jun 04:11 FTPServer-sd JobId 6: Ready to read from volume "Server-1" on device "FileStorage-1" (/mnt/backup-1/bacula).
25-Jun 04:11 FTPServer-sd JobId 6: Forward spacing Volume "Server-1" to file:block 0:9594.
25-Jun 06:32 dbserver-dir JobId 6: Bacula dbserver-dir 5.2.5 (26Jan12):
Build OS: x86_64-pc-linux-gnu ubuntu 12.04
JobId: 6
Job: Restore.2013-06-25_06.32.45_03
Restore Client: FTP Server
Start time: 25-Jun-2013 06:32:47
End time: 25-Jun-2013 06:32:48
Files Expected: 1
Files Restored: 1
Bytes Restored: 974
Rate: 1.0 KB/s
FD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Restore OK

25-Jun 06:32 dbserver-dir JobId 6: Begin pruning Jobs older than 6 months .
25-Jun 06:32 dbserver-dir JobId 6: No Jobs found to prune.
25-Jun 06:32 dbserver-dir JobId 6: Begin pruning Files.
25-Jun 06:32 dbserver-dir JobId 6: No Files found to prune.
25-Jun 06:32 dbserver-dir JobId 6: End auto prune.

*

성공적으로 복원되었다.  이제 파일을 확인하러 가보자.   FTP 서버로 접속해서 /tmp 에 있는 파일을 확인하면 된다.

root@ftp:~# ls -l /tmp/etc/bacula/bacula-fd.conf
-rw-r----- 1 root root 974 Jun 25 02:29 /tmp/etc/bacula/bacula-fd.conf
root@ftp:~#

파일 소유권과 날짜까지 제대로 복원되었다.

 

Bacula에 대해 혹평하는 몇몇 외국 유저들의 이야기를 보면 그들 전부가 "어떻게 쓰는줄을 모르기 때문에" 생겨나는 불평이다.  백업이 안되느니 복원이 안되느니 하면서 사용을 포기하는 유저들을 몇몇 봤는데, 글쓴이 경험상 Bacula 자체에 버그가 있어서 안된 경우는 아직 못봤다.  처음 접하기 어려운 툴인 것만은 분명 사실이다.  하지만 작동원리만 알고나면 정말 쓰기 쉬운 프로그램인 것도 분명 사실이다.



다음 편에서는 GUI로 Bacula를 제어해보자.

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

이번 편부터는 실제로 수동백업을 해보자.  수동백업의 의미는, bacula-dir.conf 디렉터 데몬 설정파일에서 이미 Job, FileSet, Schedule 등으로 "자동화" 해놨으므로 백업작업은 스케쥴에 정의된 시간에 자동으로 실행이 될 예정이다.  하지만, 지정된 시간이 아닌 수동으로 백업을 할 수 있어야하며 이때 제공되는 CLI와 GUI툴이 있다. 

일단은 GUI보다 CLI로 먼저 실습을 해볼건데, 왜냐하면 GUI는 기본적으로 CLI 툴에서 나오는 메시지를 예쁘게 포장한 것에 불과하기 때문이며, 리눅스 프로그램들이 다들 그렇듯 자세한 설정은 결국 CLI를 통해야만 하기 때문이다.  따라서, CLI툴에 익숙해져야 응급상황에 빠르게 대처할 수 있다.

Bacula의 CLI툴은 bconsole이라고 하는데, apt-get install bacula-console 명령을 통해서 설치할 수 있다.  디렉터 서버는 이 예제에서는 DBserver에서 운영 중이므로 DBserver에서 설치한다 (물론 다른 서버에 설치해도 된다.  그게 Bacula의 장점이다).  설치가 끝나면 /etc/bacula/bconsole.conf 파일을 열어서 name과 주소, 그리고 패스워드를 DIR 설정에 맞게 변경해주자.

Director {
  Name = dbserver-dir
  DIRport = 9101
  address = 10.211.55.33
  Password = "dir"
}

다 됐으면 루트권한으로 bconsole을 실행하자.  다음과 같은 화면이 나올거다.

root@dbserver:/etc/bacula# bconsole
Connecting to Director 10.211.55.33:9101
1000 OK: dbserver-dir Version: 5.2.5 (26 January 2012)
Enter a period to cancel a command.
*

bconsole은Tab키를 이용한 자동완성을 지원하므로 명령어가 생각이 나지않거나 파일셋, 클라이언트 이름 등이 해깔릴 때 요긴하게 사용할 수 있다.  먼저, DIR의 상태를 확인해보자.

*status dir
dbserver-dir Version: 5.2.5 (26 January 2012) x86_64-pc-linux-gnu ubuntu 12.04
Daemon started 25-Jun-13 04:09. Jobs: run=0, running=0 mode=0,0
Heap: heap=405,504 smbytes=49,275 max_bytes=51,814 bufs=220 max_bufs=232

Scheduled Jobs:
Level Type Pri Scheduled Name Volume
===================================================================================
Incremental Backup 10 25-Jun-13 23:05 DBServer Backup *unknown*
Incremental Backup 10 25-Jun-13 23:05 FTP Backup *unknown*
Incremental Backup 10 25-Jun-13 23:05 WEB Backup *unknown*
Incremental Backup 10 25-Jun-13 23:05 Desktop Backup *unknown*
Full Backup 11 25-Jun-13 23:10 BackupCatalog *unknown*
====

Running Jobs:
Console connected at 25-Jun-13 04:21
No Jobs running.
====

Terminated Jobs:
JobId Level Files Bytes Status Finished Name
====================================================================
1 Full 0 0 Error 25-Jun-13 03:34 BackupClient1

====
*

글쓴이가 이 글을 작성하는 시점에서 백업 스케쥴이 실행되는 시간이 되는 바람에 Job이 하나 취소됐다.  그래서 Terminated Jobs에 하나 떴다.

일단 DIR을 처음 실행하고 bconsole에 들어오면 가장 먼저 해야할 일이 볼륨을 생성해주는 일이다.  그래서, unknown이라는 메시지가 보이는 이유는 현재 DIR 데몬이 어디에 백업을 해야하는지 모르는 상태이다.  서버백업용 볼륨을 하나 생성해보자.

*label pool=Server storage="Server Backup" volume=Server-1
Connecting to Storage daemon Server Backup at 10.211.55.34:9103 ...
Sending label command for Volume "Server-1" Slot 0 ...
3000 OK label. VolBytes=193 DVD=0 Volume="Server-1" Device="FileStorage-1" (/mnt/backup-1/bacula)
Catalog record for Volume "Server-1", Slot 0 successfully created.
Requesting to mount FileStorage-1 ...
3906 File device ""FileStorage-1" (/mnt/backup-1/bacula)" is always mounted.
*

메시지를 보면 "successfully created"라고 나온걸 봐서 제대로 생성됐음을 알 수 있다.  그럼 이제 본격적으로 백업을 해보자.  우리가 지정한 파일셋이 제대로 적용됐는지 확인부터 해보자.

*show fileset="Full Set"
FileSet: name=Full Set
O M
N
I /
N
E /var/lib/bacula
E /nonexistant/path/to/file/archive/dir
E /proc
E /tmp
E /.journal
E /.fsck
N
*

제대로 나온다.  이제 클라이언트들이 제대로 응답하는지 확인해볼 차례다.  FTP 서버를 확인해보자.

*status client="FTP Server"
Connecting to Client FTP Server at 10.211.55.34:9102

ftp-fd Version: 5.2.5 (26 January 2012) x86_64-pc-linux-gnu ubuntu 12.04
Daemon started 25-Jun-13 02:29. Jobs: run=0 running=0.
Heap: heap=270,336 smbytes=15,781 max_bytes=15,928 bufs=48 max_bufs=49
Sizeof: boffset_t=8 size_t=8 debug=0 trace=0
Running Jobs:
Director connected at: 25-Jun-13 02:29
No Jobs running.
====

Terminated Jobs:
====
*

제대로 응답한다.  만약 명령어를 입력하고 "즉시" 응답이 없으면 설정이 잘못된 거다.  이 경우 십중팔구는 DIR 이름과 패스워드가 달라서 생기는 거다.  클라이언트에 SSH로 접속해서 /etc/bacula/bacula-fd.conf 파일을 열고 Director {} 섹션의 Name 항목이 dbserver-dir로 되어있는지, 그리고 Passwordftpserver로 되어있는지 확인하자.

이제 백업할 준비가 다 끝났다.  백업을 진행해보자.

*run job="FTP Backup" fileset="Full Set" client="FTP Server" storage="Server Backup" level="Full"
Using Catalog "MyCatalog"
Run Backup job
JobName: FTP Backup
Level: Full
Client: FTP Server
FileSet: Full Set
Pool: User Data (From Job resource)
Storage: Server Backup (From command line)
When: 2013-06-25 04:55:23
Priority: 10
OK to run? (yes/mod/no): 

여기서 위의 내용을 자세히 보면, Pool이 User Data라고 되어있는 것을 볼 수 있다.  이것은 bacula-dir.conf 파일에 정의된 Job 항목에 Pool이 User Data로 되어있기 때문인데, 일단 우리는 유저 데이터를 백업하려는게 아니라 서버 자체를 백업하려고 하는 것이므로 이것을 수정해서 Server Pool을 이용하도록 하자.

OK to run? (yes/mod/no): mod
Parameters to modify:
  1: Level
  2: Storage
  3: Job
  4: FileSet
  5: Client
  6: When
  7: Priority
  8: Pool
  9: Plugin Options
Select parameter to modify (1-9): 8
The defined Pool resources are:
  1: Server
  2: User Data
Select Pool resource (1-2): 1
Run Backup job
JobName: FTP Backup
Level: Full
Client: FTP Server
FileSet: Full Set
Pool: Server (From User input)
Storage: Server Backup (From command line)
When: 2013-06-25 04:58:16
Priority: 10
OK to run? (yes/mod/no): yes
Job queued. JobId=5
*

Job이 제대로 접수됐는지 DIR의 상태를 확인해보자.  참고로, 위의 예제에서 JobID가 5인 이유는 글쓴이가 테스트를 위해서 여러번 실행했다 취소했다를 반복해서 그런 것이니 신경쓰지 말자.

*status dir
dbserver-dir Version: 5.2.5 (26 January 2012) x86_64-pc-linux-gnu ubuntu 12.04
Daemon started 25-Jun-13 04:47. Jobs: run=2, running=0 mode=0,0
Heap: heap=405,504 smbytes=91,751 max_bytes=117,401 bufs=277 max_bufs=309

Scheduled Jobs:
Level Type Pri Scheduled Name Volume
===================================================================================
Incremental Backup 10 25-Jun-13 23:05 DBServer Backup Server-1
Incremental Backup 10 25-Jun-13 23:05 FTP Backup *unknown*
Incremental Backup 10 25-Jun-13 23:05 WEB Backup Server-1
Incremental Backup 10 25-Jun-13 23:05 Desktop Backup Server-1
Full Backup 11 25-Jun-13 23:10 BackupCatalog Server-1
====

Running Jobs:
Console connected at 25-Jun-13 05:01
JobId Level Name Status
======================================================================
5 Full FTP_Backup.2013-06-25_05.03.07_03 is running
====

Terminated Jobs:
JobId Level Files Bytes Status Finished Name
====================================================================
1 Full 0 0 Error 25-Jun-13 03:34 BackupClient1
3 Full 0 0 Cancel 25-Jun-13 04:56 FTP_Backup
4 Full 10 7.737 K OK 25-Jun-13 04:58 FTP_Backup

====
You have messages.
*

메시지 중간을 보면 running이라고 나온다.  실행 중이다.  잘 되고있다는 말이다.  마지막에 보면 You have messages.라고 나오면서 메시지가 있다고 나온다.  메시지를 확인해보자.

*messages
25-Jun 05:03 dbserver-dir JobId 5: Start Backup JobId 5, Job=FTP_Backup.2013-06-25_05.03.07_03
25-Jun 05:03 dbserver-dir JobId 5: Using Device "FileStorage-1"
25-Jun 02:41 FTPServer-sd JobId 5: Volume "Server-1" previously written, moving to end of data.
25-Jun 02:41 FTPServer-sd JobId 5: Ready to append to end of Volume "Server-1" size=9594
25-Jun 02:41 ftp-fd JobId 5: /sys is a different filesystem. Will not descend from / into it.
25-Jun 02:41 ftp-fd JobId 5: /dev is a different filesystem. Will not descend from / into it.
25-Jun 02:41 ftp-fd JobId 5: /run is a different filesystem. Will not descend from / into it.
25-Jun 02:41 ftp-fd JobId 5: /mnt/backup-2 is a different filesystem. Will not descend from / into it.
25-Jun 02:41 ftp-fd JobId 5: /mnt/backup-1 is a different filesystem. Will not descend from / into it.
*

잘 읽어보면 특수 파일시스템, sys, dev, run 등은 백업하지 않는다고 써있다.  또한, 추가로 붙인 하드디스크 역시 다른 파일시스템이라고 백업하지 않겠단다.  이것을 백업하려면 FileSet에 Include항목을 이용하면 된다.  다만, 본 테스트 한정으로, 백업 볼륨이 저 위치에 저장되므로 그것을 유의해서 스스로 백업하는 일이 없도록 하자.  대충 써보면 다음과 같다고 본다.

Include {
  File = /
  File = /mnt/backup-1
}
Exclude {
  File = /mnt/backup-1/bacula
}

 

백업이 어떻게 진행되가는지 궁금하다.  이럴 때는 status dir을 해도 되고 그냥 엔터키만 쳐도 된다.  그냥 엔터키를 쳐보자.

*
You have messages.
*

메시지가 와있다.  messages를 입력하면 보여주는데, bconsole에서 autodisplay on을 입력하면 엔터키를 입력할 때마다 추가생성되는 메시지를 자동으로 보여준다.  이것을 이용해보자.

*autodisplay on
25-Jun 02:44 ftp-fd JobId 5: /media/cdrom is a different filesystem. Will not descend from / into it.
25-Jun 02:45 FTPServer-sd JobId 5: Job write elapsed time = 00:03:32, Transfer rate = 4.671 M Bytes/second
25-Jun 05:06 dbserver-dir JobId 5: Bacula dbserver-dir 5.2.5 (26Jan12):
Build OS: x86_64-pc-linux-gnu ubuntu 12.04
JobId: 5
Job: FTP_Backup.2013-06-25_05.03.07_03
Backup Level: Full
Client: "FTP Server" 5.2.5 (26Jan12) x86_64-pc-linux-gnu,ubuntu,12.04
FileSet: "Full Set" 2013-06-25 05:03:08
Pool: "Server" (From User input)
Catalog: "MyCatalog" (From Client resource)
Storage: "Server Backup" (From Pool resource)
Scheduled time: 25-Jun-2013 05:02:57
Start time: 25-Jun-2013 05:03:10
End time: 25-Jun-2013 05:06:45
Elapsed time: 3 mins 35 secs
Priority: 10
FD Files Written: 55,461
SD Files Written: 55,461
FD Bytes Written: 982,708,126 (982.7 MB)
SD Bytes Written: 990,268,085 (990.2 MB)
Rate: 4570.7 KB/s
Software Compression: None
VSS: no
Encryption: no
Accurate: no
Volume name(s): Server-1
Volume Session Id: 3
Volume Session Time: 1372163033
Last Volume Bytes: 992,591,109 (992.5 MB)
Non-fatal FD errors: 0
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Backup OK

25-Jun 05:06 dbserver-dir JobId 5: Begin pruning Jobs older than 6 months .
25-Jun 05:06 dbserver-dir JobId 5: No Jobs found to prune.
25-Jun 05:06 dbserver-dir JobId 5: Begin pruning Files.
25-Jun 05:06 dbserver-dir JobId 5: No Files found to prune.
25-Jun 05:06 dbserver-dir JobId 5: End auto prune.

*

입력을 해보니 벌써 전체 백업이 모두 끝났다.  여기서 가장 중요한 항목은 Termination: Backup OK인데, OK냐 아니냐에 따라서 이 job이 제대로 끝났는지 아닌지를 알 수 있기 때문이다.  위의 메시지를 자세히 읽어보면 별로 어려운 것이 없다.  총 기록된 용량이 얼마며 날짜(가상머신이라 날짜가 다른건 신경쓰지 말자), 파일셋 등 여러가지 정보를 보여준다.

이로서 백업실습이 끝났다.  참고로, 증분백업은 명령어

run job="FTP Backup" fileset="Full Set" client="FTP Server" storage="Server Backup" level="Full"

에서 

run job="FTP Backup" fileset="Full Set" client="FTP Server" storage="Server Backup" level="Incremental"

이라고 변경해주면 된다.  어떤 백업방식이 가능한지 알아보고 싶으신 분은 

run job="FTP Backup" fileset="Full Set" client="FTP Server" storage="Server Backup" level=

까지만 입력된 상태에서 Tab키를 입력하면 되겠다.

 

다음 편에서는 복원을 실습해보자.

 

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

이번 편에서는 설정의 최종판, 끝판왕 되시는 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으로 작동 중인지 확인해보자. 

 

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

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

9월 24일부터 27일까지 4일간 스위스 제네바에서 진행됐었던 마지막 백업 교육.


마지막날 Bacula Systems 독일지사에 근무하는 Arno Lehmann과 함께.





블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

설치를 해보자.  Bacula의 설치는 무척이나 간단하다.  먼저, 어떤 머신을 디렉터로 쓰고 어떤 머신을 스토리지로 쓸건지 정해야할텐데 설마 이 글을 보면서 현 업무에 바로 적용하실 분은 없을거라 가정하고, 일단 Bacula의 클라이언트가 될 머신들부터 설치를 하자.  글쓴이는 매뉴얼을 써야하므로 쉬운 이해를 위해 총 4대의 가상 컴퓨터를 운영한다고 들어가기편에서 미리 언급했다.  자세한 사항을 나열해본다.  참고로, 모든 가상머신용 운영체제는 우분투 12.04 64비트를 사용했으며, 루트 파티션으로는 8기가를, 램은 1기가를 할당했다.

상황을 가정해보자.  데스크탑 1, 웹서버 1, MySQL DB서버 1, FTP 서버 1.  총 4대의 머신이 있다.  다음의 조건을 정하도록 한다.

1. 4대 모두 백업되어야한다.
2. FTP 서버가 그나마 스토리지의 용량이 가장 커야할테니, FTP 서버를 스토리지 데몬으로 운영하도록 한다.  루트파티션용 하드디스크 외에 별도로 2개의 20기가짜리 가상 하드디스크를 더 붙인다.
3. 본 매뉴얼에서는 스토리지 데몬과 디렉터 데몬을 각기 다른 서버에 나눠서 운영하는 것으로 정했다.  현실적으로는 CPU의 부하가 덜한 FTP 서버에서 디렉터 데몬도 함께 돌려야겠지만, 여기서는 DB 설정의 편의상, DB서버에서 디렉터 데몬을 운영하게 한다.  디렉터 데몬용 가상머신을 한 대 더 올리려니 실습치고는 너무 복잡해보여서 수정했다.
4.  Bacula 백업을 위한 DB는 꼭 하나만 돌아갈 필요는 없다.  하지만 역시 마찬가지로 설정의 편의상 하나만 돌리며, 백업 규모가 수천대가 아니라면 하나로도 충분하다고 판단된다.  그리고 DB는 보안상, 그리고 성능상 실제 현업에서 운영 중인 DB 서버와는 별개로 운영하는 것이 맞겠지만, 경험상 디렉터 데몬과 디렉터 데몬이 사용할 DB가 서로 다른 곳에 있으면 성능상 좋지않았다.  또한 위에 적은 이유도 있고해서, DB는 디렉터 데몬이 설치될 곳에 설치한다.
5.  호스트명은 각각 desktop, webserver, dbserver 그리고 ftp라고 정한다.

정리해보자.
DB Server - 디렉터 데몬, 파일 데몬, MySQL 데이터베이스 서버
FTP Server - 파일 데몬, 스토리지 데몬, vsFTPd, 하드디스크 2개 추가
Web Server - 파일 데몬, Apache2
Desktop - 파일 데몬, 그외 데스크탑용 어플리케이션들 

나중에 fstab을 설정하는게 귀찮으신 분들께서는, FTP 머신 설정하기 전에 하드디스크 2개를 더 붙이고 이것들을 설치 과정에서 파티션을 생성하고 ext4로 포맷한뒤, 각각 /mnt/backup-1 그리고 /mnt/backup-2로 마운트 포인트를 주도록 하자.

 

일단 가장 쉬운 "클라이언트"부터 설치해보자.  서버-클라이언트의 개념으로 놓고보자면, 클라이언트의 역할을 하는 데몬은 파일데몬이다.  클라이언트용으로 필요한 패키지는 딱 2개이며,  bacula-common과 bacula-fd 이다.  설치는 아시다시피 뻔하다.  sudo apt-get install bacula-fd 이것만 쳐주면 bacula-common은 알아서 딸려온다.  위의 조건 #1에서, "4대 모두 백업되어야한다"고 했으니, 파일데몬 설치 명령어는 4대 모두 실시해야한다.  즉, 위의 설명대로 FTP 서버는 스토리지 데몬과 파일 데몬이 같이 돌아가는 것이고, DB서버는 디렉터 데몬과 파일데몬이 같이 돌아가게 되는 것이다.

용량이 크지않기 때문에 설치는 금방 끝난다.  설치가 끝났으면, 아무 가상머신에서 /etc/bacula/bacula-fd.conf 파일을 열어보도록 하자.  루트권한이 필요하다.  주석을 제외한 핵심만 보도록 하자.  글쓴이는 데스크탑에서 작업해보도록 한다.

Director {
  Name = desktop-dir 
  Password = "39oawhr8gQpsSDq3948tWwe4SdlED12LZ12" 
}

Director {
  Name = desktop-mon
  Password = "Jd904Kddfjw3932djv4Ldvn4234I3damz" 
  Monitor = yes


FileDaemon {
  Name = desktop-fd
  FDport = 9102
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /var/run/bacula
  Maximum Concurrent Jobs = 20
  FDAddress = 127.0.0.1
}

Messages {
  Name = Standard
  Director = desktop-dir = all, !skipped, !restored
}

이번에는 이걸 그림으로 표현한 것을 보자.

 

이 매뉴얼을 보시는 분들이라면 현업에서 이미 시스템 관리자로 일하시는 분들이 대부분일거라 짐작되며, 그렇지 않은 분들이라도 리눅스 쓰는데 익숙하신 분들이라면 위의 설정은 딱 보면 아마 다들 한 번에 이해하실 거다.  참고로, 동시에 백업 가능하도록 허용된 최대 백업은 20이라고 지정되어있다.  아마 이 옵션 필요하신 분들이 많을 것으로 생각한다.

일단 항목별 설명부터 드린다.  
첫번째 Director 섹션은, desktop-dir 이라고 되어있는데, 이 부분은 디렉터 데몬이 파일 데몬에게 접속을 요청할 때 패스워드를 인증하는 부분이다.  따라서, 디렉터 데몬을 위한 부분이다. 
두번째 섹션은, 자세히 보면 뒤에 -mon 이라는 글자가 붙어있는데, 예상하시는대로 모니터링용 섹션이다.  이 부분은 나중에 따로 설명드린다.  참고로 *거의* 사용하지 않는다.  하지만, 규모가 거대한 곳이라면 필요할 수도 있다.
세번째 섹션은 파일 데몬이 작동하는 부분이다.
마지막 네번째 Messages 섹션은 작업메시지를 처리하는 부분이다.  한 번만 설정하면 다시는 건드릴 일이 없다.

여기서 우리가 건드려야할 부분은 딱 2개다.  정말이다.  파일데몬 설정은 건드릴게 아예 없다고 봐도 될 정도다.  건드려야할 2개 중 하나는 디렉터 데몬의 이름인데, 데스크탑의 호스트명은 desktop이라고 하기로했고 따라서 자동으로 호스트명-dir이 붙은 것뿐이다.  desktop-dir을 본 매뉴얼에서 쓰기로 정한 디렉터 데몬 이름으로 바꿔주기만 하면 된다.  이 매뉴얼에서의 디렉터 데몬은 DB서버에 설치하기로 했고, DB서버의 이름은 위에서 편의상 dbserver라고 하기로 했다.  따라서, desktop-dir이라고 되어있는 이름을 dbserver-dir로 바꿔주고 저장한 다음, 파일데몬을 재시작해주자.  참고로, 이름은 중요하다.  Bacula는 모든 객체를 이름으로 구분한다.  bacula-fd.conf에 들어가는 디렉터 데몬의 이름과, 실제 디렉터 데몬의 이름은 반드시 같아야한다 (디렉터 데몬 부분에서 다시 설명드린다).  물론, 디렉터 데몬이나 파일데몬의 이름이 꼭 호스트명으로 이루어져야하는건 아니라는 점을 알아두자.  나머지 다른 하나는 FDAddress = 127.0.0.1이라는 디폴트값을 loopback이 아닌 FQDN이나 eth0 등의 실제 내/외부에서 지정된 IP 주소나 호스트명을 넣도록 한다.

sudo service bacula-fd restart

가상머신 4대 전부 위에서 했던 것들을 똑같이 해주되, Password는 변경 후 꼭 기억하고 있자.  나중에 해깔린다.  앞서 설명했듯 저 패스워드는 디렉터 데몬이 파일데몬과 통신하기 위한 인증암호인데, 파일데몬의 패스워드와 똑같은 패스워드를 디렉터 데몬이 갖고있어야 접속할 수 있다.  다시 말하자면, 디렉터 데몬은 자신이 접속할 클라이언트의 비번을 알아야 접속을 한다는 것이다.  정말 간단하지 않은가?  클라이언트는 이것으로 더 이상 손댈 게 없다.  한 가지 더 추가한다면, sudo netstat -ltnp를 입력해서 해당 포트가 해당 데몬에 의해 제대로 열려있는지 확인하는 정도는 해볼 수 있겠다.

$ sudo netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address     Foreign Address State      PID/Program name
tcp   0      0      127.0.0.1:9102    0.0.0.0:*       LISTEN     4760/bacula-fd
tcp   0      0      127.0.0.1:53      0.0.0.0:*       LISTEN     4980/dnsmasq
tcp   0      0      127.0.0.1:631     0.0.0.0:*       LISTEN     4980/cupsd

제대로 동작하고 있다.  그럼 이쯤에서 수정이 완료된 bacula-fd.conf 파일을 보자.  보시면 아시겠지만, Name이랑 FDAddress 빼고는 바뀐게 없다.  바뀐 부분은 붉은 색으로처리했다.

Director {
  Name = dbserver-dir 
  Password = "desktop
}

Director {
  Name = desktop-mon
  Password = "Jd904Kddfjw3932djv4Ldvn4234I3damz" 
  Monitor = yes


FileDaemon {
  Name = desktop-fd
  FDport = 9102
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /var/run/bacula
  Maximum Concurrent Jobs = 20
  FDAddress = 10.211.55.32
}

Messages {
  Name = Standard
  Director = dbserver-dir = all, !skipped, !restored
}

 

참고로 패스워드에 대한 추가설명을 해드리자면, 패스워드는 설치시 자동으로 생성되지만 특별한 규칙은 없다고 공식 매뉴얼에 기술되어있다.  따라서, 별도의 원하는 패스워드가 있으면 그것을 써도 무방하겠다.

 

 

이제 스토리지 데몬을 보자.  스토리지 데몬은 FTP 머신에 설치하기로 했으므로, FTP 머신으로 옮겨서 작업을 진행한다.  스토리지 데몬의 설치는 bacula-sd-mysql만 하면 된다.  파일데몬 설치하는 것만큼이나 쉽다.

$ sudo apt-get install bacula-fd bacula-sd-mysql

그림부터 보자.

 

파일데몬과 다른건 Device 섹션이 더 추가된 것 뿐이다.

예상하시는대로 설정파일은 /etc/bacula/bacula-sd.conf이며, 마찬가지로 루트권한이 필요하다.  기본적인 구조도 파일데몬과 거의 비슷한데, 먼저 디렉터 데몬의 이름과 패스워드를 위한 섹션, 모니터 섹션, 스토리지 데몬을 위한 섹션 (그래봐야 포트 번호랑 데몬 이름 말고는 다를 것도 없다), 그리고 각각의 저장장치에 대한 설정이 전부다.  데몬 설치 후 설정파일 열면 디렉터 데몬 이름 바꿔주는 거랑 저장장치 추가하는 거 외에는 특별히 할 일이 없다.  설정파일을 보자.  일단은 설명을 위해 설치하자마자 바로 생성된 파일을 수정없이 올린다.  마찬가지로 주석처리된 부분은 제외한다.

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


Director {
  Name = ftp-dir 
  Password = "29q48hfaFiuhfGq234908aHer" 
}

Director {
  Name = ftp-mon
  Password = "2309IOdf23D302jlsdfawerfcdf"
  Monitor = yes
}

Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /nonexistant/path/to/file/archive/dir
  LabelMedia = yes;
  Random Access = Yes;
  AutomaticMount = yes;
  RemovableMedia = no;
  AlwaysOpen = no;
}

…….. (생략)


Messages {
  Name = Standard
  director = ftp-dir = all
}

여기서 실제 파일의 Messages 섹션 위의 주석처리된 부분을 보면, 테이프 장치 및 여러가지 저장장치에 대한 옵션의 예제들이 주석처리되어있다.  자세히 보면 auto-changer도 보이고, Bacula에서 제공하는 mtx-changer 명령어도 보인다. 

첫번째로 할 일은 아마 다들 예상하시겠지만, 디렉터 데몬의 이름을 바꿔주는 거다.  위에서 언급했듯, 디렉터 데몬의 이름은 dbserver-dir이 될 예정이므로 ftp-dir이라고 적혀있는 부분을 dbserver-dir로 변경해주자.  두번째로는 SDAddress 항목에서 마찬가지로 loopback으로 두면 안되고, 내부 네트워크에서 사용하는 FQDN이 있으면 그것을 넣어주거나 아니면 IP Address를 지정해주자.  여기서는 10.211.55.34라는 주소를 사용한다.

세번째이자 마지막으로 할 일은 저장장치를 추가해주는 것이다.  테이프 백업장치가 없으신 분들이라면 아마 간단하게 끝내실 수 있을 것 같다.  일단 본 매뉴얼에서는 가상머신을 이용하기로 했고, 가상 테이프 백업장치를 이용한 설명은 추후 고급편에서 설명하도록 하겠다.  따라서, 10GB 용량의 하드디스크 2개를 더 생성해서 이것을 붙이도록 한다.  FTP용 가상머신에 설치하기로 했으므로, 가상머신을 옮겨서 설치하도록 한다.  편의상 이 둘을 각각 /mnt/backup-1, 그리고 /mnt/backup-2에 마운트 하고, 부팅시마다 자동으로 마운트하는 것으로 fstab을 수정해놨다고 가정한다 (아니면 설치시 미리 되어있거나).  일단 본 매뉴얼에서는 하드디스크를 이용한 백업만 하기로 결정했지만, 테이프 백업장치를 설정한다고 해도 제대로 구성되어진 설정이 주석처리되어있으므로 그것들의 주석만 풀어서 그냥 그대로 써도 된다 (이름 제외하고는 수정할 필요가 없다).  

만약 스토리지 데몬 자체의 이름을 따로 사용하고 싶으신 분은 Name 항목을 모두 바꿔주시면 되겠다.  주의사항은, ftp-sd를 FTPStorage-sd라고 바꾼다면, 모니터링 항목의 ftp-mon 역시 반드시 FTPStorage-mon 이라고 변경되어야하며, 스토리지 섹션에는 이름 뒤에 반드시 -sd가 붙어야하며, 모니터링 항목에는 반드시 뒤에 -mon이 붙어야하고, 마지막으로 이름에는 공란이 들어갈 경우 반드시 쌍따옴표로 묶어줘야한다.  하지만, 사실 이름은 전혀 중요하지 않다.  나중에 클라이언트들을 식별하기 위한 이름은 클라이언트가 아닌 디렉터 데몬에서 설정하기 때문이다.  따라서, 이름은 그냥 냅두도록 하자.  

하드디스크 백업장치의 지정은, 장치명을 지정해주는 것이 아니라 마운트 포인트를 지정해주는 것이라 상당히 편리하다.  한 하드디스크 내에서도 공간을 원하는대로 나눠서 쓸 수 있다는 장점이 되겠다.

그외, 동시에 여러개의 백업 작업이 실행되는 관계로 이것에 대한 속도저하 내지는 한 번에 실행되는 백업의 숫자를 제한하고 싶을 때 Maximum Concurrent Job 항목의 숫자를 조절해주면 된다.  이제 이쯤에서 완성된 bacula-sd.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 = "ftpserver
}

Director {
  Name = ftp-mon
  Password = "2309IOdf23D302jlsdfawerfcdf"
  Monitor = yes
}

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;
}


Messages {
  Name = Standard
  director = dbserver-dir = all
} 

 

참고로 테이프 백업 장치를 위한 항목을 올려드린다.  글쓴이의 사무실에서 사용하는 LTO-5 테잎 장치다.

Device {

  Name = Neo-200s

  Media Type = LTO-5

  Archive Device = /dev/nst0

  AutomaticMount = yes

  AlwaysOpen = yes

  RemovableMedia = yes

  RandomAccess = no

  Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"

  Changer Device = /dev/sg2

  AutoChanger = yes

  Alert Command = "sh -c 'smartctl -H -l error %c'"  

}

테이프 장치와 하드디스크의 차이점은, 일단 RemovableMedia, RandomAccess, Commands가 제공된다는점, 그리고 마운트 포인트가 아닌 장치명을 사용한다는 점이 되겠다.  사실, Changer command와 Alert Command 등의 Commands는 Bacula에서 이미 다 제공된다.

 

추가된 2개의 하드디스크를 위한 장치 섹션을 살펴보자.
Name = FileStorage-1: 장치의 이름을 정한다.  이 이름은 디렉터 데몬에서 반드시 매치되어야한다.  디렉터 데몬에서 다시 설명한다.
Media Type = File: 미디어의 타입은 두가지 뿐이다.  파일, 아니면 테이프(LTO-1, LTO-2, LTO-3, LTO-4, LTO-5)
Archive Device = /mnt/backup-1/bacula: 백업되는 파일이 저장될 곳을 의미한다. 여기서 우리는 추가 하드디스크를 지정한다.
LabelMedia = yes;: 미디어에 레이블을 한다.  보통은 테이프 장치에서 테이프의 레이블을 자동으로 인식한다. 하드디스크에 적용하면 자동으로 장치명을 레이블해준다. 세미콜론은 디폴트로 붙어나오는데, 매뉴얼에는 설명이 없다.
Random Access = Yes; 하드디스크일 경우는 yes이며, 테이프 장치는 no로 정한다.
AutomaticMount = yes; 백업작업마다 저장되는 장치가 다를 경우, Bacula가 자동으로 장치를 마운트 해준다 (테이프도 가능).
RemovableMedia = no; 제거 가능한 장치인지 지정해준다.  하드디스크라면 당연히 No다.
AlwaysOpen = no;   하드디스크라면 당연히 No이고, 테이프라면 yes를 줘도 된다.

 

다 됐으면 백업될 파일들(볼륨)이 저장되는 디렉토리를 생성하고 소유권을 변경해준다.
$ sudo mkdir /mnt/backup-1/bacula /mnt/backup-2/bacula
$ sudo chown bacula:bacula /mnt/backup-1/bacula /mnt/backup-2/bacula 

스토리지 데몬을 재시작해주자.
$ sudo service bacula-sd restart

솔직히 말해서 하나도 어려운 게 없다.  만약 뭐가 뭔지 모르시겠다면, 지금껏 대충 읽으신 거다.  차근차근 직접 따라하면서 하시면 상당히 쉽다는 것을 알 수 있을 거라고 확신한다.  본인도 역시, 처음에는 뭐가 뭔지 몰라서 해깔렸는데, 조금만 파보니까 눈에 쉽게 들어오더라.

이제 가장 중요하고 복잡한 디렉터 데몬을 설정해보자.  내용이 조금 해깔릴 수 있으며 설정이 아주 길다.

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

이번 편에서는 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의 서비스 데몬들을 설치해보도록 한다.

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

또 다른 매뉴얼 작성을 시작한다.  Bacula 라고하는 엔터프라이즈급 오픈소스 네트워크 백업 솔루션이다.  엔터프라이즈 라는 단어에서 오는 의미를 봐서, 개인용은 아니라는 것이 짐작되실 거다.  물론 개인용으로 써도 된다.  전혀 문제없다.

이걸 처음 써보고서는 오픈소스에 이 정도 성능의 솔루션이 한국에서 널리 알려지지 않은 것이 안타까워서, 본인 스스로가 이걸 좀 알려야겠다고 마음을 먹게되었다.  또한, 나는 Bacula Systems에서 주관하는 공인 교육인 Bacula Systems Administrator I과 II 교육을 모두 수료하여 Certified Backup Admin 인증서를 받았다.

한 가지 덧붙이자면, 본 매뉴얼은 Bacula Systems의 경영진 및 직원들에게 작성을 통보했었고, 사실 그들도 어느정도 관심있게 지켜보고 있다.  언어적인 문제일 수도 있겠지만, Bacula가 독일을 비롯한 유럽과 서양에서는 상당히 인기있는 반면 아시아에서는 언급은 커녕 이런게 있는지도 모르는 경우가 태반이기 때문이다.  이 매뉴얼을 시작으로 한국의 IT 시장에도 Bacula가 어느 정도 알려지길 바라는 기대가 어느정도 있어보인다.

본 매뉴얼을 시작하게 된 계기는, 이렇게 훌륭한, 그것도 오픈소스 솔루션을 모르는 분들이 생각보다 너무 많아서였다.  Bacula는 한 번도 들어본 적이 없었지만 처음 접하고나서는 완전히 반해버렸다.  너무나도 훌륭하고 이걸 집이건 어디건 내가 관리하는 컴퓨터라면 전부 이걸로 갈아엎고 싶을 정도다.  내가 일하는 곳이 미국이라서 오픈소스를 접하기가 쉽긴 하지만, 주립대학이 주정부기관의 한 부서이다보니 아무래도 비용을 최대한 줄일 수 있는 오픈소스만 고집하는 것이 진짜 오픈소스 솔루션을 쉽게 접할 수 있는 이유가 아닐까 싶다.

Big Blue Button이라고 하는 너무나도 훌륭한 영상/음성지원 실시간 프레젠테이션 솔루션에 대해서도 잠깐 언급을 해드린다.  정말 이것이 과연 오픈소스인가 할 정도로 좋고, 게다가 상당수의 교직원들이 우분투 리눅스를 사용하는 본인의 직장환경에서도 모든 기능이 100% 작동되었다.  윈도우, 리눅스, 그리고 맥까지 모두 작동되는 이런 훌륭한 오픈소스 프로그램들이 많은데, 이런 것들을 알지 못해서 못쓰는 상황이 많이 안타깝다.

이 매뉴얼에서 곧 다룰 Bacula라고 하는 백업 솔루션도 마찬가지로, 오픈소스이며 너무나도 잘 만들어져있고, 쉽고, 간편하다.  해외에서는 이미 커뮤니티 버전에 대한 유저들의 참여가 활발하며, Bacula를 만든 Bacula Systems의 CTO인 Kern Sibbald가 직접 메일링 리스트의 답변을 주기도 한다.  공식적으로 리눅스, 윈도우, 맥, 그리고 여러 유닉스를 지원하며, 그외 잘 쓰이지 않는 유닉스 유저의 경우는 소스가 오픈되어있기 때문에 소스를 가져다 설치하면 된다.  공식적으로 지원되는 클라이언트용 플랫폼으로는 리눅스, 솔라리스, Free/Net/OpenBSD, 윈도우, 맥, HP-UX, Tru64, Irix가 되겠다.  특히나 백업이라는 행위가, 모든 장소에 똑같은 방식이 적용하는 것이 불가능한 아주 다양한 상황에 대한 요구가 필요한 것인데 Bacula는 이런 요구를 모두 처리할 수 있는 기능을 갖추고 있다.

또한 Bacula는, "오픈소스로 돈을 버는" 한국에서는 다소 성공하기 어려운 형태의 비지니스 모델을 이뤄냈는데,
1. 오픈소스 솔루션을 개발해서 배포한다.
2. 유료로만 지원되는 플러그인 및 모듈, 기술지원, 그리고 전문교육
을 판매하는 형태로, Bacula Systems라고하는 회사가 별도로 존재한다.  따라서, bacula.org는 오픈소스의 커뮤니티 버전을, baculasystems.com 이라고 하는 엔터프라이즈 레벨의 상품을 판매하는 것이다.  Bacula는 2000년 1월에 처음 개발이 시작되어, 2002년 4월에서야 소스포지에 첫 버전이 올라왔고, 유료버전은 짝수이며 현재 버전 6까지 나와있다.

Bacula의 특징으로는 다음과 같다.

1.  쉬운 설치 및 쉬운 설정
2.  다양한 백업 장치 지원 (하드디스크, LTO 1-5 테이프 장치 등등)
3.  다양한 모니터링툴 지원
4.  증분, 차등, 차등 증분, 변경분, 가상백업, 백업 주기, 압축, 프로토콜 등 다양한 백업방식 지원
5.  원하는 경로 설정 및 백업 전후 실시할 명령어 지정 가능 
6.  네트워크로 백업되는 데이터의 암호화를 위한 다양한 옵션 (MD5, SHA, TLS, CRAM-MD5 등등)
7.  압축 

글쓴이가 근무하는 서버실 서버 중 대략 60대를 Bacula로 백업하고있는데, 사실 옵션이 아무리 많아도 쓰는건 한정되어있기 마련이다.  따라서, 본인의 상사께서 정해준 규정과 옵션으로만 운영하는 현재, 매일 하루에 한 번씩 이메일로 날라오는 백업 리포트를 읽는 것 외에는 백업에는 아예 신경을 안쓰고 근무할 정도로 편하고 쓰기쉬운 백업 솔루션이라고 말할 수 있다.  또한, 글쓴이의 서버실 규모가 작아서 그렇지, 교육에서 만났던 브라질에서 온 참가자의 경우는 1천대 가량 규모의 백업을 Bacula로 하고있다고 했다.  다른 참석자 중에서는 NASA에서 근무하는 System Admin도 있었다.

본 매뉴얼을 따라하기 위한 조건으로, 아래의 환경처럼 구성하고자 한다.  반드시 맞춰야할 필요는 없지만, "네트워크 백업 솔루션"인만큼 최소 2대의 컴퓨터가 있어야겠다.  다만, 반드시 필수적인 조건으로는, 본 매뉴얼을 따라하고자하는 분께서는 반드시 리눅스 터미널과 명령어 사용에 익숙해야하고, 네트워크에 대한 최소한의 개념은 이해하고 있어야한다는 점이다.  본인의 실습 조건이다.

1.  노트북
2.  가상화 프로그램 (Parallels 혹은 VMware)
3.  4대의 가상 컴퓨터
4.  글쓴이는 우분투 한국 로코팀 컨택터이므로, 가상 컴퓨터 4대의 운영체제는 모두 우분투 리눅스로 실시하며, 특별히 한 대는 데스크탑으로 한다.
5.  맥용 클라이언트 설치는 설명에서 제외한다.  일단, MacPorts에서 설치가 가능하고, 설정은 리눅스랑 100% 똑같다.
6.  윈도우용 클라이언트는 부득이하게 제외하기로 한다.  맥용 클라이언트와 마찬가지로, 설정은 리눅스랑 100% 같다.  참고로, 현재 윈도우용은 2012년 6월 28일자 버전인 5.2.10을 끝으로 무료버전은 개발이 중단됐다.  참고로, 최대 9대까지 쓸 수 있는 윈도우용 라이센스는 불과 1년에 $25 밖에 안한다.  1,000대 이상도 그래봐야 $600 밖에 안한다.기업용으로 이 정도 가격은 정말로 껌값이다.  무료 버전의 클라이언트는 현재 개발이 중단됐다는 점을 기억하자.
7.  백업 명령/복원 등의 실습은 CLI로 먼저 시작하고, CLI가 어느정도 익숙해지면 GUI를 진행한다.  사실 GUI를 사용하는 진짜 이유는, Bacula에서 화면에 출력되는 데이터가 횡으로 너무 길어서 CLI로 보면 상당히 불편하다.
8.  다양한 환경과 상황에서의 실습은 차후에 보여드릴 예정이다.  백업이라는 게 상황마다 조건마다 다들 판이하게 다르기 때문에 그것들을 일일히 다 실습해볼 수도 없거니와, 여러가지 상황에 대비한 옵션과 각각의 옵션에서 파생될 수 있는 결과 역시 수없이 많이 달라질 수 있기 때문에 개념을 설명하는 부분에서는 설명을 제외한다. 

이제 설치에 들어가보자.  가상 컴퓨터가 아닌 진짜 컴퓨터로 해도 상관은 없겠지만, 리눅스 설치에 시간이 좀 걸릴테니 미리 준비하실 분들은 우분투 설치부터 시작하시면 되겠다. 

다음 편으로...

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,

9월 10일부터 12일까지 총 3일간 진행됐던 Bacula Systems 사의 오픈소스 네트워크 백업 솔루션 공인 자격교육이 끝났다.

이로써 아마도 국내 첫 Bacula 공인 백업 어드민이 된듯 싶다.


 


 

블로그 이미지

jswlinux

Seowon Jung의 잡동사니 보관소

,