Subversion 백업을 수행하는 가장 좋은 방법은 무엇입니까?


10

데비안 기반 서버에서 Subversion 백업을 수행하는 가장 좋은 방법은 무엇입니까?

svnadmin을 사용해야합니까?

svnadmin dump /path/to/reponame > reponame.dump

아니면 리포지토리가있는 디렉토리를 tar하는 것입니까?

tar -cvzf svn.backup.tar.gz /var/subversion/

위의 장단점은 무엇입니까?

감사합니다 요한


업데이트 :이 서버는 소수의 저장소 만있는 작은 서버입니다. 따라서 증분 백업은 필요하지 않을 것이므로 간단하게 유지하는 데 집중하는 것이 좋습니다.

업데이트 : 팩 래퍼 스크립트 (Svn-hot-backup의 래퍼였습니다)를 사용하여 전체 백업을 수행 한 다음 다른 깨끗한 컴퓨터에서 전체 복구를 수행했습니다. 그러나 "SVN_HOTBACKUP_NUM_BACKUPS = 10"부분이 작동하지 않아서 제거했습니다.

나는 그것이 일종의 단순하다고 생각하고 그 결과는 단지 dir tar에 매우 가깝습니다. 그러나 Manni가 svn-hot-backup / "svnadmin hotcopy"를 사용하기 위해 여기에서 지적한 것처럼 tar는 운이 좋지 않으면 때때로 손상된 백업을 생성 할 수 있기 때문에보다 안정적인 방법입니다.

답변:


11

svn-hot-backup 스크립트를 찾으십시오. Subversion과 함께 제공되며 원하는 백업을 수행 할 수있는 모든 논리와 이전 백업에서 자동 롤아웃을 포함합니다. svn-hot-backup을 사용하여 야간 저장소로 실행하여 여러 저장소가있는 단일 서버를 백업하고 일반화되도록 약간 수정 한 다음 래퍼 스크립트를 작성했습니다.

#!/bin/bash

#
# Dumps the svn repos to a file and backs it up
# to a local directory.

#Keeps the last 10 revisions
REPODIR="/var/repos"
BAKDIR="/data/backup/svn"
PROG="/usr/local/sbin/svn-hot-backup"
REPOLIST='repo1 repo2 repo3'

if [ ! -x "${PROG}" ]
then
        echo "svnbak: Could not execute \`${PROG}\`"
        exit 1
fi

for repo in ${REPOLIST}
do
    # Dump the database to a backup file
    echo "svnbak: Dumping subversion repository:  ${repo}"
    SVN_HOTBACKUP_NUM_BACKUPS=10 nice ${PROG} --archive-type=gz ${REPODIR}/${repo} ${BAKDIR}/${repo} &> /tmp/svnbak.$$

    if [ "$?" -eq "1" ]
    then
        echo "svnbak: Hot backup on '${repo}' failed with message:"
        /bin/cat /tmp/svnbak.$$
    fi

    /bin/rm /tmp/svnbak.$$
done

exit 0

1
그리고 이것은 svnadmin hotcopy의 래퍼이므로 복구하려면 / var / subversion / repos /? 아래에 파일을 복사하십시오. 다른 것을해야합니까?
Johan

'svnadmin verify'는 방금 복사 한 저장소가 실제로 유효한지 확인하기 위해 스크립트에 추가 된 것입니다.
Andrioid

@Johan-예, 그냥 복사하십시오. "결과 백업은 완전한 기능을 갖춘 Subversion 저장소이며, 문제가 발생할 경우 라이브 저장소를 대체 할 수 있습니다." 에서 svnbook.red-bean.com/nightly/en/...
Jonik

find 명령을 사용하여 이전 N 일 이내에 변경된 리포지토리를 검색 할 수도 있습니다. find 명령의 출력에서 ​​'db / current'를 검색하십시오. 이는 해당 REPOLIST 변수를 지속적으로 업데이트 할 필요가 없다는 장점이 있습니다. 또한 SVN 1.8에서는 더 이상 빈 대상으로 핫 카피 할 필요가 없지만 이전 핫 카피에 추가 할 수 있습니다. 이렇게하면 핫 카피 백업 속도가 2-3 배 빨라질 수 있습니다.
tgharold

