Backups & updates - yes all the time
Guess I am not the only one out here who, at one time or another, have had experiences with updates that messed things up? Changes applied that (later) lead to unforeseen, if not say unwanted SNAFU's, with the subsequent effect that the only thing to bring back sanity and restore peace is.... a backup? Sometimes even the most innocent looking update can lead to unpleasant results. For this reason few things scares me more than "auto-magic" updates. Like the ones WordPress can do. Frightening concept, to put your (web)fate in the hands on a tired developer who one day (or after a long night), despite running checks failed to test the performance of the update of a module, or something.
While auto-magical services may relieve you of need for attention, this freedom one day may come with a (high) cost. Today's CMS, framework or portal solutions are becoming ever more complex, ever more intricate, and features an increasing number of dependencies and inter-dependencies. When one builds a web solution the core is but one corner stone of the construction, and you quickly implement plug-ins, modules or add-ons to further enhance and improve functionality. And the number of such add-ons and applications is vast, normal average uses may quickly find themselves in the depth of a jungle, a Mirkwood in web-terms.
Clone your website
For anyone who installs and sets up their own solution with a certain degree of complexity, this is "The First Law". As soon as the basics is up and running, with all the gizmos and gears you need, or think you need, your basic lay-out and maybe ditto basic content, create a replica of your site, or a clone. This will later prove useful when you face bigger changes, or there's a need to perform deeper upgrades. Most web applications can fairly easily be cloned by making a copy of the file structure, export your database content (NB! remember to empty cache first!), import it back into an empty database and finally make changes in the config file to adapt the clone to its new source/database, plus a few other things.
Now you have a fully fledged copy of your website, one that, if you follow a sensible/doable procedure, always secures that you have a working copy on which you can perform needed tests, before deeper changes, updates or additional installations.
Configure backup services
If you installed backup services before cloning (quite likely) on the original build, remember to re-configure it so that you run one set of backups for the developer copy, and one set for your production. Test backup integrity and make sure it runs as it should, preferably by a schedule. Create a sensible division on the backup structure. I personally keep a fairly large amount of incremental backups, sometimes 120 days or more. And since I've had "variable experience" with web hosting providers, I also run backups on two levels, one on server level and one on portal level. Have lost count on how many times this has saved me from trouble and made my day.
Sometimes the number of potential SNAFU sources is as many as there are code lines in your application, or stars on a night's sky. When shit happens you might like to have control enough to fix things quickly. Relying only on or being at the mercy of your hosting provider may fix the problem but not in the pace or at the time you'd like things to be done. Therefore, two level of control is a better solution.
For those who don't think it's worth the trouble
Think again. Yeah, alright ... so your website may be so small and insignificant that it doesn't matter. But if you maintain content, maybe a blog, some other personal information that for what it's worth serves a (sensible?) purpose, be smart, secure your presence and resources. If things goes wrong, no matter how insignificant you consider the stuff to be, quite likely you will spend more time bringing things back to normal than it would take to to as suggested above.
As we all know, shortcuts sometimes makes long(er) delays!