수백만 개의 하드 링크로 파일 시스템을 미러링하는 방법?

현재 한 가지 큰 문제가 있습니다. 고객 중 하나를 위해 파일 시스템을 미러링해야합니다. 그것은 실제로 실제로 문제가되지 않지만 여기에 있습니다 :

이 파일 시스템에는 수백만 개의 하드 링크가있는 하나의 폴더가 있습니다 (예! MILLIONS!). rsync파일 목록을 작성하는 데 4 일 이상이 소요됩니다.

우리는 다음과 같은 rsync옵션을 사용합니다 .

rsync -Havz --progress serverA:/data/cms /data/

누구 든지이 rsync의 속도를 높이거나 대안을 사용하는 방법을 알고 있습니까? dd대상 디스크가 소스보다 작기 때문에 사용할 수 없습니다 .

UPDATE : 원래의 파일 시스템이기 때문에 ext3우리는 노력할 것입니다 dump및 restore. 나는 당신을 최신 상태로 유지할 것입니다

— 토마스 버거
소스

교활한. 소스 파일 시스템을 먼저 축소 한 다음 dd?

— Bittrance

답변:

양쪽을 rsync 3으로 업그레이드해야합니다. 변경 로그에서 :

- A new incremental-recursion algorithm is now used when rsync is talking
  to another 3.x version.  This starts the transfer going more quickly
  (before all the files have been found), and requires much less memory.
  See the --recursive option in the manpage for some restrictions.

rsync 3.0.0이 출시 된 지 2 년이 지났지 만 안타깝게도 대부분의 엔터프라이즈 배포판은 그보다 오래된 코드를 기반으로하므로 아마도 rsync 2.6을 사용하고있을 것입니다.

당신이 경우 참조 (다른 사람이 문제가되는 경우)의 경우, 되어 이미 rsync에 3을 실행, 당신은 증가 재귀와 호환되지 않는 옵션을 사용하고 있습니다. 매뉴얼 페이지에서 :

    Some options require rsync to know the full file list, so  these
    options  disable the incremental recursion mode.  These include:
    --delete-before,   --delete-after,    --prune-empty-dirs,    and
    --delay-updates.

또한 증분 재귀를 지원하려면 양쪽 에서 rsync 3을 실행해야합니다.

— 스티븐 프 리처드
소스

Pritchard는 그 뒷부분에 대해 감사하지만 점진적인 부분은 문제가 없으며 양쪽 모두 rsync> 3.0을 사용합니다. -H없이 rsync를 사용하면 속도가 크게 향상되지만 필요한 것은 아닙니다.

— Thomas Berger

아야. 예,이 경우 파일 시스템 액세스 속도를 높이는 옵션 (ext3을 사용하는 경우 ext4로 전환), 더 빠른 디스크 또는 RAID 레벨로 전환 (옵션 인 경우) 등의 옵션을 살펴볼 수 있습니다. 파일 시스템이 충분히 빠르지 않고 블록 수준 백업이 유일한 옵션 일 수있는 시점에있을 수 있습니다. 이 문제는 한 서버에서 다른 서버로 BackupPC 풀을 재 동기화하려고 시도했습니다.

— Steven Pritchard

우리는 지금 ext * dump를 사용했습니다. 잘 작동하며 복원 측면도 ext * 일 필요는 없습니다.

장치를 마운트 해제하고 사용하여 오프라인 백업을 수행했습니다 dump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gz.

마지막 줄은 크기, 시간, 속도 및 마지막 inode 수를 나타냅니다.

DUMP: dumping regular inode 47169535
DUMP: dumping regular inode 47169536
DUMP: Volume 1 completed at: Wed Jun 29 05:42:57 2011
DUMP: Volume 1 54393520 blocks (53118.67MB)
DUMP: Volume 1 took 4:16:43
DUMP: Volume 1 transfer rate: 3531 kB/s
DUMP: 54393520 blocks (53118.67MB)
DUMP: finished in 15403 seconds, throughput 3531 kBytes/sec
DUMP: Date of this level  dump: Wed Jun 29 01:24:29 2011
DUMP: Date this dump completed:  Wed Jun 29 05:42:57 2011
DUMP: Average transfer rate: 3531 kB/s
DUMP: DUMP IS DONE

— 토마스 버거
소스

이것이 여전히 사실인지는 모르겠지만 덤프시 파일 시스템이 사용 중이면 덤프에 문제가 발생했습니다. 당신의 목표는 속도이기 때문에 나는 당신이 이미 다른 모든 액세스를 사용할 수 있지만, 그냥의 경우 한 가정 .. 우리는 당신이가는 방법을 알려주세요

— SuperBOB

LVM을 사용하고 볼륨의 스냅 샷을 만든 다음 스냅 샷을 백업으로 재 동기화 할 수 있습니다.

또는이 dump 볼륨을 다른 응답과 결합 하여 스냅 샷 볼륨 에서 사용 하여 원래 볼륨을 오프라인으로 만들지 않아도됩니다.

— 테디
소스

파일 시스템 수준이 아닌 블록 수준에서 작동하는 것은 아마도 크게 개선되었을 것입니다.

— Marcin

내 질문에서 볼 수 있듯이 로컬이 아닌 네트워크를 통해 미러링해야합니다. 또한 LVM은 미러가 아니며 스냅 샷이라고합니다.

— 토마스 버거

@ 토마스 버거 : 내 생각은 네트워크를 통해 (rsync를 사용하여) 스냅 샷을 복사 할 것이라고 생각했습니다. LVM 스냅 샷이 아닌 경우 어떻게 정확하게 mirror 를 정의 합니까?

— Teddy

여전히 같은 문제가 있습니다. 며칠이 걸릴 것입니다. 요즘에는 거대한 달 타가 필요하기 때문에 (필요한 것은 아님) 충분한 공간을 다시 확보해야하며 그 공간이 없습니다. 그리고 거울은 독립적 인 소스의 사본입니다. 고객을 위해 생산에서 개발로 데이터를 복사해야합니다.

— 토마스 버거

@Thomas Berger : 원래는 스냅 샷 의 파일 시스템이 아니라 실제 스냅 샷 볼륨을 재 동기화한다는 의미 였습니다. 그러나 이제 Snapshot + dump 솔루션이 더 낫다고 생각합니다.

— Teddy