☰

Optimaler Dateisystemtyp und Einbindungsoptionen für ein dediziertes rsnapshot-Laufwerk

tag-icon • tag-icon linux backup filesystems mount rsnapshot
Optimaler Dateisystemtyp und Einbindungsoptionen für ein dediziertes rsnapshot-Laufwerk

Wir haben ein externes USB 2-Laufwerk, das wir als Backup-Laufwerk für unsere Konfiguration verwenden. Wir verwendenSchnappschussfür die Backups. Es verwendet einige Standardbefehle zum Verwalten von Snapshots:

  1. rm -rf: löscht abgelaufene Snapshots
  2. mv: verschiebt ältere Snapshots einen Slot nach unten
  3. cp -al: dupliziert den letzten Snapshot in den neuen Slot
  4. rsync -a --delete --numeric-ids --relative: synchronisiert neuen Snapshot

Wie Sie dem folgenden Protokoll entnehmen können, wird die meiste Zeit für die rm -rffolgenden cp -alSchritte aufgewendet:

[25/Dec/2010:14:00:02] rsnapshot hourly: started
[25/Dec/2010:14:00:02] echo 21012 > /var/run/rsnapshot.pid
[25/Dec/2010:14:00:02] rm -rf /mnt/extdrive/snapshots/hourly.5/
[25/Dec/2010:14:15:48] mv /mnt/extdrive/snapshots/hourly.4/ /mnt/extdrive/snapshots/hourly.5/
[25/Dec/2010:14:15:48] mv /mnt/extdrive/snapshots/hourly.3/ /mnt/extdrive/snapshots/hourly.4/
[25/Dec/2010:14:15:48] mv /mnt/extdrive/snapshots/hourly.2/ /mnt/extdrive/snapshots/hourly.3/
[25/Dec/2010:14:15:48] mv /mnt/extdrive/snapshots/hourly.1/ /mnt/extdrive/snapshots/hourly.2/
[25/Dec/2010:14:15:48] cp -al /mnt/extdrive/snapshots/hourly.0 /mnt/extdrive/snapshots/hourly.1
[25/Dec/2010:14:23:32] rsync -a --delete --numeric-ids --relative /etc /mnt/extdrive/snapshots/hourly.0/sm4/
[25/Dec/2010:14:23:52] touch /mnt/extdrive/snapshots/hourly.0/
[25/Dec/2010:14:23:52] rm -f /var/run/rsnapshot.pid
[25/Dec/2010:14:23:52] rsnapshot hourly: completed successfully

Meine Fragen:

  1. Ich verwende derzeit ext4 als Dateisystem. Vielleicht ist das nicht die beste Wahl unter den in Red Hat verfügbaren. Hat jemand Empfehlungen, die den Vorgang beschleunigen würden?

  2. Die Mount-Optionen der Partition sind sync,dirsync 1 2. Gibt es eine Möglichkeit, dies zu optimieren, da es nur für rsnapshot verwendet wird? Natürlich wäre ich für eine Begründung sehr dankbar.

Antwort1

  1. ext4 ist in Ordnung.

  2. Die Optionen „sync,dirsync“ sorgen dafür, dass Daten- und Metadatenaktualisierungen synchron erfolgen, was bei den meisten Workloads einen erheblichen negativen Einfluss auf die Leistung hat. Das Entfernen dieser Optionen wird die Leistung höchstwahrscheinlich steigern, Sie müssen jedoch daran denken, das Gerät auszuhängen, bevor Sie am Kabel ziehen, da Sie sonst möglicherweise Daten verlieren (vermutlich wurden diese Optionen deshalb überhaupt hinzugefügt, sie sind nicht die Standardoptionen, oder vielleicht ist es eine Art besonderer Zaubertrick, den Ihre Distribution für USB-Geräte anwendet).

  3. noatime deaktiviert Atime-Updates, wodurch die Anzahl der Schreibvorgänge im Dateisystem reduziert wird. Mehr oder weniger alle Anwendungen, einschließlich rsnapshot, benötigen keine Atimes, daher sollte dies vollkommen sicher sein.

  4. data=writeback reduziert den Journaling-Overhead, allerdings erhöht sich dadurch die Möglichkeit eines Datenverlusts bei einem Stromausfall leicht. Je nach Distribution ist dies möglicherweise bereits die Standardeinstellung.

  5. Mit ext4 ist es auch möglich, das Journal vollständig zu deaktivieren (ab Kernel 2.6.29), obwohl ich das nicht empfehlen würde. Es verfügt immer noch über alle anderen Verbesserungen von ext4, daher sollte es schneller sein als die Verwendung von ext2, fwiw.

  6. barrier=0 deaktiviert Barrieren, was die Leistung beim Schreiben verbessert, allerdings auf Kosten der Wahrscheinlichkeit eines Datenverlusts bei einem Absturz.

Antwort2

Sie konfigurieren rsnapshot so, dass mehr Snapshots gespeichert werden (z. B. 9999) und löschen diese dann selbst mit crontab von der Festplatte. Dadurch wird die Geschwindigkeit von rsnapshot vorhersehbarer.

Antwort3

Beachten Sie auch, dass durch die Verwendung --link-destauch der Plan für die Vorgehensweise geändert wird cp, was die Leistung erheblich beeinträchtigen kann (im Grunde rmwird nur die hourly.$oldverwendet und dann rsyncwird das Kopieren von hourly.1auf hourly.0die Quelle und die Synchronisierung gleichzeitig durchgeführt).

Es gibt weitere Diskussionen über einealternative Technik hier- im Grunde wird der letzte stündliche Snapshot mit in den neuen rotiert, mv hourly.$old hourly.0anstatt rmihn mit - zu versehen, und ein cp -aflfrom hourly.1onto ausgeführt hourly.0, um ihn auf den neuesten Stand zu bringen, aber das habe ich nicht ausprobiert - Sie müssten die Rotation manuell durchführen, anstatt sich darauf zu verlassen, dass rsnapshotdies von on erledigt wird

verwandte Informationen