Musings on Photography

In my posts on backup strategy, several comments asked if I’d looked into online backup services. Such services don’t work for me, because the internet connectivity I buy is metered and costs me about $.005/megabyte transferred. Getting a different internet access provider isn’t currently an option because I live in a remote spot and this provider is pretty much the only way to get fast network access (although that might change in the near future).

But there are other issues with such online backup services beyond the costs of transferring the data. The best wrapup I’ve seen is this article by James Duncan Davidson, which goes into the whole business in depth. Don’t just read the article, some of the comments are insightful as well.

Bottom line: for most of us who don’t have access to huge bandwidth and who need to store large amounts of data, online backup services are probably not going to be the answer.

The photo above is the Mac Mini based fileserver described in this post. The square white thing under the disk drive to the right is a bit of styrofoam packing material I stuck under the disk drive because the vibrations of the disk drive were making the countertop resonate and filling the room with a loud hum. The big off-white thing to the left is a UPS (uninterruptible power supply) that can run the server for about fifty minutes from the battery. (I could probably have gotten by with a smaller UPS; it only has to keep the server alive for the 30 seconds before our backup generator kicks in. If the power is out for more than about 40 seconds it means the generator failed to start, so the server is actually configured to shut down gracefully after three minutes on battery.)

Several folks have asked what I do for offsite backups. Since I just ordered new gear to revise my offsite backup scheme and make it easier to keep up, I’ll detail the new scheme.

What I bought were two one terabyte Western Digital MyBook external disk drives. Western Digital offers a confusing array of Mybook models which vary in case color, shape of the status lights, and a minor change in case dimension, all of which are of little importance to me. They also differ in the format of the filesystem the disk ships with; I always reformat a disk before using it (after reading about disk drives shipping from factories pre-infected with viruses), so that part doesn’t matter to me either. And finally, the important variation - the variety of interfaces the external disk can support. Nearly every combination of USB 2.0, Firewire (aka IEEE 1394a), Firewire 800 (aka IEEE 1394b), and eSata is offered. In general I choose the disk model with the largest number of interface options, to preserve my choices into the future. This most recent purchase, though, I bought the MyBook Home Edition, which gives me USB 2.0, Firewire 400, and eSata, but not Firewire 800. That’s because a) the Mac Mini doesn’t have Firewire 800, and b) I was able to exploit a price break.

So here’s my basic plan:

1. To start, I copy everything onto one of these disk drives. I then give this disk to my friend Bryan, who generously stores it in his house.
2. Then, once a month or so, I take the disk I still have, copy everything onto it, and exchange it for the one at Bryan’s house. The new disk goes back to Bryan’s place, and the one that had been at Bryan’s comes home, to be used the next time around.

This way, if some calamity results in the loss of every copy of data stored on the redundant servers at my home, I can go, get the disk from Bryan, copy it off that (now very precious) disk, and I’m up and running without any data loss. What sort of calamity might cause me to lose everything? The two big risks are probably a fire (my home was threatened by a forest fire just a few days after we moved in), or a burglary where the burglars are very thorough and make off with ALL the disks that comprise my redundant system of servers and workstations.

You can reduce the risk even further, by having multiple offsite copies. You don’t need to add two disks for every offsite copy. If you want N offsite copies, you’re fine with N+1 disks; you stagger the replacement and so you only need one extra disk beyond the disks stored offsite.

Finally, the reason why I don’t have one disk for each offsite backup, and go and get the disk, write a fresh backup onto it, and then replace it offsite - that’s because I know that what will happen is I’ll retrieve the disk, then it will sit around for a while before I remember to write a fresh copy, and then more time will elapse before I remember to put it back at the offsite location. In the end, if I do this, the offsite disk is actually offsite a small fraction of the time - and thus doesn’t offer any increased protection.

I’ve looked into doing offsite backup on a offsite server, transferring the data via my internet connection. Since I pay for the bandwidth I use, this ends up being an expensive option for me.

