Transactional Rollback System for Safe Upgrades

[YamiKnigth]

💾 Transactional Rollback Mechanism for Upgrades

1.1 Backup Prior to Upgrade

We propose extending the update script (updatePanel.sh) to ensure the creation of a reliable restoration point before initiating any changes.

Backup Type	Description	Notes
Database Snapshot	Full SQL dump of the database.	Requires a write lock (or equivalent transactional mechanism) to ensure integrity.
Critical App Artifacts	Copy of essential files: .env, config/, vendor/, migration map.	Packaged as a tarball with checksum for verification.
Metadata	Source Version and Timestamp.	Used as the rollback reference.

Storage Path:

/var/lib/pelican/backups/<version-id>/

Retention: Should be a configurable number of previous versions.

1.2 Admin Rollback Action

Add a control within the Panel's user interface to initiate the restoration process:

System > Maintenance > Rollback to Previous Version

Rollback Process (Sequence of Operations):

1. Stop queue workers and block write operations on the Panel.
2. Ask to Restore or Keep the database.
3. Restore application artifacts from the saved tarball.
4. Clear caches and rebuild application state (e.g., php artisan cache:clear).
5. Restart services and verify basic Panel integrity.

Note: The Rollback process must be atomic, idempotent (executable multiple times without unintended side effects), and logged with structured entries.

---

✅ Expected Outcomes

Goal	Achieved By...
Reduced Critical Regressions	CI-enforced testing.
Failure Recovery After Updates	Transactional Rollback Mechanism.
Reduced Downtime	Automated restoration path.
Faster Releases	Lower operational risk and higher confidence in deployment.

[notAreYouScared]

What in the AI...

[YamiKnigth]

If you'd like, I can upload the original without running it through the AI. I don't speak English natively, so it's in Spanish. If that's a problem for us to discuss this, just let me know and we can figure out how to work it out.

[notAreYouScared]

No its fine.

[YamiKnigth]

Well, this would be a suggestion, since I've noticed that with each release the number of errors or bugs users encounter increases. While I know that a backup can be performed manually, many users don't do it and only run the update script. It would be good to have the option to revert to the previous version in case a bug is affecting the system, at least until the error is fixed.

[notAreYouScared]

A backup of the env and the sqlite database is already done for you and placed in the bacmup folder before anything is deleted/downlaoded. The user failing to make their own backup is a them issue.

I run the upgrade script on my local prod, thats installed via the official guide, and everything works fine. We have no interest in support 2914 different environments with 9274 different configuration, proxies, etc into the mix... thats on them.

[rmartinoscar]

Copy of essential files: .env, config/, vendor/, migration map. | Packaged as a tarball with checksum for verification.

.env, database/database.sqlite (when using this driver), storage/fonts, storage/avatars are backed up, saving config doesn't make sense since its just laravel binds from env() to config() not the actual values, vendor is fully depending on composer.json & composer.lock

Im gonna ditch eval in updatePanel.sh its causing more issues then it solves and see how can i go about the tarball & checksum while keeping it as small as possible.

[YamiKnigth]

Thank you very much for your response. While it's not what I was expecting, I appreciate you taking it into account for future improvements.