Wie spiegele ich Dateisysteme mit Millionen von Hardlinks?

Wir haben momentan ein großes Problem: Wir müssen ein Dateisystem für einen unserer Kunden spiegeln. Das ist normalerweise kein wirkliches Problem, aber hier ist es:

Auf diesem Dateisystem gibt es einen Ordner mit Millionen von Hardlinks (ja! MILLIONEN!). rsyncbenötigt mehr als 4 Tage, um nur die Dateiliste zu erstellen.

Wir verwenden folgende rsyncOptionen:

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

Hat jemand eine Idee, wie man diesen Rsync beschleunigt oder Alternativen verwendet? Wir konnten nicht verwenden, ddda die Zielfestplatte kleiner als die Quelle ist.

UPDATE: Wie das ursprüngliche Dateisystem ist, werden ext3wir versuchen dumpund restore. Ich werde dich auf dem Laufenden halten

— Thomas Berger
quelle

Tricky. Verkleinern Sie zuerst das Quelldateisystem und dann dd?

— Bittrance

Antworten:

Sie müssen beide Seiten auf rsync 3 aktualisieren. Aus dem Änderungsprotokoll:

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

Es ist über 2 Jahre her, seit rsync 3.0.0 veröffentlicht wurde, aber leider basieren die meisten Unternehmensdistributionen auf älterem Code, was bedeutet, dass Sie wahrscheinlich rsync 2.6 verwenden.

Als Referenz (wenn jemand dieses Problem hat), wenn Sie sind rsync laufen 3 bereits, dann sind Sie mit Optionen , die mit inkrementeller Rekursion nicht kompatibel sind. Von der Manpage:

    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.

Außerdem müssen beide Seiten rsync 3 ausführen, damit die inkrementelle Rekursion unterstützt wird.

— Steven Pritchard
quelle

Pritchard, danke für diese Hinterhand, aber die inkrementellen Teile sind kein Problem, beide Seiten verwenden rsync> 3.0. Wenn wir rsync ohne -H verwenden, haben wir eine große Geschwindigkeitsverbesserung, aber das ist nicht das, was wir brauchen.

— Thomas Berger

Autsch. Ja, in diesem Fall möchten Sie möglicherweise Optionen prüfen, um den Zugriff auf das Dateisystem zu beschleunigen (z. B. den Wechsel zu ext4, wenn Sie ext3 verwenden), den Wechsel zu schnelleren Festplatten oder RAID-Levels (wenn dies überhaupt eine Option ist) usw. Leider Möglicherweise befindet sich das Dateisystem nicht mehr schnell genug, und Sicherungen auf Blockebene sind möglicherweise Ihre einzige Option. Ich hatte dieses Problem beim Versuch, einen BackupPC-Pool von einem Server auf einen anderen zu synchronisieren.

— Steven Pritchard

Wir haben jetzt ext * dump verwendet. Funktioniert gut und die Wiederherstellungsseite muss nicht einmal ext * sein.

Wir haben eine Offline-Sicherung durchgeführt, indem wir das Gerät umgehängt und verwendet haben dump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gz.

Hier die letzten Zeilen, in denen Sie Größe, Zeit, Geschwindigkeit und die letzten Inode-Nummern sehen konnten:

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
quelle

Ich weiß nicht, ob dies immer noch zutrifft, aber Dump hatte früher einige Probleme, wenn das Dateisystem zum Zeitpunkt des Dumps verwendet wird. Da Ihr Ziel Geschwindigkeit ist, haben Sie

— wahrscheinlich

Sie können LVM verwenden, Snapshots des Volumes erstellen und dann den Snapshot als Backup erneut synchronisieren.

Alternativ können Sie dies mit der anderen Antwort kombinieren und dump auf dem Snapshot-Volume verwenden , um zu vermeiden, dass das ursprüngliche Volume offline geschaltet werden muss.

— Teddy
quelle

Alles, was auf Blockebene und nicht auf Dateisystemebene funktioniert, wäre wahrscheinlich eine enorme Verbesserung.

— Marcin

Wie Sie in meiner Frage sehen konnten, muss ich über das Netzwerk spiegeln, nicht lokal. Auch LVM ist KEIN Spiegel, sondern, wie Sie sagten, nur ein Schnappschuss.

— Thomas Berger

@ Thomas Berger: Mein Gedanke war, dass Sie dann den Snapshot (mit rsync) über das Netzwerk kopieren würden. Und wie genau definieren Sie Spiegel , wenn es sich bei einem LVM-Snapshot nicht um einen handelt?

— Teddy

Das hat immer noch das gleiche Problem: Es würde Tage dauern. In diesen Tagen würde es eine riesige Dalta geben (nicht, dass wir das brauchen würden), also müssen wir genug Speicherplatz reservieren, und wir haben diesen Speicherplatz nicht. Und ein Spiegel ist eine unabhängige Kopie der Quelle. Wir müssen die Daten von der Produktion bis zur Entwicklung für den Kunden kopieren.

— Thomas Berger

@ Thomas Berger: Ich meinte ursprünglich, dass Sie das tatsächliche Snapshot-Volume synchronisieren würden, nicht das Dateisystem auf dem Snapshot. Jetzt glaube ich jedoch, dass die Snapshot + Dump-Lösung besser ist.

— Teddy