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.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- Readers' Choice Awards
- What's the tweeting protocol?
- BASH script to log IPs on public web server
2 hours 24 min ago
6 hours 39 sec ago
- Reply to comment | Linux Journal
6 hours 33 min ago
- All the articles you talked
8 hours 56 min ago
- All the articles you talked
8 hours 59 min ago
- All the articles you talked
9 hours 1 min ago
13 hours 25 min ago
- Keeping track of IP address
15 hours 16 min ago
- Roll your own dynamic dns
20 hours 30 min ago
- Please correct the URL for Salt Stack's web site
23 hours 41 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?