ManageEngine's own guidance starts every upgrade with the same sentence: ensure a full backup is in place. This page explains what a proper Endpoint Central backup actually contains - and the two backup shortcuts that quietly protect nothing.
Every update guide says “take a backup first”, and most admins nod and take something - a VM snapshot, a copy of the install folder, a database export on its own. ManageEngine's service pack documentation is unusually specific about why two of those three are not a rollback plan. The application files and the database must remain in sync: restoring one without the other can leave the installation in an unusable state. Here is the backup done the way the vendor intends, and how to prove it works before the day you actually need it.
Endpoint Central's built-in backup exists precisely because the application and its database are one system.
The vendor's position, in one panel. The built-in backup is the primary supported method; everything else is an extra.
Endpoint Central includes a Backup-Restore Utility, backuprestore.bat. Run it (or confirm a recent scheduled backup completed) before the maintenance window. It captures the application files and the database together in a single restorable archive, which is exactly what a rollback needs: one action that returns both halves of the product to the same moment in time. One practical mercy: this backup can run while the Endpoint Central service is still running. Stop the service only immediately before Update Manager - so the backup can be taken calmly, in advance, not against a clock.
If the server is a virtual machine, a snapshot is a reasonable additional safeguard - ManageEngine says so itself. But it is explicitly supplementary, not a replacement for the built-in backup. Snapshots age badly, get forgotten, and get deleted by storage policies. Take one if it is free and fast, label it with the date and the pre-update build number, and delete it once the new build has run cleanly for a few days. Never let “we have a snapshot” be the reason the real backup was skipped.
If Endpoint Central uses MSSQL or a remote PostgreSQL instead of the bundled database, a snapshot of the Endpoint Central server does not touch that database server at all. Coordinate with your DBA for an independent database backup - an MSSQL full backup or a PostgreSQL dump - taken at the same time as the application backup. Two backups taken hours apart are the sync problem wearing a disguise.
This is the warning ManageEngine repeats, and it deserves the emphasis: do not rely on a file-only or database-only rollback. Restoring an old application folder against a newer database - or the reverse - can leave the installation unusable, which turns a recoverable failed update into a genuine outage. A rollback is the pair, together, from the same backup, or it is not a rollback.
The honest sentence in backup work: a backup you have never restored is a hope, not a backup. At least once - ideally before your first big upgrade - restore the archive onto a spare VM and confirm the console opens with your computers, configurations and policies intact. You will learn the restore steps for the price of an hour, and you will learn them on a day when nobody is standing behind you. Keep the archive off the server itself, keep it until the new build has survived several days of real work, and only then prune it.
The video walks the complete update including the backup precautions before Update Manager runs. Watch it, then take your backup before your window opens.
Watch Full VideoYes. ManageEngine states the built-in backup (backuprestore.bat) can run while the Endpoint Central Server service is still running. You only need the service stopped immediately before launching Update Manager, so take the backup in advance and keep the window itself short.
No. ManageEngine treats a snapshot as supplementary protection, not a replacement for the built-in backup, because the supported rollback is the application-plus-database archive. A snapshot also does nothing for an external MSSQL or remote PostgreSQL database - that needs its own backup.
You can end up with an unusable installation. The application files and the database must stay in sync, which is why the built-in backup captures both in one archive and why rollbacks should always restore the pair together.