A final note: in the past, my offsite backups were written by the FreeBSD server, and thus used the native filesystem for FreeBSD. This caused me some anxiety (I can’t read those disks on any other of my computers) and some moderate amount of hassle. In the future the offsite backups will be written by the Mac Mini, and will be in the Mac native filesystem (HFS+) so that I can just plug the disk into any Mac and get at the data. This is one more reason for shifting away from the FreeBSD server. And although in theory you can plug a USB disk into the ReadyNAS NV+ and write a backup to it, I’ve never been able to get that to work. Beyond the fact that I had the keyboard, mouse, and monitor, it’s another reason why the Mac Mini based server system isn’t headless - having a keyboard, screen, and mouse makes it easy to do things like write the offsite backups when needed.

I’ve mentioned my mass storage solution previously, in this post. In that post, I indicated that the Freebsd fileserver was aging, and that I’d bought an Infrant Readynas NV+, and filled it with 320GB disks in a RAID configuration, and it was providing a redundant file server.

Well, it turned out that that plan didn’t go quite as smoothly as I hoped. Infrant, the company that was selling the Readynas line, was bought up by Netgear. There have been a few reliability issues with the Readynas NV+, but the big problem hasn’t been reliability, it’s been performance. Performance from a machine using the ReadyNAS as a file server was slower than the Freebsd server. The difference in performance was enough that instead of doing what I’d planned, and making the Readynas the main fileserver, and having the Freebsd machine serve as a backup/hot spare to the Readynas, I ended up keeping the Freebsd machine as the frontline server, and the Readynas was kept in sync with the Freebsd machine to provide EXTRA redundancy and to serve as a hot spare should the Freebsd machine lose its cookies.

This was all fine, but the Freebsd machine has really gotten old. It’s built from commodity parts, assembled by me (and my friend Rob), and during 2007 I was becoming increasingly nervous about it. Performance was good - not good enough that I didn’t keep things on local disks on the various computers around the house, but good enough that it didn’t bother me too much. The big problem, really, was that keeping the ReadyNAS in sync with the Freebsd server was a pain, mostly because the ReadyNAS just doesn’t have enough cpu horsepower to make the synchronization tool I wanted to use (rsync) work well. Add to that the disturbing fact that it’s come to light that the Readynas is somewhat prone to power supply failures, and it was becoming increasingly clear that I needed some way out.

In essence, what I needed was:

• a solution with filesharing performance (using either the Windows CIFS protocol, or the Apple AFS protocol) as good as or better than the Freebsd server.
• Something quieter than both the Freebsd server (which sounds like a jet taking off) and the Readynas (which has developed an annoying buzz).
• Something that minimized the amount of software I had to stay current with
• Preferably something physically small
• Something that doesn’t consume much power, particularly when idle (which is most of the time)
• Something where, if something happens to it, I can pretty much go out, buy the hardware off the shelf, bring it home, plug it all together, and having it running quickly

Around the middle of 2007 when I switched to Macs, I was already leaning toward putting together something based on a Mac Mini and one of the Western Digital MyBook dual external disks in mirror mode. That setup provides networked redundant disk storage, just like the firebreathing Freebsd server, and the Readynas.

Not long ago, I reported that I’d bought the external disk. I played around with it some, found it satisfactory, and planned on buying the Mac Mini soon. Well, just after Christmas, I did just that. It took surprisingly little time to set it all up, and in less than an hour I had it running as a file server, with one big filesystem on the Western Digital external disk.

Performance wise, this setup beats the (constructed specifically as a high performance file server) Freebsd machine handily by a pretty significant margin - initial benchmarks have it between 1.25x and 8x as fast as the Freebsd machine depending on task. It’s so much faster than the Readynas that I haven’t even bothered to actually measure the difference. And rsyncing to the Freebsd server it’s very fast.

So my assessment now is that the Mac Mini setup hits every single one of my requirements: fast, quiet (nearly silent, in fact, except when the MyBook Pro fan runs), it runs Mac OS X just like all the other Macs in the house, it’s tiny, consumes little power, and I can drive to the Apple store and actually buy the Mac Mini and the external disk right off their shelf.

