When your backup method is not out-of-band=FAIL

So I spent quite a bit of time traveling lately, last week I was in Edmonton, AB. When I return to my office there are two labels from UPS saying they tried to deliver the package. What really seems silly is their policy states (according to the unhelpful and unlucky person who answered my phone call) is that they hold onto the package for 5 business days, waiting for you to respond to the postcard they just mailed you--TO THE SAME PLACE THEY HAVE NOT BEEN ABLE TO GET ANYBODY!

You would think that either the collection of UPS stickies on the door, or the fact their excellent tracking database records the delivery attempts, that mailing a postcard to the same address is a terrible idea. All you catch there is somebody who wasn't available at the time to receive the UPS package, not people who are gone for a simple week!

Of course, by chance, they came during a week when nobody was in the Bluenotch Corp. office, and the killer is that the package spends more time in transit from shipper to me, then a measly 5 business days at a UPS location 20 miles away, then twice again as much time going back to the shipper. This package has spent more twice as much time on a UPS truck than waiting to be picked up, and it is going to double again when the shipper-reships it. The thing is, I know that email address and phone number is included in the shipping documentation, so if they really wanted to try to resolve the situtation, they could.

So try to get the most value out of this little incident--Don't have your backup system or your communications in same flawed mechanism, be SURE it is truly as out-of-band as possible.

Had a great discussion during my File Systems with FUSE talk at SCALE and this week I'll be at Secure IT Conference in Los Angeles. Next week is a series of workshops put on by The User Group at TUG 2009: Users To Users.

Working on a killer project I hope to post about at the end of the week once I get a few more details pounded out.