Everything you configure in Endpoint Central — every package, policy, report schedule and audit record — lives in one database on one machine. This page makes sure a bad disk or a ransomware incident cannot take all of it with them.
Ask a room of Endpoint Central admins when they last verified their database backup and the room goes quiet. The product makes backup easy to enable and even easier to postpone, because nothing looks broken while it is missing. Then the server disk fails, or the machine is rebuilt, or ransomware walks in — and the team discovers that inventory history, configurations, software packages, deployment records and the entire audit trail were all one disk’s bad day away from gone. Rebuilding the product takes an hour. Rebuilding months of configuration from memory takes weeks, and some of it — the audit history — can never be rebuilt at all.
The product can be reinstalled in an hour. None of the rows above can.
This is the real content of the backup decision. Almost none of it is replaceable.
A backup that shares a disk — or a fate — with the original is a copy, not a backup.
Location is the whole game. Off the server, or it does not count.
Open the backup settings in the console’s Admin area and turn on the scheduled database backup with a sensible rhythm — daily is right for most offices; weekly is the bare minimum for a small, quiet setup. Let the product handle its own database consistently rather than copying live database files by hand, which can capture a half-written state that restores badly or not at all.
Choose a backup destination on a different machine — a NAS share or a file server — with credentials the server can write with. Then think one step further: if ransomware reaches the Endpoint Central server, can it also reach and encrypt that share with the same credentials? Where possible, protect the backup location with separate credentials and keep one older copy somewhere the server cannot write to at all. Backups that malware can delete are a comfort blanket, not a recovery plan.
A single rolling backup has a quiet failure mode: if the database corrupts on Monday and the backup runs Monday night, your only backup is now a perfect copy of the corruption. Keep multiple generations — a week or two of daily backups is a sensible floor — so you can step back to before the damage, whenever the damage actually started.
At least once, restore the backup onto a spare machine or VM and confirm the console opens with your computers, configurations and reports intact. A backup that has never been restored is a hypothesis. The test also teaches you the restore steps calmly, on a day when nobody is shouting — which is the only kind of day on which restore knowledge is cheap.
Leave a short note where your team will find it: where backups live, how old the oldest is, and the restore steps you tested. Then verify monthly — glance at the backup folder, confirm the newest file is fresh and a sensible size. Two minutes a month is the entire ongoing cost of never having the worst Endpoint Central conversation there is.
Every setting on this page is shown live in the ManageEngine configuration video — watch it once and your own setup becomes easy.
▶️ Watch Full VideoIt offers a scheduled database backup that you must enable and point at a destination. Choose a folder on a different machine, keep several generations of backups, and test a restore at least once — an untested backup is only a guess.
Because the events you are protecting against — disk failure, a rebuilt machine, ransomware — take the server and everything on it together. A backup only counts if it survives the machine it protects.
Effectively your whole management history: computer inventory, configurations, patch and deployment settings, software packages, report schedules, user roles and the audit trail. The product reinstalls quickly; the data does not come back.