Come eseguire il mirroring dei filesystem con milioni di hardlink?

Al momento abbiamo un grosso problema: dobbiamo eseguire il mirroring di un filesystem per uno dei nostri clienti. Questo di solito non è davvero un problema, ma eccolo qui:

Su questo filesystem c'è una cartella con milioni di hardlink (sì! MILIONI!). rsyncrichiede più di 4 giorni per compilare l'elenco file.

Utilizziamo le seguenti rsyncopzioni:

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

Qualcuno ha idea di come accelerare questo rsync o utilizzare alternative? Non è stato possibile utilizzarlo ddpoiché il disco di destinazione è più piccolo dell'origine.

AGGIORNAMENTO: Come sarà il filesystem originale ext3, proveremo dumpe restore. Ti terrò aggiornato

— Thomas Berger
fonte

Difficile. Riduci prima il file system di origine, quindi dd?

— Bittrance,

Risposte:

Devi aggiornare entrambi i lati a rsync 3. Dal log delle modifiche:

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

Sono passati più di 2 anni da quando è stato rilasciato rsync 3.0.0, ma, sfortunatamente, la maggior parte delle distribuzioni aziendali sono basate su codice più vecchio di quello, il che significa che probabilmente stai usando rsync 2.6.

Per riferimento (se qualcun altro ha questo problema), se si sta già eseguendo rsync 3, si stanno utilizzando opzioni incompatibili con la ricorsione incrementale. Dalla pagina man:

    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.

Inoltre, di nuovo, entrambe le parti devono eseguire rsync 3 per supportare la ricorsione incrementale.

— Steven Pritchard
fonte

Pritchard ti ringrazia per questo, ma le parti incrementali non sono un problema, entrambe le parti usano rsync> 3.0. Se usiamo rsync senza -H abbiamo un grande miglioramento della velocità, ma non è quello di cui abbiamo bisogno.

— Thomas Berger,

Ahia. Sì, in quel caso potresti voler esaminare le opzioni per accelerare l'accesso al filesystem (come passare a ext4 se stai usando ext3), passare a dischi più veloci o livelli RAID (se è anche un'opzione), ecc. Sfortunatamente, tu potrebbe essere in un punto in cui il filesystem non può essere abbastanza veloce e i backup a livello di blocco potrebbero essere l'unica opzione. Ho riscontrato questo problema nel tentativo di risincronizzare un pool di BackupPC da un server a un altro.

— Steven Pritchard,

Abbiamo usato ext * dump ora. Funziona bene e il lato di ripristino non deve nemmeno essere ext *.

Abbiamo eseguito un backup offline, smontando il dispositivo e utilizzato dump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gz.

Ecco le ultime righe che potresti vedere dimensioni, tempo, velocità e gli ultimi numeri dell'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

— Thomas Berger
fonte

Non so se questo è ancora vero, ma il dump aveva alcuni problemi se il file system era in uso al momento del dump. Poiché il tuo obiettivo è la velocità, suppongo che tu abbia già disabilitato tutti gli altri accessi ad esso, ma nel caso in cui ... Facci sapere come vai

— SuperBOB,

È possibile utilizzare LVM e acquisire istantanee del volume, quindi sincronizzare di nuovo l'istantanea come backup.

In alternativa, è possibile combinare questo con l'altra risposta e utilizzare dump il volume dell'istantanea , per evitare di portare offline il volume originale.

— Teddy
fonte

Qualunque cosa funzioni a livello di blocco, non a livello di file system, sarebbe probabilmente un enorme miglioramento.

— Marcin,

Come puoi vedere nella mia domanda, devo eseguire il mirroring attraverso la rete, non locale. Inoltre LVM NON è uno specchio, è solo, come hai detto, un'istantanea.

— Thomas Berger,

@Thomas Berger: Pensavo che avresti copiato l'istantanea (usando rsync) sulla rete. E come si definisce esattamente il mirror , se un'istantanea LVM non è una?

— Teddy,

Questo ha ancora lo stesso problema: ci vorrebbero giorni. In questi giorni ci sarebbe un enorme dalta (non che ne avremmo bisogno), quindi dobbiamo riservare abbastanza spazio e non abbiamo quello spazio. E un mirror è una copia indipendente della fonte. Dobbiamo copiare i dati dalla produzione allo sviluppo per il cliente.

— Thomas Berger,

@Thomas Berger: inizialmente intendevo risincronizzare il volume dell'istantanea reale, non il file system sull'istantanea. Tuttavia, ora credo che la soluzione snapshot + dump sia migliore.

— Teddy,