 |
 |
Yes I did, and I think this a welcome addition. The charges ($80 media fee plus about $2.50 per data loading hour with eSATA and USB 2 interfaces supported) strike me as reasonable. For applications where you want the data to be readily accessible, I think this is a good option, though I think inadvertant/malicious deletion is always a risk with hot data so it can't be the only component of the plan We toyed with the idea of doing this, but since we don't need hot backup, we're going in a much lower tech direction. Basically, the idea is to just throw whatever media in Pelican cases and use our courier system to keep multiple copies near and far from the system being backed up. For quick recovery, someone jumps in a car and brings it back. Fast, easy, much cheaper, and recovery is significantly faster than anything we'd be able to do from S3 (unless we're talking about recovering small amounts of data). We will be using S3 for certain types of data since it is an excellent option wherever direct access is desirable. kyle On Thu, Aug 27, 2009 at 9:02 AM, Rosalyn Metz<[log in to unmask]> wrote: > Actually Kyle did you see that you can now put your stuff on a drive, snail > mail it to Amazon and they will upload it to an S3 instance for you. > Bandwith problem "solved". > > On Thu, Aug 27, 2009 at 11:59 AM, Kyle Banerjee <[log in to unmask]>wrote: > >> Agreed on both of Rosalyn's points. >> >> I'm wary of the hot backup options discussed in this thread for large >> quantities of data. First of all, hot backup is expensive -- disks >> aren't that inexpensive, and after you add power and space, it gets >> much worse. Start keeping many copies, and the price gets much worse. >> LOCKSS is good for protecting articles since that is what it is >> designed to do. For a variety of reasons that go beyond cost, I think >> it's a hopeless model for backup. >> >> Even if money is no object, bandwidth is a huge issue. Transferring a >> few GB at a time is not a big deal, but it takes awhile. Transfer >> large quantities and you run into trouble quickly. Bit rot is not so >> much of an issue because you can check integrity regularly. For >> example, a bottom of the line EC2 instance could continuously monitor >> your S3 files. >> >> Of course, there is the whole practicality aspect -- backup must be >> convenient as well as effective. Different solutions strike me as >> appropriate to different situations, but as much as I hate tapes, >> they're effective, cheap, and efficient presuming you don't keep them >> on site and verify them. >> >> kyle >> >> On Thu, Aug 27, 2009 at 8:43 AM, Rosalyn Metz<[log in to unmask]> >> wrote: >> > I have to agree with Ed. You should have a good policy in place for >> backing >> > up your data. Just throwing it on a server isn't a policy. >> > >> > At the same time I would have to disagree with Ed. You should look at S3 >> as >> > if it was your own server. What is the guarantee that you supply to your >> > users with your own server. The snap server we use here (instead of S3) >> is >> > the back up to a back up system already in place. >> > >> > >> > On Thu, Aug 27, 2009 at 9:52 AM, Edward M. Corrado <[log in to unmask] >> >wrote: >> > >> >> Rosalyn's post made me think of one more thing.... if you are looking >> into >> >> outside entities (such as we are), what are the terms of service and >> what >> >> guarantee do they offer they won't lose your data? I believe that A3 >> does >> >> not offer any guarantee, so if you go with them, you probably want to >> have >> >> some other form of storage as well. Even if they offered a guarantee, >> what >> >> good is it once they loose your documents you were trying to preserve? >> >> >> >> Edward Corrado >> >> >> >> >> >> >> >> >> >> Rosalyn Metz wrote: >> >> >> >>> Hi Edward, >> >>> >> >>> Might I suggest you look into cloud computing services if you're >> looking >> >>> at >> >>> different options. (I know you're all shocked I suggested it). If our >> >>> budget weren't so abysmal (and going to get worse) we would be using it >> >>> right now rather than the snap server we purchased with leftover funds. >> >>> The >> >>> benefits of using the cloud is of course the elasticity it offers you. >> >>> The >> >>> negative is that you have to pay to put your files into the cloud and >> then >> >>> pay again to take them out (and since we've already been slashed 30% >> and >> >>> are >> >>> guaranteed another slash...that idea was shot down). >> >>> >> >>> Of course the major player out there is Amazon S3. The problem is that >> >>> you >> >>> can't use S3 via Amazon's Web Management Console. But there is a >> company >> >>> called RightScale (http://www.rightscale.com/index.php) which has a >> web >> >>> management console that allows you to upload files quickly and easily >> >>> without having to write scripts and what not. >> >>> >> >>> Anyway, just my two cents. >> >>> >> >>> Rosalyn >> >>> >> >>> >> >>> >> >>> On Thu, Aug 27, 2009 at 8:10 AM, Edward Iglesias >> >>> <[log in to unmask]>wrote: >> >>> >> >>> >> >>> >> >>>> As I was trying to figure out what to do with half a terabyte of >> >>>> archival TIFFS it occurred to me that perhaps someone else had this >> >>>> problem. We are starting to produce massive amounts of digital >> >>>> objects (videos, archival TIFFS, audio interviews). Up until now we >> >>>> have been dealing with ways to display them to the public. Now we are >> >>>> starting to look at "dark archives" like OCLC's digital archive >> >>>> product. I would welcome any suggestions from those of you who have >> >>>> dealt with this on an archival level. It's one thing to stick the >> >>>> stuff up on a server, but then what? Our CIO suggested storage >> >>>> appliances like this one >> >>>> >> >>>> >> >>>> http://www.drobo.com/products/index.php >> >>>> >> >>>> but I am wary of the proprietary RAID system. >> >>>> >> >>>> Thanks in advance, >> >>>> >> >>>> >> >>>> >> >>>> ~~~~~~~~~~~~~ >> >>>> Edward Iglesias >> >>>> Systems Librarian >> >>>> Central Connecticut State University >> >>>> >> >>>> >> >>>> >> >>> >> > >> >> >> >> -- >> ---------------------------------------------------------- >> Kyle Banerjee >> Digital Services Program Manager >> Orbis Cascade Alliance >> [log in to unmask] / 503.999.9787 >> > -- ---------------------------------------------------------- Kyle Banerjee Digital Services Program Manager Orbis Cascade Alliance [log in to unmask] / 503.999.9787