Was ist der schnellste Weg, um tägliche Backups für 500.000 Dateien zu erstellen?

392
raullarion

Wir haben eine Anwendung, die bisher über 540.000 Bilder generiert hat. Die Bilder werden in einer Baumstruktur gehalten, die bisher 5 Millionen Inodes verwendet.

Wir möchten die Daten täglich auf einem externen Remote-Server sichern. Wir haben an rsync gedacht, aber wir wissen nicht, ob es der schnellste Weg sein wird.

Haben Sie eine Empfehlung für eine effiziente Backup-Strategie?

4
Wie viel davon ändert sich? Gibt es Änderungen in Dateien oder werden nur neue Dateien hinzugefügt (und vorhandene bleiben gleich)? Haben Sie Speicherplatzanforderungen (Komprimierung)? Wie groß ist deine Bandbreite zwischen Quelle und Ziel? Haben Sie eine feste Obergrenze (z. B. 2 Stunden) und nicht nur eine "schnellste" Zeit? Bob vor 6 Jahren 0
Die Dateien unterliegen ständigen Änderungen. Gestern hat unsere App 24.000 neue Dateien generiert. Wir behalten nicht den Überblick, wie viele täglich entfernt werden. Es ist jedoch davon auszugehen, dass täglich etwa 10.000 entfernt werden. Die App wird in Amsterdam gehostet, der Backup-Server befindet sich in der Ostküste der USA. Wir kennen die genaue Bandbreite zwischen den Servern nicht, aber wir verwenden denselben Backup-Server für andere Apps, und die Dinge laufen ziemlich schnell ab. Wir haben keine Zeitbeschränkung, aber wir möchten nicht, dass der Sicherungsprozess hohe Lasten auf unserem App-Server erzeugt. raullarion vor 6 Jahren 0
540K Bilder, 5M Inodes, viele Unterverzeichnisse? In Anwendungen, die sehr viele Dateien generieren, empfiehlt es sich, Dateien in zeitabhängigen Verzeichnissen zu speichern, um Verzeichnisse mit zu vielen untergeordneten Objekten zu vermeiden. Sie erstellen dann jedes Jahr / Monat / Tag / Stunde ein neues Verzeichnis, abhängig von der Erstellungsrate. ist das schon so? Wenn Sie wissen, wann Ihre letzte Sicherung war, können Sie sich darauf konzentrieren, wann Sie nach neuen Dateien suchen müssen (ja, dies kümmert sich nicht um alte Dateien, die sich geändert haben, aber die Anwendungen vermeiden dies und ziehen es vor, eine neue Datei zu erstellen). xenoid vor 6 Jahren 0
Leider zu viele Unterverzeichnisse. Es ist ein sehr großer Konstruktionsfehler, aber ich fürchte, wir können jetzt nicht viel für unsere vorhandenen Dateien tun. raullarion vor 6 Jahren 0

1 Antwort auf die Frage

2
Deltik

Mann, es dauert so lange, jeden Tag 5.000.000 Inodes zu scannen, um Dateien zu finden, die sich geändert haben!

Was wäre, wenn nur die Änderungen seit der letzten Sicherung gesichert werden könnten?

Nun, Sie können… mit Schnappschüssen !

Die größte Hürde für Momentaufnahmen ist der Wechsel zu einem Dateisystem, das sie unterstützt.

Unter Linux sind zwei bekannte Snapshot-Dateisysteme:

  • Btrfs - Entwickelt für Linux, weniger kampferprobt
  • ZFS - Auf Linux portiert, schon länger

Beide sind Copy-on-Write-Dateisysteme . Das bedeutet für Sie praktisch, dass sie die Änderungen seit dem letzten Snapshot nachverfolgen. Wenn Sie den letzten Snapshot an den Sicherungsserver senden, werden nur die Änderungen gesendet, Sie haben jedoch immer noch eine vollständige Kopie aller von Ihnen gewählten täglichen Sicherungen behalten.

Dies bedeutet, dass Sie als Bonus mehr als einen Tag Backups für nicht viel zusätzlichen Speicherplatz haben können (nur den Speicherplatz, der täglich von den Änderungen verwendet wird), und Sie können die Backups flexibel löschen, wöchentlich, monatlich, oder jährliche Backups nach Ihren Wünschen.

Inkrementelle Btrfs-Sicherungen

Dies ist ein Beispiel für Befehle, die Sie ausführen können, um inkrementelle Sicherungen zu erstellen und an Ihren Sicherungsserver zu senden:

# Make a snapshot btrfs subvolume snapshot -r /app/data /backup/app-data-$(date "+%Y%m%dT%H%M%S%Z")  # Ensure the snapshot is saved sync  # Find your latest snapshot, referred to as `/backup/app-data-THIS_BACKUP_TIMESTAMP` below ls -lhtr /backup/  # Send the snapshot since the previous snapshot to the backup server btrfs send -p /backup/app-data-LAST_BACKUP_TIMESTAMP /backup/app-data-THIS_BACKUP_TIMESTAMP | ssh BACKUP_USER@BACKUP_SERVER "btrfs receive /backup/app-data"

Hinweis: Ausschließen -p /backup/app-data-LAST_BACKUP_TIMESTAMPvon dem letzten Befehl, wenn dies die erste Sicherung ist.

Inkrementelle ZFS-Sicherungen

Dies ist ein Beispiel für Befehle, die Sie ausführen können, um inkrementelle Sicherungen zu erstellen und an Ihren Sicherungsserver zu senden:

# Create a snapshot of the "data" dataset in your "app-pool" zpool zfs snapshot app-pool/data@$(date "+%Y%m%dT%H%M%S%Z")  # Find your latest snapshot, referred to as `app-pool/data@THIS_BACKUP_TIMESTAMP` below zfs list -rt snapshot app-pool/data  # Send the snapshot since the previous snapshot to the backup server zfs send -i app-pool/data@LAST_BACKUP_TIMESTAMP app-pool/data@THIS_BACKUP_TIMESTAMP | ssh BACKUP_USER@BACKUP_SERVER "zfs receive backup-pool/app-data"

Hinweis: Ausschließen -i app-pool/data@LAST_BACKUP_TIMESTAMPvon dem letzten Befehl, wenn dies die erste Sicherung ist.

Verwandte Probleme