gitlab 백업

버전관리 시스템은 프로젝트에서 가장 중요한 인프라이므로 주기적으로 백업해야 한다. gitlab 은 자체적인 백업 기능을 제공하므로 cron 과 연동만 하면 손쉽게 프로젝트를 백업할 수 있다.

백업된 파일은 gitlab의 config.yml 에 지정된 패스 (기본적으로 /home/git/gitlab/tmp/backups/ 폴더이다) 에 타임스탬프_gitlab_backup.tar 형식의 파일로 생성된다.

cd /home/git/gitlab

sudo -u git -H bundle exec rake RAILS_ENV=production gitlab:backup:create
     
Dumping database ...
done
Dumping repositories ...
Dumping uploads ... 
Creating backup archive: 1387289435_gitlab_backup.tar ... done
Deleting tmp directories ... done
Deleting old backups ... skipping

 

위의 경우 1387289435_gitlab_backup.tar 란 이름으로 백업이 생성되었다.

이제 cron 과 연계하여 자동으로 백업을 수행해 보자.

  1. git 계정으로 cron 편집을 시작한다.

    sudo -u git crontab -e

  2. 편집기에서 다음 내용을 추가하고 저장한다.

    # 매일 오전 2시에 gitlab 저장소와 DBMS 의 풀 백업 실행
    0 2 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=production

     

  3. tmp/backups 내 파일을 확인하여 정상적으로 백업이 진행되고 있는지 확인한다.

 

gitlab 의 기본 설정은 백업시 기존 파일을 삭제하지 않는다. 이로 인해 백업 데이타가 너무 많아 질 수 있으므로 일정 기간이 지난 백업은 삭제하는게 좋다.

config/gitlab.yml 의 backup: 항목내 keep_time 에 기간을 초단위로 지정할 수 있다. 기본값은 0 이며 이 경우 삭제하지 않는다. 604800 으로 설정하면 일주일이 지난 백업 파일들은 삭제하게 된다


rsync 로 백업을 리모트에 복사

cron 으로 백업한 파일은 로컬 서버에 존재하게 된다. 혹시 운 나쁘게 서버와 디스크가 동시에 고장이 생기면 문제가 되므로 백업 파일을 원격지에 복사해 더 안심이 된다.
핵심 유틸리티에서 익힌 다음 rsync 명령어로 원격지 백업 서버에 복사본을 만들자. 사전에 백업 서버에는 git 이라는 계정을 생성해 두어야 한다.

 

rsync -avz /home/git/gitlab/tmp/backups git@backup.example.com:/home/git/gitlab/tmp/backups

 

위 명령어가 정상 동작한다면 cron 에 연결하여 원격지 복사를 자동화해 보자. 한 가지 주의할 점은 자동화하려면 암호 입력창이 뜨면 안 되므로 ssh 공개키를 원격지에 미리 복사해 놓아야 한다.

 

복구

복구시 가장 최근에 백업된 파일을 복구하게 된다. 다음 명령으로 복구할 수 있으며 백업 파일은 config에 설정된 경로에서 찾게 된다.

cd /home/git/gitlab
sudo -u git -H bundle exec rake RAILS_ENV=production gitlab:backup:restore

만약 특정 백업을 복구하려면 BACKUP 옵션에 파일의 타임스탬프를 명시하면 된다. 예로 위에서 백업된 파일명이 1387289435_gitlab_backup.tar 이며 이때 타임스탬프는 앞의 숫자인 1387289435 가 된다. 이 값을 BACUP 옵션에 넘기면 해당 시점으로 백업이 진행된다.

 

sudo -u git -H bundle exec rake RAILS_ENV=production gitlab:backup:restore BACUP=1387289435


Unpacking backup ... done
Restoring database ...
Restoring MySQL database gitlabhq_production ... [DONE]
Restoring repositories ...
Put GitLab hooks in repositories dirs [DONE]
Restoring uploads ...
This will rebuild an authorized_keys file.
You will lose any data stored in authorized_keys file.
Do you want to continue (yes/no)? yes
..Deleting tmp directories ... done

     

yes 를 누르면 복구가 진행되며 복구시 허용한 ssh 공개키 목록(authorized_keys)을 덮어 쓰게 되므로 authorized_keys 파일은 하나 복사해 놓는게 좋다.

복구후 gitlab 사이트에 로그인하여 프로젝트나 사용자등의 변경 내역이 최신 버전으로 반영되었는지 확인해 본다.

 

마치며

서브버전은 CVS 를 대치하기 위해 설계되었고 기존 CVS 사용자를 손쉽게 흡수할 수 있었으므로 오랫동안 주요 버전관리 서버로 사용되어 왔고 앞으로도 그럴 것이다.

그간 서브버전을 사용하면서 브랜치나 머지 기능에 아쉬움을 느낀 독자라면 git 도입도 적극적으로 검토해 보라고 권하고 싶다.

 

git 과 gitlab 은 굉장히 복잡하고 방대한 시스템이므로 본서에서는 기본적인 사용에 대해서만 간략하게 소개를 마쳤다. git 에 대해서 더 궁금한 독자는 git 관련 도서와 웹사이트를 참고하기 바라며 

gitlab은 기능과 UI 가 github 와 대부분 유사하게 만들어 졌으므로 github 사용자라면 쉽게 적응이 가능하다. 아직 gitlab 관련하여 자료가 충분하지 않고 또 gitlab 웹사이트내 문서도 그리 양이 많지 않지만 github 의 기능과 비교하면 익히면 손쉽게 사용할 수 있다. 

버전 관리 시스템으로 git 사용을 검토하고 있다면 gitlab 도 도입을 적극 검토해 보기를 권장하며 이 장을 마친다.