SEPM holds your entire security configuration in one database. Losing it means rebuilding every policy from memory. This backup routine is short, built into the product, and ignored by almost everyone until the bad day.
Ask a room of admins when they last backed up their SEPM and the honest ones go quiet. The manager feels like infrastructure, and infrastructure feels permanent, right up to a dead disk or a corrupted database. A complete SEPM backup is three things, not one: the database, the recovery file from install day, and copies stored somewhere other than the manager itself. All three are easy on a calm Tuesday and impossible to invent on a panicked Friday.
The three-piece set. Any one piece alone is a partial backup, and partial backups fail creatively.
The console has the tool built in. On the Admin page, in the Servers area, the local site offers database backup settings: turn on scheduled backups, choose how often, and how many backup copies to keep. Weekly is a sensible floor for a small office; busier sites with frequent policy changes go more often. The setting takes two minutes and then works silently, which is exactly why it gets forgotten until someone checks the backup folder and finds it empty since March. Put a monthly reminder in your own calendar to confirm the newest backup file exists and is growing.
On configuration day, SEPM created a recovery file describing the site. Broadcom's disaster recovery process leans on it: a rebuilt manager uses it to become the same site again, so clients recognise it and the restored database matches. If that file only ever lived on the server that died, your recovery gets dramatically harder at the exact moment you can least afford it. Copy it, today, to your documentation vault or file server, next to the licence file and the install media details. Three small files, one folder, labelled with the SEPM version.
Database backup covers everything, but a second, lighter net is cheap: export your main policies from the console after any significant change, and keep the exports with the recovery file. Policy exports will not rebuild a site, but they will rebuild a Monday. If a single policy gets mangled by a bad edit, importing the last good export is minutes of work instead of an evening of screenshots and memory. Admins who have lived through one policy accident never skip this step again.
Illustrative layout. The address matters less than the rule: none of it lives only on the SEPM server.
Once a quarter, or at least twice a year, prove the set works: build a throwaway VM, install the same SEPM release, restore the database, use the recovery file, and sign in. Time it. That rehearsal is the difference between a disaster recovery plan and a disaster recovery story. Broadcom publishes a disaster recovery procedure for SEPM; follow that document for the real event, and use the rehearsal to learn where your own notes are thin. Write down what surprised you. It will surprise you again otherwise.
The calm sequence, stated loosely because your version's Broadcom document is the authority: install the same SEPM release on the new server, restore using the recovery file and your database backup per Broadcom's disaster recovery steps, then confirm clients check in to the "new" manager as if nothing happened, because from their side, nothing should have. Keep the same server name and address where you possibly can; clients look for their manager where they last found it. The day this works boringly is the day the backup routine earns its keep.
The install video shows SEPM being born. This page is how you make sure it can be reborn. Set the schedule right after your first login.
▶️ Watch Full VideoIt covers the database, which holds policies, clients, groups, logs and settings. You still need the recovery file from configuration day and your licence file stored separately for a full disaster recovery.
Weekly is a reasonable minimum for a small office, more often if policies change frequently. Whatever you choose, verify monthly that new backup files are actually appearing.
No. Broadcom's supported recovery story is the database backup plus the recovery file. A snapshot may help in a pinch, but it is not the documented path and can leave the database inconsistent.