Hopp Solutions

Cloud and infrastructure engineering for business-critical environments.

Case StudiesInsightsAboutContact
ENDE
Book an Infrastructure Review

Case study | Backup & recovery

Improving Microsoft 365 backup capacity and workload distribution

A single Microsoft 365 backup server had been carrying proxy, repository and job control for an entire tenant. As SharePoint and Teams data grew, jobs stopped finishing inside their window and repository capacity became the limiting factor. A dedicated proxy and repository design moved the load off the primary server and gave each workload a clear owner.

Client context

One backup server protecting an entire Microsoft 365 tenant.

Exchange Online mailboxes, SharePoint sites, OneDrive accounts and Teams content were all protected by a single backup server that also acted as its own proxy and repository host. The design was sound at the data volume it was built for. Growth in SharePoint and Teams changed what that one server was being asked to do every night, and the symptoms showed up as job duration and storage consumption rather than as failures.
iamgeshadow

The challenge

  • Bring nightly backup jobs back inside their operating window as tenant data continued to grow.
  • Relieve a single server that was carrying proxy, repository and job control at the same time.
  • Give high-load SharePoint and Teams jobs their own processing and storage path.
  • Plan repository capacity against measured growth rather than the volume the design started with.
  • Keep protection and retention unbroken while jobs and repositories were reorganized.
  • Replace one large job scope with sets that map to identifiable owners.
  • Leave a model the client could extend without redesigning it again.

Constraints

The conditions the redesign had to work within.

icon

A fixed backup window

Processing had to complete overnight, and adding more parallel tasks to the existing server would have increased contention rather than throughput.

icon

Repository capacity

Storage was approaching its practical limit, so the design had to separate growth-heavy workloads from the stable ones.

icon

Service-side limits

Microsoft 365 applies its own throttling per tenant and per workload, which caps how much faster any single job can be made.

icon

Unbroken protection

Jobs, repositories and retention had to be reorganized without leaving any workload unprotected in between.

Hopp Solutions approach

01

Baseline of the existing backup

Measure job durations, object counts, change rates and repository consumption per workload to establish where processing time and storage were actually being spent.

02

Workload separation

Split protection by workload class so that SharePoint and Teams, the two fastest-growing and slowest-processing sets, no longer competed with mailbox and OneDrive jobs.

03

Dedicated proxy design

Introduce separate backup proxies to take processing off the primary server, sized against the object counts each workload actually produces.

04

Repository layout

Assign repositories per workload and retention profile, so capacity planning and future growth apply to one clear set of data at a time.

05

Controlled migration of protection

Move jobs onto the new proxies and repositories in stages, verifying coverage after each step instead of cutting the whole tenant over at once.

06

Restore validation

Confirm item-level restores from the new repositories for every workload, because a redistributed job is only finished once a recovery from it has been proven.

07

Documentation and handover

Record the job map, proxy roles, repository ownership and the growth thresholds that should trigger the next capacity step.

Outcome

Backup processing was distributed across dedicated proxies and repositories, and jobs returned to a predictable window.

The primary server was relieved of the processing it had accumulated, SharePoint and Teams protection moved to its own path, repository capacity was planned against measured growth, and the client received a documented model with named ownership per workload.
iamgeshadow

Outcome by area

Outcome areaResult
ProcessingBackup workload distributed across dedicated proxies
StorageRepositories aligned to workload and retention profile
High-load jobsSharePoint and Teams protected on a separate path
RecoverabilityItem-level restores validated per workload after the change
OperationsJob map, ownership and growth thresholds documented

What made the project work

  • iconMeasuring the existing jobs before changing them, rather than adding capacity on assumption.
  • iconSeparating workloads by how they behave, not by how a console happens to group them.
  • iconTreating repository capacity as a planning input with a threshold, not a number to react to.
  • iconStaged migration of protection, so no workload was ever left without a valid job.
  • iconRestore testing as the completion criterion for each workload.
iamgeshadow

Technology areas

  • Microsoft 365
  • Exchange Online
  • SharePoint Online
  • OneDrive for Business
  • Microsoft Teams
  • Veeam
  • Backup proxies and repositories
  • Windows Server
  • PowerShell

We can baseline the current design, separate the workloads causing contention and plan repository capacity before the next growth step forces the change.

Hopp Solutions

Cloud and infrastructure engineering for business-critical environments.

Based in Ohrid, North Macedonia. Supporting organizations and technology teams across Europe.

Copyright 2026 Hopp Solutions Dooel. All rights reserved.