„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? Das ist zu erwarten. Sie haben einen kräftigen Server – 128 GB – und eine Workload, die nicht gerade winzig ist. Wenn der Speicherverbrauch also langsam steigt, zucken Sie mit den Schultern. Dafür ist er schließlich da.

Aber dann geht es immer weiter. Und weiter. Bis ein einzelner Dienst – Veeam.Archiver.Proxy – praktisch alles verschlingt, was er in die Finger bekommt. Nicht gelegentlich. Nicht nur bei Lastspitzen. Ständig.

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

Das Wochenende, das nie endete

Der eigentliche Wendepunkt ist nicht der RAM-Verbrauch – es ist das, was danach kommt.

Jobs beginnen zu scheitern. Nicht sofort, nicht sauber, sondern schleichend. Sie ziehen sich hin. Sie stocken. Sie laufen ein ganzes Wochenende, ohne fertig zu werden. Sie teilen sie in kleinere Häppchen auf, in der Hoffnung, dass das hilft. Tut es nicht. Sie setzen einen neuen Proxy-Server auf, weil Sie vermuten, dass der alte das Problem ist.

Gleiches Ergebnis.

Das ist der Moment, vor dem sich jeder Admin fürchtet. Wenn Sie die naheliegenden Lösungen ausprobiert haben und sich nichts ändert. Wenn das System nicht nur langsam ist, sondern feststeckt.

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

In solchen Situationen gibt es einen natürlichen Reflex: dem Problem mehr Ressourcen entgegenwerfen.

Mehr RAM. Mehr Proxys. Mehr Trennung zwischen den Workloads.

Und fairerweise taucht dieser Rat 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 – dedizierte Systeme, vielleicht sogar andere Betriebssystem-Entscheidungen.

Aber hier der Haken: Der Nutzer hat das bereits ausprobiert. Neuer Proxy. Gleiches Verhalten.

Das macht es so frustrierend. Es ist kein klares Skalierungsproblem. Es ist etwas Tieferes – etwas Strukturelles.

Die Design-Entscheidung, über die niemand spricht

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. Denn aus einer Perspektive funktioniert das System exakt wie vorgesehen – es nutzt verfügbare Ressourcen aggressiv, um den Durchsatz zu maximieren. Aus einer anderen Perspektive fühlt es sich an, als würde es den Rest Ihrer Infrastruktur aushungern.

Zwei völlig legitime Interpretationen. Dasselbe Verhalten.

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

Denn ob „reserviert" oder „aktiv genutzt" – aus operativer Sicht 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.

Tausende Objekte – allein 4.000 für einen einzigen Kunden.

Das ist kein kleines Setup. Es ist auch keine massive Enterprise-Größenordnung, aber es liegt genau in dieser unbequemen Mitte – groß genug, um das System zu belasten, klein genug, dass Architektur-Abkürzungen (wie All-in-one-Server) noch vernünftig erscheinen.

Und genau dort taucht meist die Reibung auf. Nicht an den Extremen, sondern in der Mitte.

Drei Blickwinkel auf dasselbe Problem

Was diese Situation so interessant macht, ist, wie unterschiedlich sie interpretiert wird.

Eine Sichtweise sagt: Das ist ein Konfigurationsproblem. Zu viele Jobs, zu wenig Trennung, Proxys, die auf einem einzigen System zu viel erledigen. Die Lösung? Die Architektur neu gestalten.

Eine andere Sichtweise sagt: Das ist erwartetes Verhalten. Hoher RAM-Verbrauch ist nicht das Problem – so ist das System eben konzipiert. Das eigentliche Problem liegt woanders, vielleicht in der Job-Struktur oder der Workload-Verteilung.

Und dann gibt es noch die dritte, leisere Sichtweise: Das passiert einfach, wenn sich Komplexität über die Zeit aufbaut. Mehr Jobs, mehr Repos, mehr Kunden – bis das System an einem Punkt ankommt, 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

Was am meisten heraussticht, sind nicht die technischen Details – es ist die Unsicherheit.

Die Logs deuten auf nichts Eindeutiges hin. Änderungen bringen keine klaren Verbesserungen. 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. Nicht der RAM-Verbrauch, nicht die gescheiterten Jobs – sondern das Gefühl, in einem System festzustecken, das Ihnen kein klares Feedback gibt.

Was läuft also wirklich falsch?

Das ist der unangenehme Teil: Es gibt keine einzelne, saubere Antwort.

Es liegt vermutlich nicht nur am Speicher. Nicht nur an den Proxys. Nicht nur an der Job-Größe. Es ist das Zusammenspiel von allem – Resource-Scaling, Workload-Verteilung, Architekturentscheidungen und vielleicht sogar subtile Ineffizienzen, die erst in dieser Größenordnung sichtbar werden.

Und genau das macht es so schwer zu beheben. Denn Sie lösen nicht ein Problem – Sie entwirren ein ganzes System.

Das größere Bild, das niemand anspricht

Hier geht es nicht nur um ein einzelnes Setup oder ein einzelnes Produkt. Es geht 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.

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