Backups, Environments and Access: Hosting Hygiene That Lasts

When hosting goes wrong, the cause is often not the provider but the routines around it. A missing backup, a shared password nobody can change or a change made directly on the live site can turn a small problem into a long one. Good hosting hygiene is a set of habits that make recovery possible and access manageable.

Backups you have actually restored

A backup is only as good as the last time someone restored it. Define what is backed up, which typically includes code, database and uploaded files, how often, how long copies are kept and where they are stored. Keep at least one copy outside the primary hosting account. Then schedule periodic restore tests into a separate environment and record the outcome.

Separate environments

Changes should flow from development to staging to production rather than being made directly on the live site. Staging should resemble production closely enough that tests mean something. Use separate credentials and data where appropriate, and avoid copying personal data into lower environments unless it is necessary and protected.

Deployments that can be repeated

Deployments should follow a consistent process, ideally automated, so the same steps produce the same result. Version control for code means you can see what changed and return to a previous state if needed. Manual file uploads over FTP make both of these harder.

Access belongs to roles, not individuals

Every person who can change the website should have their own account with permissions matching their role. Avoid shared logins. When someone leaves or a supplier relationship ends, remove their access promptly. Keep a list of who has access to hosting, DNS, the registrar, the CMS and third-party services.

Credentials and secrets

API keys, database passwords and service tokens should live in environment configuration or a secrets manager, not in code repositories or documents. Rotate them when people leave and after any suspected exposure. Use multi-factor authentication on hosting, registrar and CMS accounts where available.

Monitoring and alerts

Uptime monitoring tells you when the site is unreachable. Error monitoring tells you when parts of it fail. Certificate and domain expiry reminders prevent avoidable outages. Make sure alerts go to someone who will act on them, not to an unattended inbox.

Updates on a schedule

Whatever your stack, dependencies and platforms receive updates. Agree how often updates are reviewed, how they are tested and who applies them. Urgent security updates may need to happen outside the normal schedule, so define how those are handled too.

Write a short runbook

A runbook collects the essentials in one place: accounts and owners, environments, deployment steps, backup and restore procedures, monitoring, and who to call. It does not need to be long. It needs to be accurate and findable.

Using a migration to reset

Moving to new hosting or a new platform is an ideal time to establish these habits. It is much easier to set up clean access, automated deployments and tested backups from the start than to retrofit them later. Make these practices part of the project scope, not an afterthought.