백업과 복구
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 과 연계하여 자동으로 백업을 수행해 보자.
git 계정으로 cron 편집을 시작한다.
sudo -u git crontab -e
편집기에서 다음 내용을 추가하고 저장한다.
# 매일 오전 2시에 gitlab 저장소와 DBMS 의 풀 백업 실행
0 2 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=productiontmp/backups 내 파일을 확인하여 정상적으로 백업이 진행되고 있는지 확인한다.
gitlab 의 기본 설정은 백업시 기존 파일을 삭제하지 않는다. 이로 인해 백업 데이타가 너무 많아 질 수 있으므로 일정 기간이 지난 백업은 삭제하는게 좋다.
config/gitlab.yml 의 backup: 항목내 keep_time 에 기간을 초단위로 지정할 수 있다. 기본값은 0 이며 이 경우 삭제하지 않는다. 604800 으로 설정하면 일주일이 지난 백업 파일들은 삭제하게 된다
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 도 도입을 적극 검토해 보기를 권장하며 이 장을 마친다.