Hosting, backups and deployment: how to make a bad release easy to undo
A bad release becomes a minor event when you have tested backups, a staging site, repeatable deployments and a rollback plan. Here is how to set up hosting so you can always go back.
The Gihonix team · · 4 min read
Key takeaways
- A rollback is easy only if you prepared for it before the release.
- Use staging, version control and repeatable deployment, and test your restores.
- Plan database changes carefully, because code can be rolled back more easily than data.
A bad release is easy to undo when four things are in place: every change is in version control, deployments are scripted and repeatable, backups are tested, and the team has a written rollback step. Rollback is a design decision made before the release, not a panic after it.
Every website and application eventually ships a change that breaks something. What separates a minor incident from a lost afternoon is how quickly you can go back. This guide covers the hosting and deployment habits behind that, and our hosting and DevOps service sets them up for clients.
What does a safe release process look like?
A safe process has these steps, in order:
- Changes are made in version control, not directly on the server.
- The change is tested on a staging copy that resembles production.
- A fresh backup of files and database is taken and its location noted.
- The release is deployed with a script, not by hand.
- A short checklist confirms the key pages and actions work.
- If something fails, the previous version is restored using a rehearsed procedure.
Each step removes a reason for the next one to be stressful.
Why does version control matter?
Version control records every change, who made it and when. It means the last known good version always exists and can be redeployed. If code is edited live on the server, there is nothing to go back to. Use tagged releases, so "version from last Thursday" is a precise thing you can name.
What is a staging site?
A staging site is a private copy of your website or application used for testing before changes reach customers. It should run the same software versions as production, with realistic but safe data. Test the things that make money: sign-in, search, checkout, forms and emails. Keep staging out of search engines and away from live payment accounts.
How should backups work?
A backup strategy answers three questions: what is copied, where it is kept and whether it can be restored.
- What: the database, uploaded files, configuration and, where relevant, the server setup.
- Where: away from the production server, ideally with one copy that an attacker or a mistake cannot overwrite. The NCSC's guide to backing up your data recommends this separation.
- Restore: tested at regular intervals, with the time it takes written down.
Two numbers help planning. How much data can you afford to lose, measured in time? And how long can you afford to be down? These tell you how often to back up and how fast the restore must be.
How do you roll back a release?
The simplest approach is to keep the previous release available and switch to it. Many teams deploy each release into its own folder and point a "current" link at the active one. Rolling back means pointing the link at the earlier folder, which takes seconds. Platforms and tools that support this, such as the deployment features in Laravel's ecosystem, make it routine.
For a WordPress site, rollback might mean restoring the previous plugin version from a backup taken before the update, which is why a pre-update backup matters.
What about database changes?
Code rolls back easily. Data does not. If a release changes the database, plan for that separately:
- Make changes in small steps that work with both the old and new code.
- Add new columns before using them, and remove old ones only in a later release.
- Take a database backup immediately before the change.
- Avoid changes that destroy data unless you are certain.
This approach means the old code still works against the new database, so a code rollback is safe.
Which hosting choices make recovery easier?
| Choice | Why it helps |
|---|---|
| Separate staging and production | Safe testing |
| Automated, off-server backups | Recovery after a server failure |
| Snapshot support at the host | Fast point-in-time recovery |
| Monitoring and alerts | You learn of a problem in minutes |
| Infrastructure written as scripts | A new server can be rebuilt quickly |
For the monitoring and care that keeps all this working, see our guide to what a maintenance plan should include.
Work with Gihonix
Gihonix is a software, AI and web development company based in Coimbatore, India. We set up hosting, deployment pipelines, backups and monitoring for businesses in India and abroad. Read about our hosting and DevOps service or contact us.
Frequently asked questions
What is the difference between a backup and a rollback?
A rollback returns the application to its previous version, usually in seconds. A backup restores data from a saved copy, which takes longer. You need both.
How often should I back up my website?
As often as the amount of data you can afford to lose. A shop taking orders all day needs frequent database backups, while a rarely changing brochure site needs fewer.
Do I need a staging site for a small website?
It is strongly recommended. Even a small site can break when plugins update, and staging lets you find that before customers do.
Can every release be rolled back?
Not always. Releases that change or delete data are harder to reverse, so they need extra care, a fresh backup and small, reversible steps.