What Happens During Production Rollback

Production rollback reverses the protected database and file changes recorded for the push, then validates that the live site returned to the expected prior state.

Rollback work

• Restore protected database tables in foreign-key-safe/batched order.
• Recreate original table definitions/data where captured.
• Restore modified or removed files.
• Remove files that the update created and that the checkpoint marked for removal.
• Verify protected file hashes.
• Verify the restored extension/Joomla version using database/on-disk manifest evidence.
• Run production route/basic validation and record the result.

Site availability

QCUL coordinates maintenance/site availability around production operations. If an interrupted rollback leaves availability requiring explicit action, use the displayed Restore Site Availability only after understanding the current rollback state.

If rollback cannot finish cleanly

QCUL stops automatic continuation when a rollback exception needs administrator attention. Preserve the checkpoint and saved cursor, correct the database/filesystem/resource problem, then use Resume Undo/Resume Rollback. Do not start a new production push on top of an incomplete restore.

Recovery discipline

When working with What Happens During Production Rollback, keep the independent backup available even if the QCUL checkpoint is valid. The checkpoint is a fast, short-lived update rollback mechanism; if its protected scope, validity window, or verification cannot satisfy the incident, move to the broader recovery plan rather than extending QCUL beyond its promise.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.