Backup-Fehler aufgrund von GIF-Duplikaten in Discourse

## Wie eine GIF-Datei einen Backup-Ausfall in Discourse verursachte

Während eines Backups eines der Foren auf der Discourse-Plattform ereignete sich ein anomaler Vorfall: dieselbe 1,6 MB große GIF-Datei wurde 246.173-mal dupliziert. Dadurch schwoll die Backup-Größe um 377 GB an, das Linux-Dateisystem wurde beschädigt und der gesamte Backup-Prozess stürzte vollständig ab. Das Problem lag nicht an einem Bug im Code, sondern an der Sicherheitsarchitektur der Plattform und den Einschränkungen des ext4-Dateisystems.

Warum aus einer Datei Hunderttausende Kopien wurden

Discourse verwendet einen „safe upload“-Mechanismus, bei dem jedes Mal, wenn eine Datei zwischen verschiedenen Kontexten verschoben wird (z. B. von einer privaten Nachricht zu einem öffentlichen Beitrag), das System eine neue Kopie mit einem eindeutigen SHA1-Hash erstellt. Obwohl der Dateiinhalt identisch bleibt, behandelt die Plattform sie als separates Objekt. Das ist notwendig, um Sicherheitsrichtlinien durchzusetzen und unbefugten Zugriff auf Mediadateien zu verhindern.

Im Fall eines beliebten GIFs – der tanzenden Rachel aus der TV-Serie Friends – fügten Nutzer es wiederholt in verschiedene Themen, Kommentare und private Nachrichten ein. Jede Verwendung in einem neuen Kontext erzeugte einen neuen Datenbankeintrag und eine neue Datei auf der Festplatte, obwohl der Binärinhalt exakt gleich war.

Erster Optimierungsversuch: Hard Links

Das Discourse-Team entwickelte eine Lösung, die Dateien während des Backups nach Inhalts-Hash gruppiert. Für jede Gruppe von Duplikaten wurde nur eine physische Kopie behalten, die restlichen durch Hard Links darauf ersetzt. Dieser Ansatz reduzierte die Backup-Größen drastisch und funktionierte auf den meisten Instanzen einwandfrei.

Beim Testen auf einem großen Kundenforum stellte sich jedoch heraus, dass das ext4-Dateisystem eine Grenze hat: maximal etwa 65.000 Hard Links pro Inode. Bei 246.173 Duplikaten wurde diese Grenze überschritten, worauf das System anfing, neue physische Kopien zu erstellen – nicht als Duplikate, sondern als eigenständige Dateien. Am Ende gab es statt einer Kopie ~181.000 zusätzliche Dateien, was das Problem nur teilweise löste.

Endlösung: Dynamisches Umschalten zwischen Links und Kopien

Die neue Lösung berücksichtigt Dateisystem-Einschränkungen und funktioniert universell:

• Das System erstellt zunächst Hard Links wie zuvor.
• Bei Erhalt eines EMLINK-Fehlers („Zu viele Links“) vom Linux-Kernel wechselt der Prozess zu lokaler Dateikopie.
• Die neue Kopie wird zur „primären“ für nachfolgende Links, und der Zyklus wiederholt sich bei der nächsten Grenze.

Dieser Ansatz erfordert keine Dateisystem-Anpassungen, ist mit jedem POSIX-kompatiblen OS kompatibel und reduziert effektiv die Backup-Größen auch bei extremen Duplikat-Zahlen.

Beispiel für die Verarbeitungslogik (vereinfacht):

if hard_link_fails_with_emlink?
  create_new_physical_copy
  reset_link_counter
end

Wichtige Erkenntnisse

• Sicherheit vs. Effizienz: Architekturentscheidungen für Kontextisolierung können bei Skalierung zu unerwarteten Nebenwirkungen führen.
• Dateisystem-Grenzen sind real: Auch niedrigstufige Limits wie 65.000 Hard Links pro Inode in ext4 können High-Level-Apps stören.
• Universelle Lösungen sind besser: Adaptive Algorithmen, die auf OS-Fehler reagieren, sind zuverlässiger als statische Optimierungen für ideale Bedingungen.
• Beliebte Inhalte treiben die Last: Häufig genutzte Mediadateien (Emojis, Reaktionen, Memes) werden zu versteckten Ressourcenfressern.
• Testen mit Produktionsdaten ist entscheidend: Nur reale Nutzungsszenarien enthüllen solche Randfälle.

Lektionen für Entwickler verteilter Systeme

Der Discourse-Vorfall beleuchtet ein klassisches Dilemma: die Abwägung von Datensicherheit und Speichereffizienz. Beim Design von Systemen für nutzergenerierte Inhalte sollten Sie Folgendes bedenken:

• Deduplizierung auf Anwendungsebene vor dem Schreiben auf die Festplatte.
• Überwachen von Metriken zu Dateianzahlen und Duplikaten.
• Sanftes Herabstufen beim Erreichen von Systemgrenzen.

Obwohl das Problem aus der Massennutzung eines GIFs resultierte, liegen seine Wurzeln in architektonischen Abwägungen. Die vom Discourse-Team gefundene Lösung kann als Beispiel für andere Projekte mit ähnlichen Herausforderungen dienen.

— Editorial Team