I’m just so impressed by the Mac Mini - such a great performer in such a small package at such a competitive price, and it seems very nicely made. (I bought the 1.83Ghz version with the 80GB disk drive and 1GB of memory, $600 plus tax) The whole thing is just so simple - no muss, no fuss.

So now, I’ll retire that old FreeBSD server. The Readynas will continue in it’s duty of being a backup to the Mac Mini fileserver and being a hot spare. If the Readynas fails, it will get replaced with another Mac Mini.

While I was traveling in China, on several occasions I had big photography days where I ended up with one or more really full memory cards. Recall that I was using 4GB Lexar 133x SDHC cards, and a little USB SDHC reader that came with the cards.

This gave me an opportunity to learn an important lesson. Copying 4GB of raw files off one of those SDHC cards was fast. Here, you may interpret ‘fast’ as meaning ’so much faster than copies off of my 80x CF cards using my USB CF reader that I was actually worried that I hadn’t gotten all the data off the card.’ I haven’t benchmarked the speed of the SDHC cards/SDHC reader against my CF cards and the CF reader but I expect the difference is a factor of at least four, and perhaps quite a bit more.

The difference is certainly a whole lot larger than comparing the 133x and 80x would lead you to expect. The enabling feature, apparently, is that the SDHC cards and the reader for them are UDMA capable.

Now, I don’t think this is a breakthrough that’s going to revolutionize photography. But the speed improvement is enough that, when I was copying images off the card onto my laptop, I noticed that it was only slightly slower to copy them off the SDHC card than copying them to my external hard disk to back them up. That’s pretty darn fast - and the speed means that you can sit and wait, as opposed to starting the copy, and then heading off to some other task while the copy runs.

I haven’t yet popped $120 a card for new CF cards to go in the EOS-5d, and another $40 or so for a UDMA capable reader. But I’m real, real close.

What I’ve come to think of as the Big Switcheroo is now winding slowly down to a close. Essentially all of the household computing is now done on Macs. We still need to replace one Windows machine with an iMac, but that will come soon enough. To my delight, Paula has cottoned on to the Macs without any pain at all.
Some amount of the struggle was finding replacements for various tools I’d accumulated in Windows world, especially with regard to backup and synchronizing files on multiple machines.

On all the Windows XP machines, the important stuff off each machine was backed up to one of the file servers daily, using SyncBack. So far, the replacement I’m using for the same function with the Macs is Chronosync, which does much the same thing. Chronosync seems sufficiently flexible for my needs.

For email, Microsoft Outlook has been replaced with the standard Mac mail.app, which we are finding to be pretty nice. Moving the HUGE archive of email from Outlook to mail.app was an epic struggle, involving drinking of mystic potions of dubious origin, much girding of loins, and winding myself up like a Berserker. Oh, and the help of O2M, an application that runs on windows, grovels over your Outlook folders, and spits out files in a format that can be imported by mail.app. Well, it does that, unless your folder is really big. More than, say, 4 thousand messages and all bets are off. A large portion of several days was spent in battle with the email stored on various Windows machines, breaking up large folders into smaller folders and moving the email. Of all the things involved in the switch, moving our enormous archive of email (think hundreds of thousands of email messages) was by far the biggest hassle. All the hassle was on the Windows side, by the way.

The composition window on wordpress.com, which is WYSIABNQWYG (what you see is almost but not quite what you get) if you happen to be using a browser other than Safari, reverts to HTML mode only if you’re using Safari. Since we use Safari, this was the goad needed to force me to investigate offline blog software. After a brief, abortive try with Qumana, I seem to have settled down fairly happily with Ecto which I picked because, like Qumana it runs on both the Mac and Windows platform, and at the time I picked it I was still suffering from the delusion that I might still run Windows in some places. Recently MarsEdit has come to my attention and I’ll probably check it out when I get to the fabled time when things settle down somewhat.