9

이것에 대한 문서 를 보셨습니까 ?

기본적으로 두 가지 옵션이 있습니다.

  1. 다음을 사용하여 증분 백업 수행 svnadmin dump
  2. 다음을 사용하여 전체 저장소를 백업하십시오. svnadmin hotcopy

복사 하는 동안 리포지토리가 변경 될 수 있으므로 단순히 디렉터리의 복사본을 만드는 것은 옵션 이 아닙니다 .

증분 백업 또는 전체 백업에 있는지 여부는 편집증의 양, 저장소의 크기, 요구 사항 및 인프라에 따라 다릅니다.


4

증분 백업 을 수행 할 수 있기 때문에 SVNBackup을 권장 합니다.

이것이 왜 중요한가? 대규모 개발 팀이 있고 매일 Subversion 백업이 있고 시스템이 이전 백업으로 12 시간 동안 실패하면 하루 종일 작업이 손실됩니다.

하루에 여러 번 전체 백업 ( SVN 핫 카피 )을 수행하면 리포지토리 시스템에 불필요하게로드가 발생하여 성급한 개발자를 자극 할 수 있습니다.

보너스로; 또한 Backup-PC 를 백업 솔루션으로 권장 합니다. 증분 원격 백업을 수행 할 수 있으며 다른 시스템에서 동일한 파일을 백업하는 경우 많은 공간을 절약 할 수 있습니다.


4

svnsync를 사용하여 읽기 전용 저장소에 백업합니다.이 저장소는 자체적으로 오래된 사본 (일, 주, 월)으로 백업됩니다.



매뉴얼에서 "그리고이를 수행하는 방법은 거의 없지만, 가장 큰 장점은 원격으로 작동 할 수 있다는 것입니다."
Johan

svnsync를 언급 한 +1-like dumphotcopy그 용도가 있습니다. 로컬 증분 백업에도 매우 유용 할 수 있습니다.
Jonik

백업 서버가 다른 위치에있는 경우, 당신은 하나의 단계에서 복구 많은 사건을 해결
잭 톰슨

1
svnsync 경로를 사용하려는 경우 두 가지 : 1) svnadmin 핫 카피로 시작하는 큰 저장소가있는 경우 훨씬 빠르며 / db / revs 이상의 데이터를 백업하므로 2) svnsync 호출을 소스 저장소에 추가하십시오. 미러가 항상 최신 상태가되도록 커밋 후 후크. (그러나 거울의 고리에 닿지 않게하여 거울 자체가 거울에 닿지 않도록하십시오!)
Robert Calhoun

2

원하는 경우 svnadmin을 사용하여 증분 백업을 만들 수 있습니다 . tar 아카이브를 만들기 전에 hot-backup.py를 실행해야합니다 .

다음은 svn repos 백업에 관한 기사 입니다. 어쨌든 SVN 책을 읽는 것이 이전에 말한 것처럼 좋은 출발점입니다.


0

일반 오래된 rsync로 여러 100GB + svn 저장소를 백업합니다. svnadmin dump그리고 svnadmin hotcopy이 저장소에 며칠이 걸릴 것입니다.

주의해야 할 또 다른 사항은 svnadmin dump백업 잠금 및 후크 스크립트가 아닙니다.


-1

내 저장소로 수행하는 작업은 다음과 같습니다. Dropbox와 같은 폴더 백업 서비스를 사용하십시오 (여기서 Linux 버전 링크 ). Dropbox를 리포지토리의 루트 (또는 그 위)로 ​​만들면 파일이 변경 될 때마다 백업됩니다. 여러 컴퓨터에서 사용할 수있을뿐만 아니라 온라인으로 액세스하여 해당 버전을 사용할 수 있습니다.

이러한 온라인 백업 서비스는 여러 가지가 있으며 대부분 2GB까지 무료입니다.


1
이것은 작은 개인 저장소에 대해서는 좋지만 포스터가 찾고있는 "가장 좋은 방법"은 아닙니다. 한 가지 문제는 여러 개발자의 동시 액세스와 일관성을 보장 할 수 없다는 것입니다. 백업의 주요 목표는 온라인 액세스 및 버전 대신 안정성과 일관성이어야합니다.
Martijn Heemels
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.