The update file takes minutes to apply. The backup you take before it decides whether a bad day ends in an hour or a week. This is the backup discipline behind every calm Endpoint Central upgrade — the same one the video puts right beside the upgrade steps.
Ask any admin who has run Endpoint Central for years what makes an upgrade safe, and the answer is never the update file. It is the backup taken before it. The video's own topic list puts 'safely take a backup before upgrading' alongside the upgrade steps for a reason: the service pack rewrites application files and migrates the database, and if it stops halfway there is no undo button. This page covers what a real backup includes and how to take one you can trust.
An Endpoint Central server is not a side tool — it holds your patch approvals, deployment policies, inventory history and the trust relationship with every agent in the building. An upgrade touches all of it at once.
Ninety-nine upgrades in a hundred finish cleanly, and that is exactly the trap: the hundredth is the one people remember. A backup converts that hundredth from a disaster into an inconvenience.
The strongest single option for a virtualised server is a VM snapshot or full machine backup — it captures the application, the database and the configuration in one consistent moment. If the server is physical, use your normal server backup tool and make sure the Endpoint Central installation and its database are both in scope.
Two small extras earn their space: a copy of the installation folder, and the PPM file you are about to apply, stored with the backup. If you ever need to rebuild to the same point, having the exact update file beside the backup saves a hunt.
Timing matters. Take the backup inside your maintenance window, when you can also stop the Endpoint Central services first — a snapshot of a database that is mid-write is weaker than one taken while the product is quiet.
Label it properly: date, and the build number you are upgrading from. Six months later, 'backup-final-v2' tells nobody anything; 'pre-upgrade, build 11.4.25xx, October' tells the whole story.
You do not need to rehearse a full restore before every hotfix — but at least once, prove the path works: restore the snapshot to an isolated VM or check that the backup opens and its contents are complete and recent.
At minimum, verify the backup job reported success, the file sizes look sane, and the timestamp is the one you expect. Most 'the backup failed too' stories are really 'nobody looked at the backup' stories.
There is no supported 'uninstall this service pack' route that rolls an Endpoint Central server back a build. The supported way back is the one you prepared: restore the server to its pre-upgrade state and let the agents reconnect to the build they already know.
After a restore, verify the console build number matches the old one, check that agents are checking in, and only then plan the upgrade again — this time with ManageEngine support involved and the failed attempt's logs in hand.
Backup first, services stopped, UpdateManager, verify — see the whole calm sequence before your next maintenance window.
▶️ Watch Full VideoIt is the strongest single option for a virtualised server because it captures the whole machine at one moment. Pair it with the product database in scope and take it with services stopped for the cleanest copy.
At least until the upgraded server has run cleanly through a full patch cycle and a complete round of agent check-ins — most admins keep it a few weeks, clearly labelled with the old build number.
A folder copy alone can miss the database state. Treat it as a supplement to a snapshot or a proper backup, never as the whole plan.