The full text of the ruling is Verdict in copyright lawsuit.

Since beginning using a digital camera, I have saved images in folders named after the photo date in yyyy-mm-dd format (details are in an earlier blog post). I then also systematically backed up every photo on a series of data DVDs (initially data CDs).

Some perl code and a database table are used to keep track of what's on the backup discs. The discs are stored in a separate physical location as my main hard drive.

Backup hard drive

My DVD backup gives me peace of mind, yet there are over 100 backup discs. If my main hard drive failed, re-creating my image collection would involve a substantial amount of effort. Also, my documents (such as computer code, invoices, development website, and email archive) are not on DVDs because they change too much.

I considered mirroring (RAID 1), but was put off by basic questions about how it worked (did my system need a RAID card? How would I know when one of the drives failed -- would it tell me on boot-up?). My own priority was ease of use and simple recovery; I didn't require the 1-for-1 real-time mirroring of RAID 1.

I eventually settled on buying a single, internal backup drive (750GB) and backing up both my entire digital archive and selected documents (email, code, development website, etc). I relied on the unix/linux "rsync" utility to make the backup, and I'll re-run it often to keep the backup current (no less than once a week). This will allow for easy recovery in the event of another hard drive failure.

rsync

Below is the exact syntax I use for rsync:

rsync -avhr --progress --stats --delete /original/folder/path /backup

Note that there is no trailing slash after the folders in the paths above; this makes a huge difference in the behavior of rsync. The syntax above will copy all of /original/folder/path (including any subfolders) to /backup; if you list backup afterwards you will see a folder named path that has all of path's contents.

The switches I used, -avhr, are for archive (preserves permissions, etc), verbose,human-readable numbers, and recursive (descend into and copy subfolders). The switch --delete means any files discovered on the backup drive that are not on the original drive will be deleted. I want this option so if I delete any old email, for example, it's also deleted from my backup.

My Failed Drives

I got serious about this after loosing two hard drives in the space of a couple months. The first one I lost was my digital image archive (a fairly new drive), and it required a week's effort to re-build the data (most was recovered through a linux data recover program, but the files were not in separate folders and had to be sorted through). I got serious after a second drive crashed shortly after that. It was not an important drive, but it was an illustration of hard drive reliability (or lack thereof). I researched my options, weighed the costs, and settled on the system above. I suspect RAID is better and I may migrate to that later, but this has the advantage of simplicity.

Initial download

After inserting a flash card and mounting the Compact Flash card reader, I run a perl script I wrote to download the images. It gets a listing of all the image files, then scans their exif data to determine the date the photo was taken.

I store my images in date-named folders in YYYY-MM-DD format, so the perl script copies all the images from the flash card to appropriate named folders. Any folders that don't already exist are created on the fly.

The perl script then updates a database table, adding an entry for each image file. The fields include the folder and filename for each image, date and time taken, it's filesize, and md5sum. This table currently has 119,347 entries (as of October, 2008), starting in February of 2000. This table gives each image file a database ID number which can identify it's exact location.

As part of my backup system, I make data DVDs of the image files whenever there are enough to fill up a new 4+GB DVD. I also recently implemented a backup hard drive, which I syncronize with the main drive using rsync.

Sorting into the website

I created a web interface to my image archive which allows me to browse exif thumbnails of the files in any folder in a web browser. This is a perl CGI script which extracts exif thumbnails on the fly and stores them in a folder in another location on the hard drive.

The CGI script allows me to select individual thumbnails (with a checkbox) which I want to process further for including in my website. Reduced versions are generated from the high-resolution originals for the selected files. These are made on the fly using ImageMagick and stored in the same folder as the exif thumbnails.

The remaining steps are the most labor-intensive. Images are grouped into sets, edited down, and the levels are adjusted. Next, they are carefully keyworded and descriptive information is added. They are then entered into the website, and given a website photo ID number. The original file id number is preserved, and still identifies the original digital file in the archive.

This system evolved over several years and different variations, and will probably change further.

There is an extensive chronology of the original lawsuit for defamation brought against me on this site. That litigation eventually included my own copyright infringement claims against the other party, and led to a trial in November, 2007, in federal court (D. Minn). I represented myself and prevailed on my 3 copyright claims the 7 claims against me.

I've set up a web site that discusses this new litigation for malicious prosecution, including a docket of all filings in the case, and a seperate page for major documents/hearings. Visitors can post comments.

Athena (little girl being cute), 2+ minutes.

Athena Athena apple juice for the first time

I have a separate section of this website discussing the malicious prosecution lawsuit and the current Appeal. ]]> Thu, 17 Jun 2010 00:00 PDT