128 GB RAM… und es frisst trotzdem alles: Wenn Backup-Software gegen Ihre Infrastruktur kämpft

Wenn „hohe Auslastung" nicht mehr normal wirkt

Anfangs wirkt es nicht wie eine Krise. Ein Backup-Dienst, der viel RAM nutzt, ist zu erwarten. Sie haben einen kräftigen Server mit 128 GB und eine Workload, die nicht gerade winzig ist. Wenn der Speicherverbrauch also langsam steigt, zucken Sie mit den Schultern, denn dafür ist der Speicher da.

Dann geht es aber immer weiter, bis ein einzelner Dienst, Veeam.Archiver.Proxy, praktisch alles verschlingt, was er in die Finger bekommt. Nicht gelegentlich und nicht nur bei Lastspitzen, sondern ständig.

Genau dann kippt die Stimmung. Was sich früher wie normales Verhalten anfühlte, wirkt plötzlich wie etwas, das Sie nicht mehr wirklich unter Kontrolle haben.

Das Wochenende, das nie endete

Der eigentliche Wendepunkt ist weniger der RAM-Verbrauch als das, was danach kommt.

Jobs beginnen zu scheitern, nicht sofort und nicht sauber, sondern schleichend. Sie ziehen sich hin, sie stocken, und sie laufen ein ganzes Wochenende, ohne fertig zu werden. Sie teilen sie in kleinere Häppchen auf, in der Hoffnung, dass das hilft, aber es hilft nicht. Sie setzen einen neuen Proxy-Server auf, weil Sie den alten in Verdacht haben, und bekommen dasselbe Ergebnis.

Das ist der Moment, vor dem sich jeder Admin fürchtet: Sie haben die naheliegenden Lösungen ausprobiert, und nichts ändert sich. Das System ist nicht nur langsam, es steckt fest.

Die Illusion von „Mehr Ressourcen lösen das Problem"

In solchen Situationen gibt es einen natürlichen Reflex: dem Problem mehr Ressourcen entgegenwerfen, also mehr RAM, mehr Proxys und mehr Trennung zwischen den Workloads.

Dieser Rat taucht auch schnell auf. „Sie brauchen wahrscheinlich separate Proxy-Server", schlägt eine Stimme vor und deutet an, dass das aktuelle All-in-one-Setup Teil des Problems sein könnte. Eine andere tendiert zu Architekturänderungen, also dedizierten Systemen und vielleicht sogar anderen Betriebssystem-Entscheidungen.

Der Haken dabei: Der Nutzer hat das bereits ausprobiert. Neuer Proxy, gleiches Verhalten. Deshalb ist es so frustrierend, denn ein klares Skalierungsproblem ist es offenbar nicht, sondern etwas Strukturelles.

Die Design-Entscheidung, die dabei selten erwähnt wird

Dann liefert jemand ein Detail, das die gesamte Sichtweise verändert.

Der Proxy-Dienst soll eigentlich viel Speicher nutzen. Er skaliert automatisch und verbraucht bis zu rund 80 % des verfügbaren RAM, um Objekte schneller zu verarbeiten.

Plötzlich sieht das, was wie ein Bug aussah, eher wie ein Feature aus. Und genau da wird es kompliziert. Aus einer Perspektive funktioniert das System exakt wie vorgesehen und nutzt verfügbare Ressourcen aggressiv, um den Durchsatz zu maximieren. Aus einer anderen Perspektive hungert es den Rest Ihrer Infrastruktur aus. Zwei völlig legitime Interpretationen desselben Verhaltens.

„Er hält den RAM nicht … er nutzt ihn"

Die Debatte endet dort nicht, sie wird noch nuancierter.

Die eine Seite befürchtet, dass der Dienst Speicher reserviert, ihn also festhält, selbst wenn er gerade nicht aktiv gebraucht wird, und damit andere Prozesse blockiert. Die Antwort darauf fällt unverblümt aus: „Er hält keinen RAM, außer er nutzt ihn gerade."

