Jak wykonać kopię lustrzaną systemów plików za pomocą milionów linków?


11

W tej chwili mamy jeden duży problem: musimy wykonać kopię lustrzaną systemu plików dla jednego z naszych klientów. To zwykle nie jest problem, ale oto:

W tym systemie plików jest jeden folder z milionami dowiązań twardych (tak! MILIONÓW!). rsyncdo zbudowania listy plików potrzeba więcej niż 4 dni.

Korzystamy z następujących rsyncopcji:

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

Czy ktoś ma pomysł, jak przyspieszyć ten rsync lub skorzystać z alternatyw? Nie mogliśmy użyć, ddponieważ dysk docelowy jest mniejszy niż źródło.

AKTUALIZACJA: Ponieważ oryginalny system plików jest ext3, spróbujemy dumpi restore. Będę cię aktualizować


Zdradliwy. Najpierw zmniejsz źródłowy system plików, a następnie dd?
Bittrance

Odpowiedzi:


3

Musisz zaktualizować obie strony do rsync 3. Z dziennika zmian:

- 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.

Minęły ponad 2 lata od wydania rsync 3.0.0, ale niestety większość dystrybucji korporacyjnych oparta jest na kodzie starszym niż ten, co oznacza, że ​​prawdopodobnie używasz rsync 2.6.

Dla odniesienia (jeśli ktoś ma ten problem), jeśli uruchomione już rsync 3, a następnie używasz opcji, które są niezgodne z bieżących rekursji. Ze strony podręcznika:

    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.

Ponownie, obie strony muszą uruchomić rsync 3, aby można było obsługiwać przyrostową rekurencję.


Pritchard dziękuję ci za to, ale części przyrostowe nie stanowią problemu, obie strony używają rsync> 3.0. Jeśli użyjemy rsync bez -H, mamy wielką poprawę prędkości, ale nie tego potrzebujemy.
Thomas Berger,

Auć. Tak, w takim przypadku możesz zajrzeć do opcji, aby przyspieszyć dostęp do systemu plików (np. Przejście na ext4, jeśli używasz ext3), przejście na szybsze dyski lub poziomy RAID (jeśli to nawet opcja) itp. Niestety, może być w punkcie, w którym system plików po prostu nie może być wystarczająco szybki, a kopie zapasowe na poziomie bloku mogą być Twoją jedyną opcją. Miałem ten problem podczas próby synchronizacji puli BackupPC z jednego serwera na drugi.
Steven Pritchard

3

Użyliśmy teraz zrzutu * ext. Działa dobrze, a strona przywracania nie musi nawet być rozszerzona *.

Zrobiliśmy kopię zapasową offline, podłączając urządzenie i wykorzystując dump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gz.

Oto ostatnie linie, które można zobaczyć rozmiar, czas, prędkość i ostatnie numery i-węzłów:

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

Nie wiem, czy nadal jest to prawdą, ale zrzut miał pewne problemy, jeśli system plików był używany w momencie zrzutu. Ponieważ twoim celem jest szybkość, przypuszczam, że już wyłączyłeś dostęp do niego, ale na wszelki wypadek. Daj nam znać, jak idziesz
SuperBOB

0

Możesz użyć LVM i zrobić migawki woluminu, a następnie zsynchronizować migawkę jako kopię zapasową.

Alternatywnie możesz połączyć to z inną odpowiedzią i użyć dump na woluminie migawki , aby uniknąć konieczności przełączania oryginalnego woluminu w tryb offline.


Wszystko, co działa na poziomie bloku, a nie systemu plików, byłoby prawdopodobnie ogromną poprawą.
Marcin

Jak widać w moim pytaniu, muszę wykonywać kopię lustrzaną w sieci, a nie lokalnie. Również LVM NIE jest lustrem, to po prostu, jak powiedziałeś, migawka.
Thomas Berger

1
@Thomas Berger: Myślałem, że skopiujesz migawkę (używając rsync) przez sieć. Jak dokładnie definiujesz lustro , jeśli migawka LVM nie jest nim?
Teddy

To wciąż ma ten sam problem: zajęłoby to kilka dni. W dzisiejszych czasach istniałaby ogromna dalta (nie żebyśmy tego potrzebowali), więc musimy ponownie zarezerwować wystarczająco dużo miejsca i nie mamy tego miejsca. A lustro jest niezależną kopią źródła. Musimy skopiować dane z produkcji do opracowania dla klienta.
Thomas Berger

@Thomas Berger: Pierwotnie miałem na myśli, że zsynchronizujesz rzeczywisty wolumin migawki, a nie system plików na migawce. Jednak teraz uważam, że rozwiązanie snapshot + zrzut jest lepsze.
Teddy
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.