Simple Backup and Restore With Tar

I've got a Linux server that acts as a fileserver, among other things. I have hundreds of gigabytes of data on it, accessible to any of my computers but in a simplified fashion because I'm not duplicating the data on each computer, plus backup is more straightforward because I just need to backup the server. And Linux is great for automation, and for raw processing of files in bulk. ;-)

So, how to back up the data?

I have installed Webmin, which makes backing up directories in the filesystem trivial. With a web form, you can specify everything about your backup: What directories to backup, where to save the backup file, whether you want to just tar it or also bzip the archive; it even handles scheduling it as a cron job, notifying you the results via email, and more.

If you were do to this manually, though, your tar command might look something like this:

tar -c -f /path/of/archive.tar.bz2 --bzip /path/to/backup

You're telling tar, "Please -create a -file at /path/of/archive.tar.bz2, and along the way, compress it using --bzip. The path to archive is /path/to/backup."

I was backing up a 15GB directory and didn't want to make the server spend the extra time compressing all that data, so to save time I did not use the --bzip argument, and so instead it just creates a tar file which I'd name archive.tar.

Great. We're backing up on a regular basis now. I feel much better.

Oh no, I need to retrieve a single file from my backup! How do I do it?

It would be overkill to extract the whole archive, especially when it's really big like my example, when all you need is a single file, perhaps just a few megabytes in size.

Well, if you were to extract the whole archive, you might type:

tar -xvf archive.tar

You're telling tar to extract from the file archive.tar, and be verbose, showing all the files you extract.

Again, that's a waste of time and hard drive space. Instead, --list the archive to find the file you need, and then --extract the exact file by specifying it to tar.

You could just list all the files and try to find your file in the list:

tar --list -f archive.tar

Again, a waste of time. Make Linux do the work. I know the file I need to restore is foobar.txt, so tell Linux to return just that file by piping the archive list into grep:

tar --list -f archive.tar | grep foobar.txt

It crunches through the archive, looking for that file. Finally, it returns, say, "my/path/to/foobar.txt". Excellent! Now ask tar to extract just that single file from the archive:

tar -x -f archive.tar my/path/to/foobar.txt

Now, tar will wade through all the files in the archive, and only extract the single file.

CMS Roundup: Introduction

Over the next few weeks, I am going to review a handful of web content management systems for the community college where I work, and I will be blogging my reviews here in a series called "CMS Roundup". This review will cover mainly ColdFusion solutions, since that is my love and specialty, but a few non-CF packages may sneak their way into the mix.

Scale. I will be reviewing open source, entry level, and mid-market packages, which places the price range from free to $150,000. Enterprise-level solutions in the $200,000 to 7-digit numbers will not be considered because they are ridiculously out of our price range.

Weighted features. There are some features that I will be particularly interested in. The system has to be very easy for a non-technical user to understand. The developer should be able to set up various templates and security for different site areas. The marketing department should be able to enforce page approval and workflow to ensure the accuracy, consistency, and propriety of the content. Easy integration with existing external applications should be simple as well. These are just some of the features that will be considered; the strengths and weaknesses specific to each CMS will be reviewed as well. And I'm sure I'll get a feeling for more desirable features as I progress through the reviews.

The players. My list of CMS's for consideration is a fluid one, so please make recommendations while I'm in the middle of this process. The open source ColdFusion players are FarCry, Gerobase, and Katapult; commercial ColdFusion players are CommonSpot, ShadoCMS, HotBanana, and Savvy. I'll look at a couple non-CF contenders, like Estrada and CrownPeak in the commercial space and Plone, Joomla, and Drupal in the open source space.

Likely, this journey will end with a summary of strengths and weaknesses of all CMS's, including winners in each category, and of course, the name of the CMS that ultimately earned a new customer. ;-)

The game is afoot.

Tale of a Dying iPod

This is a tale in progress of a third-generation iPod nearing the end of its life. No, not by my hands. This poor little guy is dying of natural causes: old age. :-)