Diese Unterscheidung ist wichtig, fühlt sich in der Praxis aber nicht immer beruhigend an. Ob reserviert oder aktiv genutzt, operativ ist das Ergebnis dasselbe: Andere Workloads fühlen sich eingeengt an, und die Performance wird unberechenbar.

Das Skalierungsproblem, das offen zutage liegt

Dann schauen Sie sich die Zahlen an, und plötzlich ergibt vieles einen Sinn. Zwei Proxy-Server, 59 Repositories, 59 Jobs und tausende Objekte, allein 4.000 für einen einzigen Kunden.

Das ist kein kleines Setup, aber auch keine massive Enterprise-Größenordnung. Es liegt genau in dieser unbequemen Mitte, groß genug, um das System zu belasten, und klein genug, dass Architektur-Abkürzungen wie All-in-one-Server noch vernünftig erscheinen. Dort taucht die Reibung meist auf, nicht an den Extremen.

Drei Blickwinkel auf dasselbe Problem

Interessant an dieser Situation ist, wie unterschiedlich sie interpretiert wird.

Eine Sichtweise sagt, es sei ein Konfigurationsproblem: zu viele Jobs, zu wenig Trennung, Proxys, die auf einem einzigen System zu viel erledigen. Die Lösung wäre dann, die Architektur neu zu gestalten.

Eine andere Sichtweise sagt, das Verhalten sei erwartbar. Hoher RAM-Verbrauch ist dann nicht das Problem, sondern Teil der Konzeption, und das eigentliche Problem liegt woanders, vielleicht in der Job-Struktur oder der Workload-Verteilung.

Und dann gibt es die dritte, unauffälligere Sichtweise: Das passiert einfach, wenn sich Komplexität über die Zeit aufbaut. Mehr Jobs, mehr Repos und mehr Kunden, bis das System einen Punkt erreicht, an dem es technisch funktioniert, sich aber praktisch kaum noch verwalten lässt.

Keine dieser Sichtweisen ist falsch. Sie betrachten nur unterschiedliche Ebenen desselben Problems.

Die eigentliche Frustration: keine klare Antwort

Am meisten sticht nicht das technische Detail heraus, sondern die Unsicherheit. Die Logs deuten auf nichts Eindeutiges hin, Änderungen bringen keine klaren Verbesserungen, und jede Lösung fühlt sich wie Raten an.

„Ich fühle mich bei der Lösungssuche echt am Ende", gibt der Nutzer zu.

Das ist der Teil, der hängen bleibt, mehr als der RAM-Verbrauch oder die gescheiterten Jobs: das Gefühl, in einem System festzustecken, das Ihnen kein klares Feedback gibt.

Was läuft also wirklich falsch?

Der unangenehme Teil ist, dass es keine einzelne, saubere Antwort gibt.

Es liegt vermutlich nicht allein am Speicher, an den Proxys oder an der Job-Größe, sondern am Zusammenspiel von allem: Resource-Scaling, Workload-Verteilung, Architekturentscheidungen und vielleicht sogar subtilen Ineffizienzen, die erst in dieser Größenordnung sichtbar werden.

Deshalb ist es so schwer zu beheben. Sie lösen nicht ein Problem, Sie entwirren ein ganzes System.

Das größere Bild dahinter

Es geht hier nicht nur um ein einzelnes Setup oder ein einzelnes Produkt, sondern um ein Muster.

Moderne Backup-Systeme sind leistungsstark, aber auch komplex. Sie skalieren aggressiv, setzen bestimmte Architekturen voraus und verhalten sich nicht immer intuitiv. Wenn alles zusammenpasst, funktionieren sie hervorragend. Wenn etwas nicht stimmt, wird es schwer, ihr Verhalten nachzuvollziehen.

In dieser Grauzone, in der Dinge eigentlich funktionieren „sollten", es aber nicht tun, beginnt die eigentliche Herausforderung. Denn an diesem Punkt verwalten Sie nicht mehr nur Backups, Sie debuggen das System, das eigentlich alles andere schützen soll.