On Windows, I used the RSS features built into Windows Explorer. On the Mac, I dabbled with the RSS features in Safari and promptly concluded that “that way madness lies, let me shun that”. After evaluating both Newsfire and NetNewsWire, I settled on NewsFire. After a few weeks with that, I complained about it here on the blog, and several readers pointed me back to NetNewsWire, so I gave it another try. At this point, I’m sold, mostly because of its ability to display blog posts in the context of the blog, and not just text on a page.

One of our file servers is an aging machine running FreeBSD, with a large RAID filesystem. It’s getting to an age where I’m starting to think about replacing it, so some thought has been given to what I might replace it with. As it currently stands, I could replace this huge, firebreathing (the server is fairly noisy) system with a Mac Mini and one of these Western Digital MyBook Pro II external disk drives configured in mirror mode for redundancy. At current street prices and choosing the least expensive Mac Mini, this would give me a fileserver which would outperform the FreeBSD server and would be relatively inexpensive for what you get - one terabyte of fairly high performance redundant networked storage. One big advantage is that, if the building catches on fire, you grab the external disk and run. The fact that it runs a commercially supported OS and I can replace the Mac Mini just by driving to the Apple store and forking over bucks rather than by assembling the machine myself is a plus. The fact that it would be almost silent and consume about 1/5 the power the BSD machine does is also a plus. Folks who are lusting after NAS that performs a bit better (and is more capable and configurable) than the current crop of fire-and-forget NAS units might want to give the Mac Mini approach a ponder.

For photo editing, I’m using Photoshop CS3. It’s better than CS2, which is not to say that I think it’s good. I’d like someone at Adobe to explain to me why, on a machine as fast as my Mac Pro, it STILL takes forever to start up Photoshop. What in the world can they be doing?

Managing the collection of photos is being done (with some regret) with Adobe Bridge. For me, it works. It’s rather like Churchill’s comment about democracy being the worst possible form of government, except for all the others. Bridge is the worst possible tool for this job, except for all the others, which all seem to suffer from bizarre, deal-breaking defects. All of my comments about Bridge on Windows can be ported to the Mac without alteration.

For word processing, spreadsheet, etc. we’re using Microsoft Office. When Office 2008 for the Mac finally ships we will get it, although I have gazed upon Apple iWork and wondered how long before it is sufficiently refined that I can sever ties with Word and Excel. Perhaps never, but one can hope.

All of this acquisition of software tools has run up some expense, although none except the Adobe stuff is even slightly expensive. On the other hand, I haven’t had to buy, install, configure, curse at, and be annoyed by any antivirus software. This puts me very slightly ahead on cost and way ahead on muss, fuss, and general botheration.

The package containing Adobe Lightroom arrived late on Saturday.  Naturally, Sunday was scheduled solid, with a two hour drive to Yakima, one and a half hours of Artist Reception, and then two hours drive back, followed by two and a half hours of meeting about trying to form a Snoqualmie Valley Artists Guild.  After that, I got home, and pretty much went to bed.

Today I browsed through the Adobe Photoshop Lightroom Book by Martin Evening, felt hopelessly confused, and decided to just install the software and see what the heck happened.

First complaint - one of my rules for software is that software should not conceal from users where data are stored, ever.  If Lightroom is going to create a huge database file and save it away on my computer, it should let me know, up front, where the heck it’s putting this thing.  Furthermore, if you’re going to create huge files, you must make it fairly straightforward for me to cause those files to live in some place more acceptable to me. 

HINT TO LIGHTROOM DEVELOPERS - many, perhaps most, photographers have attached to their computers various arrays of disks, and they expect that they will be able to easily and without much in the way of head-banging frustration cause your application intended to manage huge amounts of data store said data on some specific disk in some specific folder.  Assuming that the owner of this sophisticated computing system which stores hundreds of gigabytes of photos will want to store things in the place dictated by Windows (and thus not on any of the really large secondary disks) is probably a bad bet.

