Backups: Why, What, and How

“You should backup your PC” is an old refrain from many years ago. It was good advice. Of course, back then that meant buying a box of floppy disks and using a backup program – MS-DOS had a backup.com (later versions had backup.exe) that could be used to make sure that if your PC crashed and wiped out or scrambled your data, you could get it back. Some people (including yours truly) actually did this; some even did it on a regular basis. Most, however, had to experience the loss of a complex spreadsheet that they had developed, or their only copy of the great American novel, or some other similarly precious digital file before they saw the real wisdom in backups.

Of course, the next piece of advice was to store the backups “off-site,” which meant taking them to the home of a trusted family member or friend, or maybe taking them to your office (or home, if it was a work backup), or, in rare cases, perhaps putting them into a safe deposit box at a bank. This was to avoid the situation of a fire, flood, or some other catastrophic event destroying your home (or office) that would also destroy your backup. Almost nobody did this. Not even me.

As hard drives became available and, more importantly, reasonably priced (my very first hard drive was a 10 megabyte (yes – 10 MEGAbyte) Plus Development HardCard, which plugged into an expansion slot in the original IBM PC, and for which I paid about $750 back in, as I recall, 1984), it took many more floppies to back up the PC. Several options were developed to make it easier, but all of them still suffered from the “it-needs-to-be-offsite-to-really-be-a-backup” problem.

Today’s cheap, multi-gigabyte hard drives, in readily available commodity PCs, coupled with digital cameras and cell phones with increasingly good cameras mean that many people – maybe even most people – have lots of photos on their PCs that they’d really hate to lose. The size of these hard drives, the number of files, and the complexity of some of their folder structures makes backing everything up a daunting task.

Still, some people do make backups. Unfortunately, many of them are using external hard drives or USB thumb drives to back up their files on a semi-regular basis (when they think about it). That is better than nothing, but those backups will still be destroyed in a fire, or they could be lost or stolen, or the device could simply fail.

So, the “why” of backups is so that you won’t lose all of your child’s baby photos or their graduation of wedding photos, or your only copy of your digital financial records, or all the work on your novel, or whatever in case your PC crashes or your hard drive fails. And this paragraph provides the “what” to back up – anything that would be difficult or impossible to recreate if it was lost, whatever that happens to be. Now, on to the “how…”

And the “how” is continuous, online (aka cloud) backup. The best-known of these it probably Carbonite.com (I am not affiliate with Carbonite and I do not get any kickbacks from them, just so you know), but there are several other good alternatives. This type of backup is basically a set-it-up-and-forget-it approach to safeguarding your files. They are backed up either continuously or every few minutes to a remote server (likely distributed over several geographically dispersed servers), so they are protected from the local catastrophic events described above. You don’t have to remember to make the backup and you don’t spend any time on it (other then the initial setup), which means they’re really convenient. And, starting at around $6 per month, they are pretty affordable.

So, please, you should back up your PC!

Week 10 Project, Part 2a: Back on Track

Last week, I wrote about two problems I had moving my project from PhpStorm to IntelliJ IDEA Ultimate (both from JetBrains.com). To recap (or you can read the entire post here), I could not get the deployment configuration to work (I set it up to sync the local sources with the web server on any explicit “Save All”), and I could not get the built-in web server (in the IDE) to open the site for testing – it was always opening the actual site on the web server (which works, but adds some network traffic and some latency).

The solution to the first problem, described in last week’s post, was for me to use the correct path for the local directory where the sources are located. Duh. As I stated last week, this was not in any way the fault of JetBrains or the IDE; it was all my doing.

The second problem I finally solved after I wrote last week’s post. Again, the fault lies solely with me. When I created the deployment configuration (and finally got it right), I had inadvertently set it up as the default deployment configuration. As the IntelliJ IDEA docs clearly state, if a deployment configuration is marked as the default, it will be used instead of the built-in web server (or any other deployment configuration, presumably). As soon as I unset the default, it went back to using the internal web server when I clicked the “Run” button to test the site.

Yes, I know this is a short blog post. I spent way too much time on these two issues – I should have just read the docs (or searched Stack Overflow) right away. Oh well, next time…

Week 10 Project, Part 2: Rabbit Trail Detour

This week was supposed to find the code complete and the web app up (at dev.kobayashicoding.net) and running. As these things go, however, I found myself doing some DevOps instead of coding.

I use JetBrains tools for development. I’ve been using PhpStorm for quite some time, and recently also licensed IntelliJ IDEA because I want to start learning Kotlin (and maybe even bone up on Java). The interface for these IDEs is pretty much identical (as far as I can tell), so I’ve been using IntelliJ IDEA recently, even on projects that I started in PhpStorm – including this current project.

Somehow in moving from PhpStorm to IntelliJ IDEA, I managed to delete the deployment configuration for this project. JetBrains tools – like most others I’ve used – have built-in FTP and SFTP clients to synchronize the local code with the actual web server, and I set mine up to upload any changed files whenever I do an explicit “Save” of all changed files. When I began working on the code again last week, I noticed that neither was the code being uploaded to the server, nor did I have the usual “Browse Remote Host” pane on the right side of the IDE’s window.

A quick look at the deployment configurations revealed that there were none. So, I spent more time that I should have configuring the settings for the host. This was not JetBrains’ fault – I simply failed to use the correct path to the local folder with the code for the site. Once I realized – and corrected – that, the code got synced and the changes I’d just made magically appeared.

I haven’t been as lucky with the other issue that also appeared. Using PhpStorm, I used to be able to run the local version of the site (I’m not actually using any Php, or anything else that requires a real web server), but the “Run” icon in the toolbar was grayed out. So I clicked the “Configurations” button and looked for the appropriate template to use, but have not yet been able to recreate the configuration I need. I guess I’ll have to actually resort to looking at the docs, or even <gasp> contact JetBrains tech support – which is awesome.

Tune in next week for the exciting continuing saga…