Having been a Unix systems administrator for about 20 years and “in the IT business” for more than twice that time, I have always been aware that that tedious task of backing up your data can pay off in the end. As we say, there are two types of computer users: those who have lost valuable data and those who will lose valuable data. But, backups can help.
The other day, while between crises at Chaos Central, our home/office/workshop, I was browsing through the web statistics for our public sites and actually paid attention to the list of ‘404’ (File Not Found) errors. Now, a lot of these are the usual and customary web site attacks that go on all the time, “bad guys” probing for security holes that a) don’t exist because we are not using Microsoft Internet Information Server, or b) have long since been plugged in Apache, so I more or less ignore those, along with the blind probes for informational pages to gather email data to feed SPAMmer’s address lists. But, since I have been using Google’s Webmaster Tools to aid in Search Engine Optimization (SEO) for my clients, I’ve paid a bit more attention to little things, like having a ‘robots.txt’ file even if I don’t have any pages I want to hide from the search spiders. Another one is the ‘favicon.ico’ file: you don’t need one, but browsers always ask, so it is nice to have one. Besides, it adds a distinctive icon to the address bar, tab, or ‘favorites’ list, so I have been creating those tiny graphics and adding them to sites as well.
But, this time, I also noticed missing pages where there shouldn’t have been any. Oh-oh. Until sometime last year, we had a number of links from our public server pages to our ‘extranet’ server located in our home office and port-mapped to our external router. Some issues with our Internet service at home and our impending move made it imperative to move these pages onto our public servers, which I more or less did, in bulk, to a virtual server, and changed all the links to point to the new location. I had thought I had tested all of the links, but here we were, many months after the transition, with a broken link. An entire page and all of its images, gone.
Meanwhile, the old extranet computer had not survived the household move. After sitting in a cold, damp basement for a month or so last fall, it refused to start. But, we still have the last set of backups! So, I extracted the files from the backup archive and uploaded them to the web site.
For the record, we are, of course, a Unix shop, running mostly Solaris and Linux, so we use Amanda, the open-source backup system from the University of Maryland, and backup to virtual tape on cheap USB drives. The drives are large enough to keep several weeks’ worth of backups, and we archive the last backup set from “retired” machines. For machines like my Linux laptop, that aren’t necessarily on or even in the network 100% of the time, I use rsync, freezing a checkpoint now and then, since we do upgrade Ubuntu versions, and we keep a pre-upgrade backup as well as current ones. Because the Amanda backup runs daily, but we do a lot of work during the day, we also keep a snapshot backup (using rsync) every couple of hours during the workday on our main server/workstation. For our one seldom-used physical Windows machine, we simply copy our working directories onto a file share on one of the Unix systems.
So, there are many ways to do backups, but it is important to do at least one of them, whether or not it seems to be a pain–it will pay off. Oh, yes, I am in the group of users who have lost data–in my case, I archived data, then failed to make a second copy before the orginal archive failed. And, just because I’ve lost data once, doesn’t mean I won’t again, backups or no backups. But, keeping good and current backups does reduce the chances that it will be soon or extensive.