Live data from Hacker News

Storage for Photographers

paulstamatiou.com

141–150 of 186 posts

Re: Storage for Photographers

#141
post #34

We applied to YC with exactly this idea. We made it to the interview, but were turned down. I wrote about that experience: http://tghw.com/blog/pull-hard We pulled our bootstraps hard and tried to get it going, but soon realized that there's a pretty big flaw with the idea: most photographers have no idea that they should backup their photos. They know hard drives crash, but they never expect it to happen to them. Th…

> For this experience, we spent less than $1,000. Compared to an entrepreneurship class at any college, that's quite cheap! My undergrad was in USC's entrepreneurship program. One of the points they always hyped on was whether or not you were "selling vitamins or vicodin", so to speak. As you learned through Snaposit, most people when making chit-chat will be supportive of your venture, but you won't know how they re…

FWIW, that's the original Lean Startup model.

In fact, that's how the Four Hour Work Week or one of those books was written -- ads first, and when the ads converted, the book was then written.

Re: Storage for Photographers

#142

Earlier quoted context omitted.

I periodically mail a DVD of important stuff to my parents and ask them to toss it in the basement. You could do the same thing with backup tapes, or whatever. Drives/tape/flash/dvd is pretty damn cheap and easy. These S3 type solutions would have to be much cheaper to be interesting.

A DVD holds 4.7GB. Box.net offers 5GB for free. Besides, how do you verify that those backups can be restored when you need them, if they're offline in some remote location? That seems rather untrustworthy to me. I run checks against parity files regularly to verify their integrity.

10 DVDS hold 47GB. How much does that cost on Box?

And can you download 47GB faster than your mom can mail you a DVD?

Re: Storage for Photographers

#143

I am the CEO/Co-Founder of Mosaic. We are a company that helps serious photographers backup their photographers. I am happy to share what we have learned in the past 2 years. www.mosaicarchive.com As a background, we now have thousands of users and customers. We also finished raising a series A in February. (Not that raising money proves anything) http://www.boston.com/business/technology/innoeco/2013/02/mo... We are…

Thanks for replying Gerard. Do you ever see a version where I can store directly on my Amazon Glacier account?

Especially given "However... we are not an online backup company." I'd feel tremendously safer and more trusting of your service. I haven't used Mosaic so maybe you already do this, I'll take a closer look this week.

Also (in a nice way), your site could benefit from a redesign. Unfortunately I think quite a few consumers judge the trustworthiness and value of a brand by their site/landing design.

Re: Storage for Photographers

#144
post #82

I'm not convinced that retrieval time doesn't matter. If you decide you want several photos, wait 4 hours to retrieve them from Glacier, then realize you wanted a few more and have to wait an additional 4 hours, I think that would get old pretty quickly.

I was wondering something similar. Does Glacier have any way to see a preview of the images you are downloading? If I upload 100 images with serialized file names (001.jpg, 002.jpg) how do I know which images to download?

There's no preview. Actually there's no way to download or even list your archives through the AWS Console. You need to write (or find) an app that uses the Glacier API.

Re: Storage for Photographers

#145

Yes, PLEASE. We run a wedding photography business, and our numbers are something like this: - 40-60gigs shot in a weekend, need to offsite the RAWs as soon as possible. In six or seven years we've never needed offsite retrieval. Fine for it to be slow. - Only need around 100-200g of raws locally for jobs in progress - Once processed into final jpgs files are approx 8-10x smaller. Offsite these as well, and need acce…

> Occurs to me you might wonder what this looks like today I finally hit a sweet spot of performance, archive accessibility, and offsite safety, by using internal SSD for latest import workspace, direct attached WD Velociraptor (Thunderbolt) for current projects (can reconnect between Mac Mini server and laptops as needed), and 2 direct attached LaCie 4big Quadras (daisy chained via FW800) for archived projects (up t…

The idea of a P2P backup solution is interesting, more so if you can hook up strangers into a massive backup network.

Of course, the challenge is to make sure the peers are online when you need the files, and for this reason the network may need 5-10gb of storage for 1gb of data to duplicate the content across multiple users.

Re: Storage for Photographers

#146

I really wish we as a developer community would better differentiate between "backup" and "preservation". They are both related to storage, but are fundamentally different problems. The article touches on the desire to have photos safe for decades, but doesn't really get into the strategy necessary to make that happen. If we care about decades, storing the raw NEF or CR2 file is almost certainly the wrong approach. T…

In a word, VMs. If you make sure you can open that NEF or CR2 file in a virtual machine, and the virtual machine image is in a standard, open format, you're set. You just have to worry about the image format becoming obsolete and not 10 or 20 different proprietary formats.

That said, I used to be a pretty prolific hobbyist musician and I haven't pulled this off myself. I have tons of old songs I can't open because they rely on a fiddly collection of old freeware plugins for freeware music apps from 11 years ago. I also have songs I can't open because they only play in a music tracker I wrote, which is open-source, but only runs on OpenBSD.

It is a tricky problem and it seems hard to tackle because the market for professional software inherently favors closed-source, which has no incentive to adopt open, non-siloed formats.

Re: Storage for Photographers

#147
Currently using Crashplan to backup my photos. I copied 200+ DVDs of photos to my hard drive in numbered directories... then deleted them after I had them uploaded (Crashplan keeps deleted files if you choose that option).

Re: Storage for Photographers

#148
> I just need to know they are somewhere safe for decades to come.

The thing about Amazon Glacier... unless they are themselves making more than one copy, and taking hash fingerprints, and storing a couple copies of the hash fingerprints, and using it all to check for bit rot on a regular basis...

...and I don't think they're doing all (any?) of these things...

...then people are sadly going to find that their stuff _isn't_ neccesarily safe for decades to come. One copy on a single piece of media in an Amazon data center somewhere does not actually make for 'safe for decades to come'.

Re: Storage for Photographers

#149

I really wish we as a developer community would better differentiate between "backup" and "preservation". They are both related to storage, but are fundamentally different problems. The article touches on the desire to have photos safe for decades, but doesn't really get into the strategy necessary to make that happen. If we care about decades, storing the raw NEF or CR2 file is almost certainly the wrong approach. T…

Even without getting to format obsolescence...

...do we know, when you store something in Glacier, does Amazon keep multiple copies, or just ONE on some unspecified media? Do they take a hash fingerprint, and compare it to the copy for bit rot corruption?

Even without getting to format obsolescence, the strategy of just keeping the bitstream reliably and verifiably retrievable for 'decades to come' is worth discussing.

Re: Storage for Photographers

#150

> I just need to know they are somewhere safe for decades to come. The thing about Amazon Glacier... unless they are themselves making more than one copy, and taking hash fingerprints, and storing a couple copies of the hash fingerprints, and using it all to check for bit rot on a regular basis... ...and I don't think they're doing all (any?) of these things... ...then people are sadly going to find that their stuff…

https://aws.amazon.com/glacier/#highlights

> Amazon Glacier is designed to provide average annual durability of 99.999999999% for an archive. The service redundantly stores data in multiple facilities and on multiple devices within each facility. To increase durability, Amazon Glacier synchronously stores your data across multiple facilities before returning SUCCESS on uploading archives. Unlike traditional systems which can require laborious data verification and manual repair, Glacier performs regular, systematic data integrity checks and is built to be automatically self-healing.

Post reply on HN