SECOND HINT TO LIGHTROOM DEVELOPERS - when confronted with the fact that Lightroom has placed data in what I consider to be a rude and inappropriate place, I do not particularly like it when I cannot easily find a way to coerce your damn application into storing the data where I want to store it.  In particular, designing your application so that the way to create a new library is to hold down the eff-ing ‘alt’ key while starting the application is, well, let’s just say I have quite a lot to say about your parentage and whether you are in fact smarter than a plate of boiled broccoli.  You decided this was a better plan that a menu item called ‘create new library’ because you were, what?  In the throes of some massive neural seizure?

The second bit of consternation came when Lightroom announced that it could not import a bunch of .psd files that I have created with Photoshop, and suggestedthat I open the files in Photoshop, and then save them with ‘maximum compatibility’ checked in the preferences.  THIRD HINT TO LIGHTROOM DEVELOPERS - I do not consider it to be a good omen when one Adobe application announces that another, highly related Adobe application’s files can’t be read because they were not created in ‘maximum compatibility’ mode.  Especially when the documentation for that option says that it’s needed to make the files readable by OLDER versions of software, and not ensure forward compatibility with software to be written and purchased in the future.

I have lots more to say about Lightroom but this is too long already.  I am impressed by many of the features and capabilities of Lightroom but I am wondering somewhat whether this application is actually ready for prime time.

This past Wednesday night, I attended the March Group f/5.6 meeting.  As a general thing, each month a member does a presentation, and this month Wade Henninger gave us an excellent presentation on Adobe Lightroom.  Wade, a software developer who is actually working at Adobe (on Lightroom, no less) has a very fast, breezy presentation style that I love - sort of a stream of consciousness maximum bandwidth brain dump.  I can learn a lot from Wade in a very short time. 

After seeing Wade’s presentation, I came home and ordered a copy.  I don’t think that Lightroom will ever (unless it subsumes a great deal of the functionality of Photoshop) ever become a one stop tool that will satisfy all of my needs.  But I was mightily impressed by the power and flexibility, both with using Lightroom as a DAM tool and using it as a sort of Ultra-Bridge to help me get each photo I’m going to work on in Photoshop over into photoshop.  My big concern was that Lightroom is the obvious place to do things like noise reduction, etc. and many of the tools I use for those tasks really ought to become plugins to Lightroom, in the way they’re now plugins to Photoshop.  Wade assured me that this will eventually be the case.

Lightroom has problems - for example, multiple monitor support sucks.  (This makes me glad I decided to opt for one freakishly huge monitor instead of multiple monitors).  But it is a start, and the only competitive product, really, is Aperture, which I can’t use because it is Mac only.  Now, the current strategic computing plan here at Atelier Butzi includes switching to Macs with the next rollover of machines, but I’m still not comfortable locked into a single platform solution when I can avoid it.  When the Great Mac Switchover happens, I can revisit that decision, I guess.

The USPS tells me the package is now only tens of miles away from my PO Box, so I guess I’ll find out if I’ve made a mistake pretty soon.

There was quite a long discussion on the advantages and disadvantages of deleting ‘bad’ images in camera, versus deleting them after download when you’ve got different tools to view the images, over on The Online Photographer (see this post, this post, this post, this post).

All that discussion is well and good.  The technical issues surrounding bugs in filesystems, the properties of flash memory, etc. are all well taken.  The issue of not being able to judge images properly on a teeny, non-color-corrected display are well articulated and are important, surely.  The improving marginal capacity/price of available storage cards does, surely, reduce the pressure for in camera deletion.

But, as Arlo Guthrie once put it, “…that’s not what I came to tell you about.”  I’m not here to argue about the merits of in camera deletion versus on computer deletion.  I’m here to argue that, as artists, we might all want to consider Butzi’s Rule of Deletion - “Don’t delete anything.  Ever.”