The iPod is functional currently, but the most worrisome symptom is this very peculiar screen it displayed when trying to sync a few days ago:

A dying iPod’s call for help!

I didn't know what this screen meant, but after a search on Apple's website, I discovered it is called a Disk Scan Icon. It means that something bad was happening with the hard drive, so the iPod went into a diagnostic mode. The progress bar never moved after 15 minutes, though, so I'm assuming the diagnostics crashed. After a reset, the iPod rebooted normally and worked fine after that.

Before this happened, a few weeks earlier, the iPod started crashing every time it would start a sync. Just a hard freeze. After some fiddling, I figured out that it would work if I plugged it directly into the cable instead of the dock. Once I got it running, I did an iPod restore through iTunes (which wipes out all songs and restores the iPod to its factory condition). Everything has worked fine since then, until the ominous screen above.

Maybe my iPod will die right on time for the release of a multitouch iPod. ;-)

CF8, AJAX, Flex, AIR: There’s Room For Everyone

The ColdFusion community has been paying attention to IT journalism lately, for better or worse, and for good reason. Our environment is especially in a state of flux; many of us may had been concerned about the future of ColdFusion given Adobe's acquisition of Macromedia, but those fears were allayed, especially now with Adobe making it so clear that they have invested respectable time and resources into improving ColdFusion with CF8. But the results of the acquisition are only just beginning to emerge. And as Adobe's strategy becomes clearer, it is very evident that they are putting arguably more resources into other technology like Flash and Flex.

What ultimately prompted my thoughts was the article Web 2.0 Needs Adobe by Tom Yager. His discussion is very flattering for Adobe, although ColdFusion isn't mentioned anywhere. Neither is it mentioned in Cringley's equally flattering article An AIR of Invisibility. There's a reason for this. They're focusing on the user interface of apps, which is really what defines the perception of how responsive and powerful an app can be. Fretting about ColdFusion getting the back seat is like fretting that your favorite athlete wasn't nominated for an Oscar; it wasn't really up for consideration.

So, user interface. Now that's something to fret about. Many of us don't like to think about the UI, and that has to change! User interface has always been important when users form their impression of an app, and that high priority is applying more heavily to web apps as they begin to vie for user acceptance with their heavier desktop brethren.

Most ColdFusion developers are using HTML for their user interface. An industry migration will hopefully migrate that median toward AJAX-enhanced HTML or Flex interfaces for web apps, and of course AIR for desktop apps. ColdFusion won't be going anywhere, as our internet connectivity is always going to need a server-side component.

So how are we to react to these articles' evaluations of AJAX and Flex? In a way, they are depicting JavaScript (and thus AJAX) as a dinosaur with wings. It is powerful, it got a shot in the arm with the popularity of AJAX, and it can do amazing things. But it's still a "dinosaur". It is old technology trying to keep up. Enter Flash and Flex. The new kids on the block. They're more modern--but they've had time to mature--and they just out-perform AJAX in what they can accomplish. Now tack on thoughts about how much AJAX functionality Adobe has put into CF8. What's the point if AJAX is inferior to Flex? What does it all mean?

It's a big internet out there. Various scenarios call for various solutions! Whereas it is a good idea for us as ColdFusion application developers to learn Flex and start using it when UI needs call for it, the ultimate point is that we start improving our UIs from plain HTML. Start putting more effort into the user interface. We've had it easy in the past when simpler, less sophisticated interfaces were accepted on the web, and that time is coming to an end as the web pushes forward as a viable application platform.

Is it urgent that we start learning Flex? I feel that AJAX and Flex will be sharing the web application space for a long time. Yes, Flex and Flash might be Adobe's ticket for bringing web apps to the next level, but their commitment to AJAX is very clear. That is evident in the AJAX support in CF8 and AIR. Learn Flex if you can. If it's just too much for you to handle right now, AJAX is a fine step--more palatable and familiar for HTML developers--that will let you focus on the more important point: Improving your app's user interface.

  Theme Brought to you by Directory Journal and Elegant Directory.