Bagaimana cara mirror filesystem dengan jutaan hardlink?

Kami memiliki satu masalah besar saat ini: Kami perlu mirror sistem file untuk salah satu pelanggan kami. Itu biasanya bukan masalah, tapi ini dia:

Pada sistem file ini ada satu folder dengan jutaan hardlink (ya! JUTAAN!). rsyncmembutuhkan lebih dari 4 hari untuk membangun filelist.

Kami menggunakan rsyncopsi berikut :

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

Adakah yang tahu cara mempercepat rsync ini, atau menggunakan alternatif? Kami tidak dapat menggunakan ddkarena disk target lebih kecil dari sumbernya.

UPDATE: Seperti sistem file asli ext3kita akan coba dumpdan restore. Saya akan membuat Anda tetap up2date

— Thomas Berger
sumber

Rumit. Perkecil sistem file sumber terlebih dahulu, lalu dd?

— Bittrance

Jawaban:

Anda perlu memutakhirkan kedua sisi menjadi rsync 3. Dari changelog:

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

Sudah lebih dari 2 tahun sejak rsync 3.0.0 dirilis, tetapi, sayangnya, sebagian besar distribusi perusahaan didasarkan pada kode yang lebih tua dari itu, yang berarti Anda mungkin menggunakan rsync 2.6.

Untuk referensi (jika orang lain mengalami masalah ini), jika Anda sudah menjalankan rsync 3, maka Anda menggunakan opsi yang tidak kompatibel dengan rekursi tambahan. Dari halaman manual:

    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.

Juga, sekali lagi, kedua belah pihak harus menjalankan rsync 3 agar rekursi tambahan didukung.

— Steven Pritchard
sumber

Pritchard berterima kasih atas hal itu, tetapi bagian tambahan tidak masalah, kedua belah pihak menggunakan rsync> 3.0. Jika kita menggunakan rsync tanpa -H kita memiliki peningkatan kecepatan yang hebat, tapi bukan itu yang kita butuhkan.

— Thomas Berger

Aduh. Ya, dalam hal ini Anda mungkin ingin melihat opsi untuk mempercepat akses sistem file (seperti beralih ke ext4 jika Anda menggunakan ext3), beralih ke disk yang lebih cepat atau tingkat RAID (jika itu bahkan pilihan), dll. Sayangnya, Anda mungkin pada titik di mana sistem file tidak bisa cukup cepat dan cadangan tingkat blok mungkin satu-satunya pilihan Anda. Saya mengalami masalah ini mencoba rsync kumpulan BackupPC dari satu server ke yang lain.

— Steven Pritchard

Kami telah menggunakan ext * dump sekarang. Bekerja dengan baik, dan sisi pemulihan bahkan tidak harus ext *.

Kami telah melakukan pencadangan offline, dengan umounting perangkat dan digunakan dump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gz.

Di sini, baris terakhir yang bisa Anda lihat ukuran, waktu, kecepatan, dan nomor inode terakhir:

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

— Thomas Berger
sumber

Saya tidak tahu apakah ini masih benar tetapi dump dulu memiliki beberapa masalah jika sistem file sedang digunakan pada saat dump. Karena tujuan Anda adalah kecepatan, saya kira Anda telah menonaktifkan semua akses lain untuk itu, tetapi untuk berjaga-jaga .. Beritahu kami bagaimana Anda melakukannya

— SuperBOB

Anda bisa menggunakan LVM dan mengambil snapshot dari volume, lalu rsync snapshot sebagai cadangan.

Atau, Anda dapat menggabungkan ini dengan jawaban lain dan digunakan dump pada volume foto , untuk menghindari keharusan mengambil volume asli offline.

— Teddy
sumber

Apa pun yang bekerja pada level blok, bukan level sistem file mungkin akan menjadi peningkatan besar.

— Marcin

Seperti yang Anda lihat di pertanyaan saya, saya harus mirror di seluruh Jaringan, bukan lokal. Juga LVM BUKAN cermin, itu hanya, seperti yang Anda katakan, sebuah snapshot.

— Thomas Berger

@ Thomas Berger: Pikir saya adalah bahwa Anda kemudian akan menyalin snapshot (menggunakan rsync) melalui jaringan. Dan bagaimana tepatnya Anda mendefinisikan mirror , jika snapshot LVM bukan salah satunya?

— Teddy

Itu masih memiliki masalah yang sama: Butuh waktu berhari-hari. Pada hari-hari ini akan ada dalta besar (bukan bahwa kita akan membutuhkan itu) jadi kita harus mereserver ruang yang cukup, dan kita tidak memiliki ruang itu. Dan cermin adalah salinan sumber yang independen. Kami harus menyalin data dari produksi ke pengembangan untuk pelanggan.

— Thomas Berger

@ Thomas Berger: Awalnya saya maksudkan bahwa Anda akan me-rsync volume snapshot aktual, bukan sistem file pada snapshot. Namun, saya sekarang percaya solusi snapshot + dump menjadi lebih baik.

— Teddy