복잡해

아스팔트

ssh root@main_server "tar czf - /DB_TABLES" |tar xzf - -C /bck

( z이전 댓글 f에서도 지적 하고 f -추출했습니다 tar)

원격에서 main_server로컬 /bck디렉터리로 파일을 전송하는 경우, /DB_TABLES파일이 작지 않기 때문에 전송이 완료될 때 일부 파일이 변경되어 /bck끊김이 발생할 수 있습니다.

동기화

rsync --archive --verbose --relative --delete root@main_server:/DB_TABLES/ /bck

약간 더 나은 점은 rsync파일이 양쪽에서 수집된 다음 새 파일이나 변경된 파일이 전송된다는 것입니다. 모든 파일은 처음으로 rsync전송됩니다 . 그 후에는 더 작은 볼륨이 전송되기를 바라지만, 수집 단계 이후에 파일이 변경되면 파일이 /DB_TABLES손실됩니다(예: 전송되지 않음).

작은 파일이 많으면 병렬로 실행할 수 있습니다. (1)

rsync --archive --verbose --relative --delete root@main_server:/DB_TABLES/dir1/ /bck
rsync --archive --verbose --relative --delete root@main_server:/DB_TABLES/dir2/ /bck
(...)

(1) 올바른 구문을 보장할 수 없습니다.

데이터 베이스

/DB_TABLES전송 중에 파일이 변경되지 않도록 해야 합니다 ( ssh+tar둘 중 하나 rsync). 이것이 가능하다면(예: 데이터베이스를 중지하여) 두 가지 솔루션 중 하나가 작동할 것입니다( rsync장기적으로는 더 빠를 것입니다).

rsync데이터베이스를 중지/정지하는 데 걸리는 시간을 확인하기 위해 소요되는 시간을 보정할 수 있습니다 .

데이터베이스를 중지할 수 없는 경우 제공된 경우 원격 동기화 메커니즘(로그 전달, 슬레이브)을 사용하십시오.

송곳

비용이 많이 들지만 효과적인 해결책은 실제로 데이터를 복구해 보는 것입니다(예: 로컬 복사본을 만들고 가장 최근에 삽입된 레코드를 검색하는 것). 여기에는 많은 자원과 인력이 필요하며 실제로 생산을 중단하는 하나 이상의 데이터베이스가 포함될 수도 있습니다. 이상적으로는 이 테스트를 매년/분기별로 수행해야 합니다.

(원격 서버에) 충분한 공간이 있는 경우 먼저 무언가를 통해 보관할 수 있습니다(예: x, mycopy.x와 같은 항목 생성, ssh를 통해 시작). 그런 다음 rsync를 사용하여 mycopy를 전송할 수도 있습니다
. --append를 사용할 수도 있습니다. , 트래픽을 약 2/3 정도(약 100x/1000x 더 빠르게) 줄일 수 있으므로(예: 매일 여러 번 실행) 어느 것을 직접 검색해 보세요.
SSH 비밀번호로 로그인하세요(경로 조정!). 여기 스니펫이 있습니다.

ssh [email protected] "/bin/x a /tmp/mycopy.x /DB_TABLES"

또는 RSA 키를 사용하십시오(이 예에서는 기본 포트 22).

/bin/ssh -p 22 -i /root/mysshkey [email protected] /bin/x a /tmp/mycopy.x /DB_TABLES  

고대/공용 아카이빙 프로그램(tar, 7z, zip, rar 등)을 사용하면 매번 모든 데이터를 전송해야 하며(또는 최소한 철저한 확인을 해야 함) 아래와 같이 데이터 복사본 하나만 유지해야 합니다. 이 케이스 키는 로그인할 때 비밀번호를 입력하세요).

rsync -avr [email protected]:/tmp/mycopy.x /temporaneo/dedup/mylocal

또는 (표준 포트 22를 통해 RSA 키 사용)

/bin/rsync -I -vv   --omit-dir-times --no-owner --no-perms --partial --progress -e "/bin/ssh -p 22 -i /root/mysshkey"  -rlt  --delete "[email protected]:/tmp/mycopy.x" "/temporaneo/dedup/mylocal"

zfs 파일 시스템을 사용하는 경우 스냅샷을 찍은 다음 복사본을 만들 수 있지만(zfs-over-ssh) 유감스럽게도 귀하의 경우는 그렇지 않습니다.

편집/2: 어떤 종류의 문제를 피하기 위해 어떤 소프트웨어가 이 상황(대규모 데이터베이스 백업의 WAN 전송)에 적합한지 지적하지 않겠습니다. 비록 그것이 무엇인지는 이해하지 못하지만요.
이 작업을 수행할 수 있는 소프트웨어를 아는 사람이 있으면 알려주시기 바랍니다.
수천 개의 오픈 소스 프로젝트가 있으며 물론 모두 알고 있다고 주장할 수는 없습니다.