The final presentation at last night’s Tapeless Workflow seminar at the Editors Guild was a discussion of tape backup. Yes, there were chuckles about the irony of a “tapeless workflow” which still requires tape media.

Melrose Mac was touting the merits of LTO-4 tape backup and underscoring its importance for securing production insurance, however I felt that LTO was presented as a near flawless mode of backup.

Unfortunately, it’s not.

Don’t Bet Your Life On It

During the course of my 17-year career building and managing server networks for large and small organizations I have implemented high-capacity backup systems on Windows and NetWare servers (remember them?) using many tape formats: DAT, 8mm, DLT, and the latest LTO.

Despite the lifespan claims of tape media, practical experience has shown me that tape backups are unreliable.

Any time I needed to restore data (for real) the tape backup system didn’t perform. Backup software would complain the catalog was corrupt. Tape media would become unreadable despite previous use.

A few weeks ago I attempted to restore data from an LTO-3 tape which was used 18 months ago – no luck – ARCserve informed me the tape was unreadable. This is what occurs most often despite the vendor, quality, price, format or tape media being used.

I’m guessing the LTO tape (which was created in a different [and defunct] drive) wasn’t readable in the newer unit – so much for standards. Considering that equipment is constantly changing you can’t risk unreadable media when equipment is upgraded.

Parting Thoughts

Regardless, tape is critically important to your backup strategy but is only one component. Suggestions:

• Create at least two copies on tape and external hard drive using media/device from different vendors.
• Fully restore them once a year and create new backup media.
• Rotate your media using a Grandfather, Father, Son scheme.
• Never be without multiple full and incremental backups spanning weeks, months, years.
• Securely store the media in different buildings, campuses, even cities.

This is my experience and, of course, your mileage may vary.

Other Options

Melrose Mac recommended a system from Cache-A which is plug-and-play and writes data in TAR (tape archive) format. Using TAR may eliminate software glitches such as corrupted backup catalogs due to software version differences (i.e.: ARCserve, Retrospect, etc.).

For years I was disappointed with shared web hosting because of slow page loads or spam blacklisting because another user on the same IP address abused their email privilege.

Server performance isn’t an issue with static HTML pages but it’s critical for PHP and MySQL platforms such as WordPress, Gallery, etc. Dedicated hosting was (and still is) too expensive for my budget but I discovered that a virtual server (VPS) provided the control I needed. With proper balancing of customers per server performance should be acceptable.

Unfortunately my experience with HostForWeb’s VPS wasn’t stellar; decent customer support but the performance was terrible. I compiled a list of wants and needs in search of a new web hosting provider.

• Linux VPS
• cPanel based
• Full support for PHP, MySQL, gd library, etc.
• Unlimited domains
• Unlimited bandwidth

The provider I found was Rackforce out of Canada. Mostly self-serve with on-line and telephone support but at $79/month it wasn’t cheap. Tech support was responsive and the server performance was excellent, unfortunately I winced at the fee during the years I was a customer.

Enter the economic downturn of 2009. All good aside $79/month is too much when competitors are offering shared hosting for $5/month. Dare I consider shared hosting again? It must have improved all these years later and the sub-$25 monthly fee was looking attractive. Some things might need to go (VPS and unlimited bandwidth) but others must stay (cPanel, PHP, and MySQL).

I took the plunge with a $24/month reseller plan at HostGator. Middle-tier pricing but a solid feature which met my needs. The cPanel interface is stripped compared to my Rackforce VPS but transferring a Linux hosting account isn’t difficult. A few days later I had everything transferred, DNS updates and all.

It’s been a month and no problems to report. PHP/MyQSL-based services such as WordPress are fast. According to mon.itor.us there is 100% up-time on the domains I’m hosting. Let’s hope I never get mentioned on Digg because the bandwidth fee could bury me. Maybe that’s not a bad thing either.

WordPress 2.7 offers the ability to automatically upgrade plugins as they are released. No more downloading and FTP’ing.

My first experience upgrading a plugin was one of those head scratching moments. I clicked the “upgrade automatically” link and was presented a form asking for connection information.

What sort of connection information? To the plugin developer’s web site or WordPress.org? What user account? There is no documentation at WordPress.org for this feature and the forum posts were of little help.

The obvious solution was the last I tried; you must enter the information for your hosting platform where WordPress lives.

Hostname

myblog.com

Username

myblogadmin (try your hosting admin user account which should be the same as your FTP account for up/downloading of files to your web site)

Password

Password for the preceding user account

Connection Type

Normal (unsecured) FTP or Secure FTP

Behind the scenes WordPress will create a temporary folder inside of wp-content called upgrade.

If you are having trouble with downloading, unpacking, or installing the plugin you’ll need to look at file ownership and/or permissions on your web host. Chris Abernethy provides some helpful insight.

Changing the location of a WordPress installation isn’t as harrowing as it may sound. Although no tools exist to do it automatically, some knowledge of the Linux command line and MySQL makes it do-able. This post is a summary of the steps I performed to relocate my blog folder; this assumes you are hosting under Linux, MySQL, and cPanel. Take a gander at the official Moving WordPress documentation before you begin.

Make a Backup

Be sure to make a backup of your installation.

Change the Current Blog Folder

Rename your existing WordPress folder (i.e.: /journal) to the new name. FTP or ssh (i.e.: mv journal blog) can be used for this.

Update the blog path settings within the admin panel.

Updating Paths in the Database

If your blog posts contain images or links using the old folder they must be changed. There is a simple SQL command which performs a search and replace. I suggest using phpMyAdmin instead of MySQL’s command line.

Take a look at your wp_options table in phpMyAdmin. You may find that plug-ins are using your old path in their settings which may be not accessible through the admin interface.

Don’t Break Trackbacks

If anyone is linking to your blog they’ll be using the old folder name. To ensure those links don’t break with your folder we can use a symbolic link and a 301 redirect.

Login to your Linux hosting account using ssh and navigate to the root folder of your web site such as public_html. Enter the following command:

ln -s /path/to/new /path/to/old

Replace /path/to/new and /path/to/old with the absolute folder names. For example:

ln -s /home/your-domain/www/blog /home/your-domain/www/journal

You may be tempted to add a redirect using cPanel but don’t – the symlink above is doing this for you.

Unfortunately, permalinks still won’t work. For example, a permalink of http://your-blog/journal/2008/06/my-post will generate a 404 Not Found instead of redirecting to http://your-blog/blog/2008/06/my-post. Don’t bother with the Redirection plug-in because it doesn’t build a library of prior permalinks.

Instead, use Alexandra’s technique to modify your .htaccess file and all of your old permalinks will 301 properly.

If you’re attempting to run an installation of PHPlist alongside Drupal you’ll find PHPlist complains about settings for magic quotes. I can’t vouch for the completeness of this fix but it gets rid of the errors without breaking anything else.

Assuming you installed the lists folder in the root of your Drupal site, you’ll find that an htaccess file in your Drupal install is changing the magic quotes values which are impacting PHPlist. You can override this for PHPlist using another htaccess file. Navigate into the lists folder for PHPlist and create an .htaccess file with the contents:

# Changes for PHPlists running on a Drupal installation

php_value magic_quotes_gpc        1
php_value magic_quotes_runtime    0

Word of warning: don’t modify your host’s PHP.INI for these settings as it will likely break something else if you host multiple domains. In my case it broke WordPress so stick with the htaccess method.