Macrium Site Manager Repository Planning Where Backup Images Should Live
Every backup definition you create points at one place: the repository. Pick that place badly — a nearly full NAS, a slow share, the same disk as the server — and every schedule built on top of it inherits the mistake.
✍️ Technical Anshu🪟 Windows / Windows Server⏱️ 8 minute read
🎥 Watch the full Macrium Site Manager deployment in the video, step by step
When a Site Manager deployment disappoints, the post-mortem almost never blames the software. It blames storage: the repository filled up in month two, or restores crawl because images live on a busy file share across a slow link. The repository is simply the folder or share where agents write their backup images — but it is the foundation of the whole system. Decide it first, size it with real numbers, and the rest of the deployment gets easy.
✅ Measure one real full image and one real day of change before you buy any disk
Example numbers only — your office figures come from one pilot PC, not from a brochure
1
The Three Honest Places a Repository Can Live
Disks inside (or attached to) the Site Manager server. Fastest and simplest. Best when the server is a real machine with room for proper drives — and the images then sit next to the server, so protect that room.
A NAS on the same LAN. The most common office choice. Easy to expand, shared with nothing else if you are disciplined. Speed is whatever your network gives it — gigabit wiring is the practical minimum.
A share on another server. Works, but you are borrowing: when that server is busy, rebooting or itself being backed up, your backups queue behind it.
What never belongs on the list: a folder on the same PC being backed up, and a USB drive that someone unplugs. A repository must be on a different machine than the PCs it protects, on storage that stays put.
2
Size It From One Pilot, Not From Hope
Repository maths needs exactly two measured numbers:
Back up one typical PC and note the full image size — office PCs with Windows and apps usually land far below their disk size because images store used data, compressed.
Run its backup again the next day and note the incremental size — that is one day of real change in your office.
Multiply: (full image × number of fulls kept) + (daily incremental × days kept), per PC, then add all PCs together and add at least 30 percent headroom.
The retention guide on this site works this formula through with real numbers. The point here: do this before choosing the NAS or the disks, not after the first "repository full" night.
3
Speed and Separation Rules That Prevent Pain
Gigabit end to end. Repository, switch and server on gigabit at minimum — a single 100 Mbps hop quietly turns a 20 minute backup into hours.
Nothing else lives there. A repository that doubles as the office file share fights users all day and fills with things that are not backups.
One repository per site. Branch offices should write to local storage and sync if needed — imaging across a WAN or VPN all night is how backups get cancelled.
Credentials with intent. The repository share should accept the backup service account — not "Everyone, full control". The security guide covers locking it down properly.
4
Plan the Second Copy on Day One
A repository is a single point of failure wearing a backup costume. From the first week, decide how a copy of it exists somewhere else: sync the repository to a second NAS, rotate external drives off-site, or replicate to cloud storage. Site Manager repositories can be synchronised to remote storage as part of the platform's tooling — what matters is not the mechanism, it is that the copy exists and is tested. If that sentence makes the project feel bigger, that is because real backup is bigger than one box.
🔴 Never let the repository be the only copy AND the fastest disk in the building. The first ransomware incident in an office goes looking for exactly two things: the file shares and the backups. If both are one share, both are gone in the same minute. Keep the repository isolated and copied — the ransomware protection guide shows the full pattern.
🎥 Watch the Complete Deployment in the Video
Server install, agent push, backup definitions and schedules — the whole Macrium Site Manager deployment, live and step by step.
Can the repository be on the same disk as the Site Manager server system drive?
Technically yes, practically no. The server's own system disk is small, busy, and when it fills up the console, the schedules and the images all suffer together. Give the repository its own volume or its own NAS so backup growth can never strangle the machine that manages it.
Should I use one repository for the whole office or one per department?
Start with one repository per site — it is simpler to size, protect and copy. Split only when you have a real reason: a separate high-security store for servers, or two physical stores because one building houses two independent networks.
How full can a repository safely run?
Keep it under roughly 80 percent. Backups need working room while new images are written and old ones are being merged or deleted by retention, and a repository at 98 percent fails jobs at 2 AM in ways that look mysterious until you check the disk. The dashboard shows repository usage — watch the trend, not just the number.
This guide is based on the Technical Anshu Macrium Site Manager deployment video • Stuck on any step? Ask in the video comments — you will get a reply there 🙏