128GB of RAM and Veeam's Backup Proxy Still Eats Everything

When "high usage" stops feeling normal

At first, it doesn't seem like a crisis. A backup service using a lot of RAM is expected. You've got a beefy server with 128GB and a workload that's far from tiny, so when the memory starts creeping up, you shrug it off. That's what it's there for.

Then it keeps going, until one service, Veeam.Archiver.Proxy, is basically consuming everything it can get its hands on, constantly, well beyond occasional spikes.

That's when the tone shifts. What used to feel like "normal behavior" starts to feel like something you can't quite control.

The weekend that never ended

The RAM usage turns out to be the lesser problem. The real breaking point is what comes next.

Jobs start failing, slowly rather than cleanly. They drag, they stall, and they run for an entire weekend without finishing. You split them into smaller chunks, hoping that'll help, and it doesn't. You spin up a new proxy server, thinking maybe the old one is the issue, and get the same result.

That's the moment every admin dreads: you've tried the obvious fixes, nothing changes, and the system has gone from slow to stuck.

The illusion of "more resources will fix it"

The natural instinct in situations like this is to throw more resources at the problem: more RAM, more proxies, more separation between workloads.

To be fair, that advice shows up quickly. "You probably need separate proxy servers," one voice suggests, hinting that the current all-in-one setup might be part of the issue. Another leans toward architecture changes, such as dedicated systems and maybe even different OS choices.

The user had already tried that, though. New proxy, same behavior. That's what makes this frustrating: it doesn't look like a clear scaling issue, and whatever is wrong seems more structural.

The design choice that changes the picture

Then someone drops a detail that changes how you look at everything. The proxy service is supposed to use a lot of memory. It auto-scales, consuming up to around 80% of available RAM to process objects faster.

Suddenly, what looked like a bug starts to look like a feature, and things get complicated. From one perspective, the system is working exactly as designed, using available resources aggressively to maximize throughput. From another, it feels like it's starving the rest of your infrastructure. Both interpretations are valid, and they describe the same behavior.

"It's not holding RAM… it's using it"

The debate doesn't stop there. One side worries that the service is reserving memory, holding onto it even when it's not actively needed and effectively blocking other processes. The response comes back bluntly: "It doesn't hold RAM unless it's using it."

That distinction matters, but it doesn't always feel reassuring in practice. Whether memory is "reserved" or "actively used," the operational outcome is the same: other workloads feel squeezed, and performance becomes unpredictable.

The scale problem hiding in plain sight

Then you look at the numbers, and things start to click. There are two proxy servers, 59 repositories, 59 jobs, and thousands of objects, with 4,000 for one customer alone.

That's not a small setup, and it's not massive enterprise scale either. It sits in the uncomfortable middle ground: big enough to stress the system, small enough that architecture shortcuts like all-in-one servers still seem reasonable. That middle is where friction tends to show up, more than at the extremes.

Three ways to see the same problem

What makes this situation interesting is how differently people interpret it.

One perspective says this is a configuration issue: too many jobs, not enough separation, and proxies doing too much on a single system. The fix would be to redesign the architecture.

Another says this is expected behavior. By that reading, high RAM usage is simply how the system is designed to operate, and the cause lies elsewhere, maybe in job structure or workload distribution.

A third, less vocal view says this is just what happens when complexity builds up over time. More jobs, more repos, and more customers pile up until the system is technically functional but practically difficult to manage.

None of these are wrong. They're looking at different layers of the same problem.

The real frustration: no clear answer

What stands out most is the uncertainty, more than any technical detail. Logs don't point to anything definitive, changes don't produce clear improvements, and every fix feels like a guess.

"I feel truly cooked trying to find a solution," the user admits.

That's the part that resonates. Beyond the RAM usage and the failed jobs, there's the feeling of being stuck in a system that doesn't give you clear feedback.

So what's actually going wrong?

There's no single, clean answer, which is uncomfortable. Memory, proxies, and job size probably all play a part. The trouble lies in how they interact: resource scaling, workload distribution, architecture decisions, and maybe subtle inefficiencies that only show up at this scale.

That's what makes it hard to fix. You're untangling a whole system instead of solving one problem.

The bigger picture

The same pattern shows up well beyond this one setup or product. Modern backup systems are powerful, but they're also complex. They scale aggressively, assume certain architectures, and behave in ways that aren't always intuitive. When everything lines up, they work beautifully. When something's off, they become hard to reason about.

The hardest spot is the gray area where things "should" work but don't. At that point you're doing more than managing backups: you're debugging the system that's supposed to protect everything else.