저장소 서버 업그레이드 기록

지난 주 후반 부에 사용 중인 Perforce/Subversion 서버가 올라가 있는 서버를 업그레이드 했다.

기존 시스템이 메모리가 부족해서(4GiB RAM on Windows Server 2003 R2; x86), 메모리를 증설하고(->8GiB), OS를 새 것으로(Windows Server 2008 R2; x64) 만드는 작업이 이루어졌다.

물론 이러다 저장소에 문제 생기면 말 그대로 망하는 거라, 일단 백업 작업이 진행;

  1. Perforce 서버 셧다운
  2. 전체 Perforce 서버 백업 (depot, journal, checkpoint …)
  3. 백업된 데이터 복사. 이건 외장 하드 디스크[1] 로.
  4. Subversion 저장소 전체를 hotcopy
  5. hotcopy된 저장소 네트웍 백업. (별도 HDD인지라 3과 동시 진행되었다)

이 후에 복구 작업 시작. 사실 저 백업은 최악의 경우를 상정하고 한 거라, 서버 업그레이드 / 재 설치 중에 별다른 문제는 없어서 1~5는 그냥 백업만 한 번 더 한 일이 되었지만(…).

Perforce 서버 재 설치 후, 저장소 디렉터리를 지정하고 실행하는데 서버가 안 뜬다? $P4ROOT 환경 변수 문제도 아니었음. Perforce 버전이 올라가서 저장소 업그레이드를 수행해야하는 문제였다. 업그레이드 후 서버 정상 동작.

Perforce 서버 주말 백업 스크립트 테스트. 안 돈다? 뭐가 문제인가… $P4PORT 환경 변수를 클라이언트 프로그램에서 요구하더군. 이거 설정하고 정상 동작 시작.

Subversion 서버 재 설치. Collabnet 에서 subversion 관련 바이너리만 배포하던게 없어졌더라; 그래서 collabnet edge 서버 설치하고, 거기 있는 svnserve.exe 바이너리만 이용하기로(…).

sc create 로 서비스 등록하고 서비스 시작. svn.conf 를 인식하지 않는다(…). SASL이 동작하지 않아서 그냥 구 버젼 바이너리 가지고 있던걸로(32bit 이긴하지만; 이쪽은 메모리 문제가 없었으니),

오늘 출근해보니 SVN은 주말 백업이 이루어지지 않았다. 아마도 퍼포스 백업 스크립트가 먼저 돌아야하는데, 이게 백업 완료 후 리붓해서 그런 듯. 순서 바꾸고 다음 주 테스트를 기다려야.

+ 근데 퍼포스 서버는 왜 죽었을까? 아무도 사용하지 않을 시간 대 인데;;;

  1. 네트워크 복사로는 안정적으로 초당 10메가 바이트 이상 전송한다고 해도 대략 17 시간에서 18시간 걸릴 양이라 []

Published by

rein

나는 ...

4 thoughts on “저장소 서버 업그레이드 기록”

    1. 정확한 이유는 알 수 없지만(…), 일단 제가 생각하는 이유는 다음과 같습니다.

      1. 자잘한 데이터 부터 대형 바이너리까지 파일 크기가 다양하고, 총량도 커서 원격 서버를 쓰면 동기화 / 전송 시간이 부담 됩니다.
      2. 보안. 여기는 심지어 개발 관련된 파일들은 외부 망과 물리적으로 단절되어 있습니다.
      3. 관리 편의; 이건 이견이 있을 수 있긴하지만, 서버 다운 타임을 직접 조절할 수 있는게 편합니다.

Leave a Reply