rsync 또는 git push-웹 사이트 백업에 더 나은 방법

재난 복구를 위해 여러 공급 업체에서 2 개의 LAMP 웹 서버 (고성능 라이브 서버 및 저전력 백업 서버)을 실행합니다.

현재 4 시간마다 한 번씩 라이브 서버에서 백업 서버로 모든 데이터를 재 동기화합니다.

이것은 잘 작동하지만 rsync는 어떤 파일이 변경되었는지 파악하는 동안 시스템로드를 급격히 증가시킵니다.

모든 웹 사이트가 git 저장소에 있기 때문에 git push가 더 나은 백업 기술인지 궁금합니다.

git repo에 라이브 업로드 폴더를 포함시켜야합니다. 백업 프로세스는 다음과 같습니다.

live$ git add .
live$ git commit -a -m "{data-time} snapshot"
live$ git push backup live_branch

그런 다음 백업 서버에 포스트 커밋 후크를 설정하여 푸시 할 때마다 체크 아웃합니다.

각 웹 사이트의 크기는 50M에서 2GB입니다. 약 50 개의 별도 git repos로 끝났습니다.

이것이 rsync보다 "더 나은"솔루션입니까?

• 어떤 파일이 변경되었는지 계산하는 것이 더 좋습니까?
• git push가 rsync보다 효율적입니까?
• 내가 무엇을 잊었습니까?

감사!

---- 일부 비교 테스트의 데이터 ------

1) 52MB 폴더 다음에 새로운 500k 폴더 추가 (주로 텍스트 파일)

rsync

sent 1.47K bytes  received 285.91K bytes  
total size is 44.03M  speedup is 153.22

real    0m0.718s    user    0m0.044s    sys     0m0.084s

자식

Counting objects: 38, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (37/37), done.
Writing objects: 100% (37/37), 118.47 KiB, done.
Total 37 (delta 3), reused 0 (delta 0)

real    0m0.074s     user   0m0.029s    sys     0m0.045s

2) 1.4G 폴더 다음 새 18M 폴더 추가 (주로 이미지)

rsync

sent 3.65K bytes  received 18.90M bytes
total size is 1.42G  speedup is 75.17

real    0m5.311s    user    0m0.784s    sys     0m0.328s

자식

Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.21 MiB/s, done.
Total 107 (delta 0), reused 0 (delta 0)

real    0m15.334s    user   0m5.202s    sys     0m1.040s

3) 52M 폴더 다음에 새로운 18M 폴더 추가 (주로 이미지)

rsync

sent 2.46K bytes  received 18.27M bytes  4.06M bytes/sec
total size is 62.38M  speedup is 3.41

real    0m4.124s    user    0m0.640s    sys     0m0.188s

자식

Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.43 MiB/s, done.
Total 107 (delta 1), reused 0 (delta 0)

real    0m6.990s    user    0m4.868s    sys     0m0.573s

4) 1.4G 폴더 다음에 새로운 500k 폴더 추가 (주로 텍스트)

rsync

sent 2.66K bytes  received 916.04K bytes  612.47K bytes/sec
total size is 1.42G  speedup is 1547.14

real    0m1.191s    user    0m0.180s    sys     0m0.268s

자식

Counting objects: 49, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (48/48), done.
Writing objects: 100% (48/48), 177.90 KiB, done.
Total 48 (delta 3), reused 0 (delta 0)

real    0m1.776s    user    0m0.390s    sys     0m0.497s

5) 1.4G 폴더-변경 사항 없음

rsync

sent 1.72K bytes  received 716.44K bytes  287.26K bytes/sec
total size is 1.42G  speedup is 1979.18

real    0m1.092s    user    0m0.168s    sys     0m0.272s

자식

nothing to commit (working directory clean)

real    0m0.636s    user    0m0.268s    sys     0m0.348s

5) 52M 폴더-변경 사항 없음

rsync

sent 528 bytes  received 88.40K bytes  59.29K bytes/sec
total size is 62.38M  speedup is 701.41

real    0m0.779s    user    0m0.044s    sys     0m0.144s

자식

nothing to commit (working directory clean)

real    0m0.156s    user    0m0.057s    sys     0m0.097s

실제로 나는 균형 잡힌 혼합을 사용하는 것이 좋습니다. 메인 백업은 적어도 매일 밤 git에 커밋되어야합니다. rsync를 사용하여 일주일에 한 번 또는 두 번 다른 시스템과 동기화하여 생산 상자에서 멀리 떨어진 다른 시스템과 동기화하십시오.

Git은 즉각적인 복구에 도움이되며 백업 버전이 변경되고 변경 로그가 있기 때문에 데이터 분석이 더 쉬워집니다. 데이터를 크게 변경 한 후에는 커밋을 수행하고 수동으로 git을 푸시하여 이유를 changelog에 넣을 수 있습니다. git이 잘못되면 rsync가 구조에 올 것입니다. 그러나 rsync의 빈도에 따라 여전히 데이터가 느슨해집니다.

일반적으로 백업 및 재해 복구와 관련하여 100 % 복구를 보장 할 수있는 것은 없습니다.

Rsync는 훌륭한 동기화 도구이지만 서버에서 Git을 실행하고 업데이트 push를 ing 또는 pulling 할 때 훨씬 더 다양한 기능을 제공합니다.

서버에서 사용자 생성 컨텐츠를 추적하고 백업해야합니다. production서버는 자식의 repo의 복사본을 가지고 있으며, 매일 밤 자동으로 추가하고 크론을 통해 새로운 파일을 모두 커밋합니다. 이것들은 push우리의 gitolite 서버에 연결되며 후크를 사용하여 나머지 서버를 동기화합니다.

서버에는 온보드 리포지토리 사본이 있으므로 스냅 샷뿐만 아니라 서버에 문제가 발생했을 때 쉽게 저장할 수있는 자세한 기록 정보가 제공됩니다.

두 제품이 무엇을 제공하는지 잘 알고 있다고 생각합니다. 코드베이스를 체크 아웃 / 내보내기하는 서버에서 자체 저장소를 사용하는 것으로 생각의 선을 바꾸고 싶습니다. 또 다른 생각은 미디어 파일을 재 동기화 할 수 있다는 것입니다 (이 사이트 중 일부에 대해 2GB라고 말하면 미디어 유형의 파일이 많이 있다고 생각합니까?). Git에서 추적 할 수는 없습니다.