Migrating to Linux, Part 2
Here's a personal story from one of the authors that illustrates exactly why we all must make regular backups. I'll never forget it. It was late at night, and I was on a tight deadline, cranking out a major project for a client. Then, I heard it. A rattling noise, like a backgammon player shaking a cup of dice. Yes, my hard disk had just croaked—I was hearing the heads skipping across the platters in my hard drive. The machine would not reboot, nor could I access any data on the drive. After a few seconds of panic and terror, I tore open my desk drawer and cradled what at that moment was my most prized possession: a recent tape backup of that entire hard drive. The next morning was a flurry of intense activity. I notified clients of a brief delay. I contacted my computer manufacturer (the disk was under warranty) and demanded a new hard disk—of course, it would take 10-14 days. I ended up running out and buying a new disk, installing it, reinstalling all my software and restoring most of my precious work from that tape. Eventually, the manufacturer replaced the dead disk.
The moral of the story? Disasters can and do strike ordinary people doing ordinary things on a computer. Your responsibility is to be prepared. In my case, the hard drive crash was softened from a disaster to an inconvenience, all because I had that backup tape. Fortunately, Linux comes complete with a set of utilities that make backups safe, easy and reliable. Plus, several commercial and free software options exist to automate and simplify the backup process. Ideally, backups should be performed daily. In reality, doing a full backup about twice a week is a reasonable schedule for most SOHO users. Plus, if possible, store every other backup off-site. Even if your spouse or parent takes one tape or disk to work and brings back the other one, you are reducing the risk of losing your backup to fire or theft. Never leave your backup media sitting in the backup device.
If you don't have access to a backup program, Linux has several options to tide you over until you get one. Probably the most used is the tar command, which you should have at least an understanding of, even if you end up using a different backup option. Spend some time looking at the tar man page. Check your Linux manual; most give a fairly thorough analysis of this key backup option. At the very least, until you have a more reliable backup routine, copy key files to a floppy using the cp command.
Assume it's 9 AM on a weekday. Your client expects delivery of a key project by noon. You finished it last night at 11:30 PM, after hours of revision and several pots of coffee. All you have to do now is boot up your machine, print out a final copy and fax it off. Except for one little problem: you machine refuses to boot. Only three hours until your deadline—what now?
Linux will rarely choke, provided you are not tweaking with the system or mucking around while logged in as root. However, some hardware failures can sneak up on you. In any case, you must be prepared to act when your machine doesn't want to boot. That means having and knowing how to use a good set of Boot/Root disks, also known as rescue disks (see Resources).
The Boot/Root disk may one day turn out to be your best friend. While a comprehensive set of instructions are beyond the scope of this article, you need to understand how to use them. Many distributions come with a set of boot disks that double as emergency disks, or you can download a pre-built set. In any case, get them and know how to use them before a disaster strikes.
Now that we have covered guidelines for basic system administration, it's time to think about doing some work. Fortunately, the last several months have seen an explosion in the amount of productivity software—both free and commercial—available for Linux users.
As for the Open Source versus commercial software debate, the choice boils down to the preferences and budget of the user. Most users will end up with a hodgepodge of both free and commercial software on their systems. SOHO users, additionally, have their limited time and accountability to clients or colleagues to consider when making their choice. Our advice is to thoroughly check the capabilities of any software you plan to use.
Let's look at an example. Say it costs you $100 to purchase a piece of commercial software and you figure it will take four hours to install, configure and gain familiarity with the product. Now compare that to an Open Source product. While you pay nothing for the software, it may take you ten hours to install and become comfortable using it. Which product do you choose? It's up to you and your priorities. Just remember: Open Source does not always mean free of expenses, while commercial software can never be automatically assumed to be easier to use or of higher quality. Judge each package by its individual merits and make the right choice for yourself.
Regardless of your choice, we believe it is up to us as SOHO Linux users to provide positive feedback to both commercial developers and the kind souls who develop Open Source packages. Linux is the best SOHO/workstation OS on the market right now, but most commercial developers have yet to embrace it with the support it deserves. On the other hand, we can't expect free software developers to fill all the voids left in the Linux software library. By rewarding those commercial developers who do port their software to Linux, we can encourage others to do so; and by using Open Source software, we encourage the type of cooperation that has made Linux the great OS it is today.
Does this mean any one development model is the best option for SOHO users? No, we are merely suggesting that if you do choose to use commercial software for Linux, please be sure to obey the developers' licensing restrictions and give positive feedback or bug reports on the product, if applicable. If you are using Open Source packages, please consider contributing to such development efforts, by donating your own time or perhaps even financially, if you can.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development