It’s easy to make this argument - just start from Josh Hawkin’s premise as expressed in his post on TOP - it’s darn hard to know, in advance, which images will be significant.  There’s not just Josh’s story about his image being a winner, there’s the story of the photographer who photographed the Queen of England during a parade, and got what he thought was just boring dross.  That is, until it was revealed that an assassination attempt had been made, and the photographer reviewed his film, and there, in the middle, found one frame with a hand encroaching into the frame holding a pistol leveled at the Queen on horseback.

Easy, too, to make the argument that if we delete stuff, even prosaic and quotidian stuff, we’re deleting stuff that historians will find fascinating and important.

And, of course, with the price of storage continuing the free fall that it’s been doing for the past decade (or more), it’s easy to argue that keeping everything is cheap.

But those aren’t the persuasive argument.  The persuasive argument is this: as artists, I think we get rid of our trail of mistakes at peril.  Those ‘losers’, ‘also rans’, and ‘not quite winners’ represent the path of our searching for something significant.  Often, our process consists of dabbling around the edges of something unconsciously, a sort of spiritual testing of the waters.  And only by going back and looking at our ‘loser’, ‘also ran’, ‘not quite winner’, and, most importantly, our ‘What in the name of everything that is sacred could I possibly have been thinking when I opened the shutter on this scene’ photos can we possibly discover what our unconsious process has been busily working away at.

For me, and I believe for a lot of photographers, photography is a way of “Effing the ineffable”.  We’re after something, and not only is it hard to express it in words, it might be impossible.  It’s something that, almost by definition, doesn’t fit into our existing mental model of how the world is put together.  We don’t learn new things by performing experiments where we know the outcome, we learn new things by performing experiments where we DON’T know the outcome.    We advance as photographic artists not by only opening the shutter when we know, in advance, that result is going to be a world class, blow the viewer right out of his sneakers, stupendous winner of a photograph.  We advance when we set up the camera thinking “I wonder what would happen if…” and then proceed to open the shutter knowing full well that the odds are good that the photo will be no damn good at all but that we’ll have learned something in the process.

And, I argue, one of the most valuable things we can do is to periodically go back, and go over our backlog of ‘not winners’ and ask ourselves some questions.  Not just questions like “Are these sharp enough?  Would using a tripod improve the sharpness of my photos” (which are fine, as far as they go) but also questions like “Why do I seem to have so many photographs of people’s shoes?  What’s going on, there?” or “Gee, now that I’ve started making the photograph that first attracted my attention, and then turning 180 degrees and making another, why do I find the ‘backward glance’ photos so compelling?  Isn’t that interesting?”

There are trends in our work, running back weeks and months and years, waiting patiently for us to come back and discover them.  But the trends are often encoded in the stream of ‘not winners’ that every photographer makes, and if we delete them, we can’t go back and find those trends.

David Bayles and Ted Orland put it well when they said “The function of 99% of the art we make is to enable us to make the 1% which soars.”  Those ‘not winners’ you’re tempted to delete - they’re not mistakes, they’re the groundwork for what is coming next.  If you don’t know what’s coming next, go back and look at those ‘not winners’ and try to find the patterns and trends that point the way.  That’s what they’re for.  They have a purpose, and the fact that the purpose isn’t “fire up photoshop, make a beautiful print of this image, frame it, and get it hung in the museum” doesn’t mean that purpose is any less important.

Don’t delete anything.  Ever.

“What’s in a name?  That which we call a rose/by any other word would smell as sweet.”

While my internet connection was down, I was motivated to do things that didn’t require the ‘net, like cleaning up.  One of the things I started to do was to organize the VAST lump of computer files.

Far and away the most daunting thing was that I’ve been very bad about avoiding duplication, so it’s often the case that I have the very same image, stored in multiple locations.  I decided that this was a Bad Thing, and I set about finding duplicates and eliminating them.  And to my dismay, this was a Very Hard Thing to Do, because often the duplicates would have different names.

Here are some lessons I learned:

