Technical Anshu
Tutorials Blog
🗄️ Repository Security

Protect the Macrium Backup Repository From Ransomware Before It Protects You From Nothing

Modern ransomware does not start by encrypting your files. It starts by finding and destroying your backups — because backups are the reason victims refuse to pay.

✍️ Technical Anshu🪟 Windows / Windows Server⏱️ 9 minute read
🎥 Watch the full Macrium Site Manager deployment in the video, step by step

The repository is the most valuable folder in your office: every PC's entire contents, in one place, writable over the network. That makes it target number one in any serious attack — and also the thing that decides whether an attack is a bad week or the end of the business. Site Manager deployments have real defences available, including one built by Macrium for exactly this. This guide layers them honestly, in the order to apply them.

Repository Defence — Layer Check
✅ Macrium Image Guardian active on repository storage
✅ Repository share uses a backup-only service account
✅ No daily user account can browse or delete images
✅ Second copy of the repository off-site or offline
⬜ Console admin access limited to named admins
The checklist: an attacker who owns a normal user account should still be unable to touch a single backup image
1

Turn On Macrium Image Guardian

Macrium Image Guardian (MIG) is Macrium's own shield for backup files: it watches the repository storage and prevents other processes from modifying or deleting protected Macrium image files — including ransomware trying to encrypt them and a malicious or mistaken deletion. It is offered as part of the Site Manager installation options, and on the machine hosting your repository it is the single highest-value checkbox in this entire guide. Install it where the images live, confirm it reports active, and treat any MIG warning in the console as a drop-everything event.

2

Give the Repository Its Own Credentials — and No One Else's

  1. The repository share should be writable by the backup service account the agents and server use — and readable by almost nobody else.
  2. Your daily admin account, and definitely every ordinary user account, should get access denied when browsing to the repository share. Test this personally; assumed permissions are how repositories die.
  3. Never map the repository as a drive letter on user PCs. What users cannot see, the malware running as them cannot encrypt.
  4. Keep console access tight as well: the Site Manager console can delete backups, so its logins belong to named admins only.
3

Keep One Copy the Network Cannot Reach

Every defence above assumes the attacker is outside your admin accounts. A determined attacker who steals a domain admin password can defeat share permissions and even protection software. The layer that survives that is separation: a copy of the repository that is offline (rotated external drives, unplugged between syncs), off-site, or in cloud storage with its own credentials and versioning. Sync the repository on a schedule, keep at least one generation back, and test restoring from the separated copy during your quarterly restore test — an untested copy is a rumour.

4

The Server Itself Is Part of the Target

Attackers go for the backup server because it holds the keys to every machine. Harden it like it matters: keep Windows and the Site Manager platform patched, limit who can log on to it, do not browse the web or read mail on it, and back up the server's own configuration as part of your repository sync so the console itself can be rebuilt. The goal is boring and specific — when everything else in the office is encrypted, this one machine and its storage should still be standing, holding clean images.

🔴 The test is simple: log in as an ordinary user and try to delete a backup image. If you can, so can the ransomware running as that user on the worst day of the year. Fix permissions until the answer is no — then check again after every repository change.

🎥 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.

▶️ Watch Full Video

❓ Common Questions (FAQ)

Does Image Guardian make off-site copies unnecessary?

No. Image Guardian stops other processes from modifying or deleting image files on that storage, which defeats the common ransomware pattern. It cannot help if the whole server is destroyed, stolen, or fully taken over by an attacker with deep control. Guardian protects the files; separation protects the building. You need both layers.

Should backup images be encrypted?

Image encryption protects the data if repository storage or an off-site drive is lost or stolen — worth it for the off-site copies especially. Just guard the password like a licence key: an encrypted image whose password is lost is indistinguishable from no backup, so store it in the office password vault, not in one person's memory.

Our repository is on a NAS. Does the same advice apply?

Yes, with NAS-flavoured steps: use a dedicated share and a NAS-local backup account that exists for nothing else, disable or restrict other access paths to that share, enable the NAS's own snapshot feature on the repository share if it offers one, and keep the NAS firmware updated. The principles — least access, one unreachable copy, tested restores — are identical on any storage.

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 🙏