Set every PC to back up at 2 AM and you have not made a schedule — you have made a traffic jam. Forty machines imaging at once will saturate the network, choke the repository, and still be running when staff arrive.
Site Manager's central scheduling is its biggest advantage over standalone installs — and the easiest to misuse. The console will happily queue hundreds of jobs, but your network and repository disks have real limits. Good schedule design is mostly arithmetic and a little empathy: measure how long one backup takes, give machines start times spread across the night, and keep the frequent intra-daily backups for the few computers whose data truly changes by the hour.
From your pilot PC you already know the two numbers that run this whole page: how long a full backup takes and how long a daily incremental takes on your real network, writing to your real repository. Multiply the incremental time by the number of machines that will run together — that is your congestion. If one incremental takes 8 minutes and twelve machines start together, the repository is not doing twelve 8-minute jobs; it is doing one long shared struggle. Staggering is simply refusing to start that fight.
The classic pattern still works: one full image a week, incrementals on the other days. Incrementals only store what changed, so they are small and fast. Site Manager also supports intra-daily backups — as often as every few minutes — and this is where restraint matters. Intra-daily makes sense for a billing server or a design machine mid-project. For forty ordinary desktops it multiplies repository load and storage churn to protect data that changes twice a day. Frequency is a cost you pay in disk and network; spend it where the data earns it.
Real fleets miss slots: laptops go home, desktops get switched off at the wall, the night cleaner unplugs things. A schedule that only works in a perfect office fails in yours. Run backups in the early evening for machines that are reliably on then and off at night, enable wake features where your hardware supports them, and check the console's missed and failed list every morning for a week after go-live. The pattern of who misses tells you how to re-time — that feedback loop is the actual design process.
Server install, agent push, backup definitions and schedules — the whole Macrium Site Manager deployment, live and step by step.
▶️ Watch Full VideoAfter the last person reliably leaves and early enough to finish with slack before the first person arrives. For most offices that means starting server backups around 1 AM and desktops in staggered groups after. If your office works late, an early-evening incremental plus a later full pattern often fits real life better than one midnight block.
Usually one of three things: too many machines starting together and strangling each other, full backups colliding on the same night, or one very slow machine — an old PC or a bad network drop — holding its group open. The console shows per-job duration; find the outlier before you move everyone's start time.
Wi-Fi backups work but are slower and easier to interrupt when the laptop sleeps or roams. If your laptops dock with wired network at desks, schedule for docked hours. If they are mostly remote, accept Wi-Fi, use smaller more frequent incrementals, and check their success rows in the console weekly — remote laptops are the first to drift out of protection.