1. Every image should have a unique name, even if it become removed from the directory that provides identifying context.  So it’s no good to have a directory named “July 2001″ and a directory named “August 2001″, each of which has files named PICT0001.JPG, PICT0002.JPG, etc. in it, especially if the files in the directory are not identical.  More on this later.
2. Files which are derived from some original file should make it clear what that original file was in the file name if at all possible.
3. When you’re reading files off CF cards, you should read the files off the card, and immediately ensure that they are stored in TWO locations on separate hard disks, for safety.  Having done that, you should immediately format the darn CF card, so that you don’t end up duplicating the files when you copy files off the card the next time.
4. Unix is far better than Windows/XP for letting me cobble together tools to find all the files that are byte for byte the same.
5. It will be far easier to avoid duplication in the future (and easier to detect dupes) than it has been to eradicate them on a filesytem with 10’s of thousands of files and some large but unknown number of duplicates.
6. Myrate of accumulation of files has increased exponentially over the past few years, so that I am accumulating files much much faster now than I was even just one year ago.
7. Don’t tackle tasks like this when you already have a headache.  Trust me on this one.

Right now, for image files which I am creating now, when I copy the files off the CF card (or SD card, whatever.  Sit down in back, there, and be quiet) I immediately rename ALL the files using the following scheme: <camera name>-<YYYYMMDD>-<sequence number>.

Camera name is a unique, short name I attach to each camera I own.  For my Canon EOS-5d, the name is “5d”.  For the Canon A95 I own, the name is “a95″.  You get the idea.

YYYYMMDD is the date the image was captured.  This is recorded in the EXIF data, so it’s easy for the tool I use (Adobe Bridge) to find it and use to rename the file.  It’s also easy for any other tool people use to do it, so if I switch from using Bridge, I don’t have to switch naming conventions.  I use the order year, month, day, with fixed widths, because it makes it easy to get various tools to sort the files in date order.

Finally, the sequence number is the one attached to the file by the camera.  On the 5d, it’s a four digit number and when it hits 9999, it just wraps back to 0000.  You’ll note that as long as I don’t have a camera body which wraps the number in a single day, I’ll never get different files with names that collide.

Like a lot of photographers, I’ve got a lot of data in a lot of files.  Up until recently, I stored those files in duplicate, one copy on my main desktop machine, and one copy on a dedicated fileserver with a really big RAID array.

That fileserver is a custom built high end Intel machine, running Freebsd as the operating system.  At the time I built it, it was pretty much the only way to get a RAID server unless I wanted to shell out the big bucks and run the server version of XP, which I didn’t want to do.

But recently, as that machine ages, I started wondering how I was going to replace it.  One option was to build another machine like it, but for various reasons I wasn’t too keen to do that - I wanted something more appliance-like - something that reduced the amount of time I needed to be a wizard.

My solution was to buy a Infrant Readynas NV+ - a dedicated network attached storage (aka NAS) machine with RAID built in.  I bought it, stuffed it full of disks, connected it to my network, powered it up, and voila! I had one terabyte of RAID storage on my network that wasn’t there before.  It has lots of cool features, including support for both Windows SMB style filesharing (so my windows machines talk to it) and the Apple file sharing protocol, so that as I transition over to Macs, I don’t suffer too much.

Best of all, it’s quieter than the Freebsd machine, which is a noisy beast.  It draws less power and generates less heat, too.  I connected it to an APC UPS, and it recognized it instantly and configured to shut down gracefully when the UPS gives up.  It will even send email when bad stuff happens.

The best thing about the ReadyNAS NV+ is the expandability of the RAID system.  You can start out with a small number of disks and add more disks, and the unit just adapts, makes more storage available, and keeps on going.  You can replace all of the disks in the unit with larger disks, one at a time, and the unit adapts as you install each new disk, and when the last larger disk is installed, you get more storage.  It doesn’t insist that every disk in the system be identical!

In the photo, the Freebsd fileserver is the big black thing on the far left, and just to it’s right is the UPS that helps it survive the frequent power outages I have.  On the far right, the little silver thing is the Infrant ReadyNAS NV+, and just to its left is the smaller power supply that supports it.