Rollback Procedures
Rollback procedures describe how to revert a patch release safely when necessary.
Use this guide to review the rollback options available after patching, including Linux rollback scripts and Windows snapshot restores.
Rollback Scripts/Snapshots Restores
Linux
Patch Management generates rollback scripts on each patched host. These scripts are typically stored under the Breeze Agent directory with a timestamp, so that Cloudaware can:
- Roll back a single host if only one system is affected.
- Execute rollback across a larger group of hosts in a coordinated way.
Windows
For Windows, snapshots are made before patching. Snapshots are retained for 60 days.
When to Roll Back
Consider rolling back when:
- Critical services fail or cannot be stabilized quickly.
- Data integrity is at risk.
- Workarounds are insufficient or too risky for extended use.
Recommendations:
- Follow documented rollback and verification steps in your change record.
- Communicate status to stakeholders and update incidents.
- After rollback, reassess how to address the underlying vulnerability or issue (for example, alternative patches or configuration changes).
Rollback Process
If a rollback is necessary, it can be performed by the application or instance stakeholders, or upon request to the Cloudaware Service Team.
The rollback script is located on every patched instance at the following path: /opt/breeze-agent/os_updater/YYYYMMDDhhmmss.sh. To perform a rollback, run the script on the required instance.
Cloudaware Service Team can perform both instance-level and account-level rollbacks for Linux and Red Hat instances only.
If a rollback is requested, the Breeze agent resets the repository to the previous GUID, executes the rollback script, and verifies the rollback by running yum update against the preview repository GUID. After the rollback script has completed, yum update should not report any package changes on the host.