On Sat 17 Feb 2007 21:46, Dennis J. Tuchler wrote:

...

Why is it a bad idea to use CDROMS as storage media?

__________

Hello Mr Tuchler,

- at this time I have been having trouble reading CDs because of crumpled Labels

. . . maybe labels, and damage to the reflective surface on the label-side are a negative factor ?

best wishes So don't use labels--write on the top of the disk with a fine-point marking

On Saturday 17 February 2007 16:53, riccardo35@gmail.com wrote: pen. Or, there is a system where the disk can be engraved on the top-- it's called Light-Scribe. The disks are from Memorex, and I don't know who makes the drive. I also don't know if there is a driver for Linux. Somebody here will know. It's pretty neat--my son gave me a music disk written this way. --doug -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

riccardo35@gmail.com wrote:

On Sat 17 Feb 2007 21:46, Dennis J. Tuchler wrote:

...

Why is it a bad idea to use CDROMS as storage media?

__________

Hello Mr Tuchler,

- at this time I have been having trouble reading CDs because of crumpled Labels

. . . maybe labels, and damage to the reflective surface on the label-side are a negative factor ?

I've only used those stick on labels for music CDs and have never seen one "crumple". Those CDs are usually stored in my car, where they're exposed to temperature extremes. For computer use, I always use a permanent marker directly on the CD surface. However, any back up media can fail, so it's best to have multiple generations available. Incidentally, I'm old enough to remember bored computer operators, on the night shift, backing up to a stack of open reel tapes. The tapes were then sent via courier to off site storage. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

David Brodbeck wrote:

Dennis J. Tuchler wrote:

...

I have seen advice on listservs not to back up to a CD ROM. I never understood why. Why is it a bad idea to use CDROMS as storage media?

They're a bit slow to write to, but other than that I don't see any reason not to.

My experience suggests you can't count on CD-RWs for long-term backups...like more than a few years. CD-Rs seem to hold up pretty well as long as you don't expose them to direct sunlight.

Then again, there's no point in using CD-RW for long term storage. As you mention, CD-R would be better for that. However, if you're looking for a "recover from crash" type backup then CD-RW should be fine, provided you always verify the backup. No matter what medium you use, if it's important verify and even make multiple back ups. In server admin courses, they often teach the proper methods for back up, including generation management etc. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sat February 17 2007 17:25, Randall R Schulz wrote:

Dennis,

On Saturday 17 February 2007 13:46, Dennis J. Tuchler wrote:

...

I have seen advice on listservs not to back up to a CD ROM. I never understood why. Why is it a bad idea to use CDROMS as storage media?

For me, at least, CDs per se are too small. DVDs can constitue a manageable solution for backing up select portions of one's data (but still not for most whole-system backups). With multisession writing and rewritable media, you have acceptable _backup_ media, but not a very good archive solution.

I'm kind of hoping that one of the new DVD formats (HDDVD or Blu-ray) will prove useful for backup and, perhaps, archiving purposes, but it remains to be seen if it will become economical (cost of drives and media) and what sort of longevity and reliability characteristics those media formats will exhibit.

Separately, does anyone know of Linux software (perhaps a FUSE file system) that exploits optical drive packet writing? I've seen such things for Windows (simulating an everyday read/write, random-access magnetic drive using an optical recorder), though I was always sorry when I tried them because they seemed to make my system unstable (though that was probably just bad driver coding).

...

Dennis J. Tuchler

Randall Schulz We use DVD-RAM drives and media. The media is pricey compared to dvd -r and -rw, but it is much more reliable. Double sided (not double layer) media in a cardridge costs about $7.50 each. There is also now media that does not require the cartridge, but for backup purposes, the cartridge protects the media. The life is much longer. Google it. The problem is, so far, I have not found a Linux program to "format" or "write the filesystem" to the media. I have to use a windows computer to format the media, then use it. I format using the FAT32 filesyste, but UDF 1.5 and 2.0 are available.

In case you are not aware, DVD-RAM reads and writes just like a hard drive. No sequential writes, no ISO files. You can set up directories just like a HD, but, according to a Panasonic engineer, you cannot set up partitions. Regarding cost of media/drives, I think we are spoiled. Today, drives and media are dirt cheap, compared to yesteryear. Re: archive, I agree with your comment re: dvd-r. Archiving should always be done on a non-rewritable media. Actually I bo both, backing up my DVD-RAM media with DVD-R. Years from now, DVD-R drives and formats will still be arround, but DVD-RAM is not very popular, so it might not survive the test of time. I have some backed up data on 5 1/4" floppies, 8" floppies, Zip disks, SparQ cartridges, Colorado Optics tape, and Bernouli cartridges. I abandoned my Radio Shack TRS-80 Model I cassette tapes on December 31, 2004 (yeah right!). -- John R. Sowden AMERICAN SENTRY SYSTEMS, INC. Residential & Commercial Alarm Service UL Listed Central Station Serving the San Francisco Bay Area Since 1967 mail@americansentry.net www.americansentry.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2007-02-18 at 12:42 -0500, James Knott wrote:

...

Three months later, I tried to do a restore, and found that about half the DVDs had developed read errors. So now I don't trust CDs or DVDs anymore

That is why you're supposed to make frequent back ups and keep a few generations. There is always the possibility of media failure, no matter what you use.

Yes, but that can be taken into account beforehand by the recording program, by using self-correctable byte codes and sectors, so that errors in the media (a bad sector, for instance) can not simply be detected, but also corrected. Does that exist in Linux? I have used that method almost 20 years ago in MsDos, with floppy backups. Why don't we have that in Linux? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF2OhOtTMYHG2NR9URAoXRAJ9dSe4ExPSbhTEl0tj6nhfNzgFX0wCeKo+o EHJmuV+Y+dOpsfNbkBprxFg= =Z6tH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

The Saturday 2007-02-17 at 15:46 -0600, Dennis J. Tuchler wrote:

...

I have seen advice on listservs not to back up to a CD ROM. I never understood why. Why is it a bad idea to use CDROMS as storage media?

Do you have a link? Such a statement without explanation is... well, confusing, as you yourself show.

A CD is too small nowdays, that could be a reason, but DVDs are more reasonable - still, you can imagine backing a 500 GB HD to... what, 100 DVDs?

Many years ago, I used to back up my hard drive to floppies! Lessee now 500 GB / 1.44 MB = over 330,000 floppies!!! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 18 February 2007 15:14, Carlos E. R. wrote:

I wish we had some open backup software as reliable as that one was, but using modern media, like dvds, for instance.

I spent a lot of time working with DAR and daromizer which is a front end to DAR. DAR is quite flexible on its output and with daromizer to setup most of the backups... it worked quite well. However...... I found that DVD's are not that reliable... when you write them yourself. And that goes for DVD's created in a TV-DVD-recorder or on a PC. I don't use DVD's for backup any more. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

The Sunday 2007-02-18 at 12:52 -0500, James Knott wrote:

...

...

A CD is too small nowdays, that could be a reason, but DVDs are more reasonable - still, you can imagine backing a 500 GB HD to... what, 100 DVDs? Many years ago, I used to back up my hard drive to floppies! Lessee now 500 GB / 1.44 MB = over 330,000 floppies!!!

Me too!

I still have backups in 360 Kb floppies, and I know they still work, they are fully "restorable" - I know because I tried. I used PCtools Backup (Microsoft on later days paid them for a limited version of the same program to include with MsDos 5 or 6). I had a dual floppy pc and it was able to backup using both drives alternatively, without me pressing a key. It was so fast I barely had time to store a floppy and pick the next!

I wish we had some open backup software as reliable as that one was, but using modern media, like dvds, for instance.

I also used 360K floppies on my XT clone with it's *HUGE* 30 MB drive! Then on my 386 OS/2 system, I used Backmaster with QIC-80 tapes. Nowadays, I either write an image to a duplicate hard drive, copy to an external hard drive or write to DVD. I use KDar for writing to the DVDs. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Monday 19 February 2007 10:32:57 am Greg Freemyer wrote:

On 2/17/07, Dennis J. Tuchler wrote:

...

I have seen advice on listservs not to back up to a CD ROM. I never understood why. Why is it a bad idea to use CDROMS as storage media?

AIUI, it relates to designed life of the media. For most CDs/DVDs it is pretty short (a year or two I think. And the glue from the back of the label will eat away your data. Don't use them.)

Check these out: http://www.kmpmedia.com/kodak-gold.html

That should be long enough for you (rated 100 to 300 years).

FYI: I was curious about the cost. $122 for 100-pack at http://www.datamediastore.com/kodak-cd-r-29150.html.

Greg

Another longevity issue with CD/DVD media is mold and bacteria. Apparently in humid climates anywhere, there are molds and bacteria that will eat the data layer. Sometimes within weeks. Cool & dry is best for storage. Don't know about the glue eating the data layer. I thought labels and adhesives just took off the reflective layer causing a loss of readability. Data is still there if you can replace the reflective coating... Sanford's Sharpie brand of markers are OK for writing on the media. Stan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-02-19 at 11:17 -0800, David Brodbeck wrote: ...

Other than that I've had remarkably few problems reading CD-Rs that are a decade old. CD-RWs seem to suffer more from bit-rot. My 20-year-old 720K floppies aren't doing so hot, either. ;)

Those floppies are probably better quality than their contemporaries. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF2iyutTMYHG2NR9URAiYsAJ4n8Wch5YBPs1oP/dp4Falbos1wAgCfWpE3 Q5K6FbY5j47xM4DqvmUxmos= =y07J -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2/19/07, Doug McGarrett wrote:

On Monday 19 February 2007 14:17, David Brodbeck wrote:

...

S Glasoe wrote:

...

Don't know about the glue eating the data layer. I thought labels and adhesives just took off the reflective layer causing a loss of readability. Data is still there if you can replace the reflective coating...

I've found on some cheap media the lacquer on the label side is very thin, making it easy to chip the reflective layer and lose data.

I've also erased CD-Rs accidentally by leaving them in direct sunlight. The UV seems to bleach the dye out of the data layer.

Other than that I've had remarkably few problems reading CD-Rs that are a decade old. CD-RWs seem to suffer more from bit-rot. My 20-year-old 720K floppies aren't doing so hot, either. ;)

I have had numerous problems trying to read old floppy disks. While that was almost the only backup medium, it has turned out to be pretty flaky. Old audio tapes may sound OK, but who knows how many drop-outs there might be in a digital version of same? I would guess that a number of major corporations are finding that their digital tapes are not completely readable--but you'll probably not read that in the Times' business section!

It would seem that the perfect backup medium would be carving on stone!

--doug

I think the best realistic method is still Micro-fiche. Still only rated for 100 years (IIRC) but truly believed to last that long. AIUI, some companies still save very important documents to micro-fiche for that very reason. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Monday 19 February 2007 17:12, Carlos E. R. wrote:

...

Paper has a proven track record ;-)

But it's not without its own vulnerabilities. It gets eaten by bugs and mold, becomes brittle, fades and / or discolors, is quite susceptible to heat etc.

-- Cheers, Carlos E. R.

RRS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tue, 2007-02-20 at 12:27 +0100, Carlos E. R. wrote:

What electronic data storage is in existence that can be guaranteed to be read even one century ahead? You need power. You need electronics, technology... if the technology crumbles, would we be able to regenerate it, or would be the needed technology be written in discs and unavailable?

And for 1500 years no one could read ancient Egyptian hieroglyphics, carved in stone. Maybe there will be no humans in the future to read our backups. Better train those simians! -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

Of course. But those things we can prevent, and has been done so for centuries. For catastrophes, redundancy.

What electronic data storage is in existence that can be guaranteed to be read even one century ahead? You need power. You need electronics, technology... if the technology crumbles, would we be able to regenerate it, or would be the needed technology be written in discs and unavailable?

DVDs can be eaten by bacteria or mold. They can burn. They are susceptible to heat and light. The degrade on their own (ie, they fade). Hold on... didn't you say that of paper? ;-)

Ok, magnetic storage, then. Uh, oh... what about catastrophic electromagnetic pulses? Everything erased in a single blow!

If things get that bad I don't think there will be much worry about backups. Survivors will be to busy just trying to stay alive to worry about it. -- (o:]>*HUGGLES*<[:o) Billie Walsh The three best words in the English Language: "I LOVE YOU" Pass them on! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-02-19 at 11:32 -0500, Greg Freemyer wrote:

AIUI, it relates to designed life of the media. For most CDs/DVDs it is pretty short (a year or two I think. And the glue from the back of the label will eat away your data. Don't use them.)

The initial designed life was ethernal. A century at least. Actual life expectancy after "improvements" is much lower. Well, maybe I'm thinking of CDs.

Check these out: http://www.kmpmedia.com/kodak-gold.html

That should be long enough for you (rated 100 to 300 years).

FYI: I was curious about the cost. $122 for 100-pack at http://www.datamediastore.com/kodak-cd-r-29150.html.

I wonder if there are more makers claiming similar durability? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF2eSRtTMYHG2NR9URAlXrAJ90Tr59VV3QnSsldESIQjVO2szxdwCcDA2/ ZQtFfN2Rt11ihN4t3whOG2M= =uuM+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-02-20 at 05:12 +1100, Graham Smith wrote:

The following article maybe of interest to you. http://adterrasperaspera.com/blog/2006/10/30/how-to-choose-cddvd-archival-me...

Yes, it is very interesting. I didn't know that dvd+r was more reliable than dvd-r, for instance. It says that the best are made by 'Taiyo Yuden', a name I didn't even know about, but might be sold by verbatim. Hum! I have a box of verbatim that I can not even burn! I have also learnt about "http://www.digitalfaq.com/media/dvdmedia.htm" where there is a list of "Media IDs", so that I can who is the real manufacturer, classified by quality. Let me see what I have. * TDK: CMC MAG/M01 - CMC Magnetics (Taiwan) --> 3rd class. * Memorex: RICOHJPN/R03 - Ricoh, Ritek (Taiwan, Japan) --> 2nd class. * Verbatim 16x: MCC/004 - Mitsubishi Chemicals, --> 1st class. (data life plus) Mitsubishi-Kagaku Media, advnzd AZO+ Verbatim (Singapore, Taiwan, India) So it seems the best I can get, the Verbatim, I can not use because they fail with my LG burner! :-/ Maybe I'll have to test more media... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF2iuQtTMYHG2NR9URAvuLAJ41/iw09PKlFfMZKkDJwEnf/Q9kYwCdFOM+ SKXu4FsRoVCPQPq8uOqwHJQ= =vedg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-02-19 at 19:55 -0600, Billie Erin Walsh wrote:

A while back I read an article, aimed primarily at genealogists, about archival quality DVD's. The, supposedly, best disks for long term, stable, storage are DVD+R's, and the best of those come from only one manufacturer. Taiyo Yuden. They are available through:

http://www.supermediastore.com/taiyo-yuden-silver-thermal-8x-dvd-plus-r-medi...

I would have to find a source closer to me than that. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF2l2LtTMYHG2NR9URAskMAJ9ueFnkhTTTY22/pqjNgB1KGc1fBwCcC5lv cc8Y5XLgST3K4l1a4Xvb6as= =EIcf -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-02-20 at 08:59 +0100, jdd wrote:

...

I would have to find a source closer to me than that.

don't worry, the quality may have fallen as soon as the test was known :-)

X-)

and who will be here in 100 years to know if Kodal ly or not? whow cares?

Paper...

the only backup reliable is redundency. Think your house can get fire or water flood. Spread your valuable data...

Even backing up two different sets of dvds is no guarantee. A dvd can develop a failure in one sector, the second copy in another sector. Would there be a way to generate a correct copy from both? The thing is, we need software that generates reliable backups using unreliable media. This was done in the past. For instance, sectors would have redundancy in another sector of the same disk, spread around, so that a read error in a region of the disk is not fatal. I read about a software that created a redundancy set for a dvd, but needs to be stored somewhere else. If the dvd develops errors, the data can be recovered using that software and the error prevention set for that dvd. Nice idea, but cumbersome... that data should be integrated inside the same dvd. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF2tlXtTMYHG2NR9URAvmvAJ0aMavBAbUR5Tp/uTnBf8Vs7z4I5ACfe4lZ WbNjmIwtTYJa0RCPy/+hK3g= =ZXZ3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

The Monday 2007-02-19 at 19:55 -0600, Billie Erin Walsh wrote:

...

A while back I read an article, aimed primarily at genealogists, about archival quality DVD's. The, supposedly, best disks for long term, stable, storage are DVD+R's, and the best of those come from only one manufacturer. Taiyo Yuden. They are available through:

...

http://www.supermediastore.com/taiyo-yuden-silver-thermal-8x-dvd-plus-r-medi...

I would have to find a source closer to me than that.

I don't know. They are just as close as your mail box. -- (o:]>*HUGGLES*<[:o) Billie Walsh The three best words in the English Language: "I LOVE YOU" Pass them on! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tue, 20 Feb 2007, Carlos E. R. wrote:-

The Tuesday 2007-02-20 at 05:58 -0600, Billie Erin Walsh wrote:

...

I don't know. They are just as close as your mail box.

Mailing across an ocean is not cheap.

I've found some 8x DVD-R branded Aone that have the media ID TYG02. Not had a problem with them so far, but only been using then for a couple of years. Also found some unknown brand 8x DVD+Rs that have the ID MCC003[0] that I've also only used for the last year, or so, and also had no problems with. According to: URL:http://www.digitalfaq.com/media/dvdmedia.htm both of these are supposedly 1st class media and suitable for archiving. Interestingly, the above URL also states these are often the most expensive however the last 400 I've bought were only 12GBP per 100. Works out around 17 euros, or 22USD. I've also some 4x discs burnt around 5 years ago[1] that are still 100% readable. And for the last few years, just to make sure my backups are going to be recoverable, I have a quite decent[2] backup system: 1, use tar to create an archive; 2, split the archive into 100MB pieces; 3, use par2 to create parity files for recovery in case of a media failure, using a 1MB block-size and 535 recover blocks; 4, burn about 3.5GB of data, plus the 530MB of par2 files to DVD; 5, make a duplicate of the DVD. Results are that if there is a failure of the disc, I can use dd to salvage the readable files, recreate the broken ones and burn a fresh couple of copies. The only time this would fail is if both copies of the DVD, or more than 530MB of data on both discs, were unreadable. [0] Unknown because they're full-face printable, so no branding, and I no longer have the label for the 50-disc cakes. [1] From the time-stamps on the files. Regards, David Bolt -- Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/ RISCOS 3.11 | SUSE 10.0 32bit | SUSE 10.0 64bit | openSUSE 10.2 32bit RISCOS 3.6 | SUSE 10.1 32bit | SUSE 10.1 64bit | openSUSE 10.2 64bit TOS 4.02 | SUSE 9.3 32bit | | openSUSE 10.3a1 32bit -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Fri, 23 Feb 2007, Carlos E. R. wrote:-

The Wednesday 2007-02-21 at 00:40 -0000, David Bolt wrote:

...

...

And for the last few years, just to make sure my backups are going to be recoverable, I have a quite decent[2] backup system:

1, use tar to create an archive; 2, split the archive into 100MB pieces; 3, use par2 to create parity files for recovery in case of a media failure, using a 1MB block-size and 535 recover blocks; 4, burn about 3.5GB of data, plus the 530MB of par2 files to DVD; 5, make a duplicate of the DVD.

What is par2?

The home page describing it is here: URL:http://parchive.sourceforge.net/

I have a guess, looking at sourceforge, that is somekind of parity file standard for data recovery,

Yep. Uses the same sort of data recovery system to RAID.

but I don't see how to generate them.

The one I use doesn't have a GUI, although there are the sources for a GUI available. The way I use it is to open a console, change to the directory containing the files I want to create the PAR files for, and then use the following: par2 c -s 1024000 -c 535 -l * This then creates a series of recovery files, with a total of 535 recovery blocks, each with a block size of almost 1MB, and limits the size of the largest recovery file to a little over the size of the largest file. If I ever need to recover data from a damaged DVD, I would use a small script using dd to copy each file off the DVD to a directory on a hard drive, change into that directory, and then use: par2 r With the values I use, I should be able to recreate upto 5 missing files, or significantly more files if dd can copy most of the data.

What are you using, where did you get it from?

Source code from sourceforge, patched it to handle GCC4, and then built an RPM for it. I keep copies of it built for multiple versions of SUSE here: URL:http://www.davjam.org/~davjam/linux/par2/index.htm

I have found parchive... (http://en.wikipedia.org/wiki/Par2)

...

Results are that if there is a failure of the disc, I can use dd to salvage the readable files, recreate the broken ones and burn a fresh couple of copies. The only time this would fail is if both copies of the DVD, or more than 530MB of data on both discs, were unreadable.

This phrase in the wikipedia is interesting:

| Parchive files can be used for other purposes than Usenet transmission. | | * A patch is available for the DAR backup program SaraB here that | uses PAR or PAR2 to ensure robust backups.

Now I wonder if the "dar" we have in the distro has that implemented [...] it seems it does.

Dar may have PAR support built in but, since PAR2 hasn't been included in SUSE, I don't think it'll have PAR2 support. It may have but, since I haven't used dar, I've no idea. Regards, David Bolt -- Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/ RISCOS 3.11 | SUSE 10.0 32bit | SUSE 10.0 64bit | openSUSE 10.2 32bit RISCOS 3.6 | SUSE 10.1 32bit | SUSE 10.1 64bit | openSUSE 10.2 64bit TOS 4.02 | SUSE 9.3 32bit | | openSUSE 10.3a1 32bit -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-02-23 at 12:39 -0000, David Bolt wrote:

...

What is par2?

The home page describing it is here:

URL:http://parchive.sourceforge.net/

Interestingly, the distro has a "par" from that same page, but not "par". There isn't even a man page for "par". I guess from what you say that they are not the same. [...] I saw a link explaining the differences. What would I need to compile - from sourceforge? gpar2-0.3.tar.gz libpar2-0.2.tar.gz par2cmdline-0.4.tar.gz Curiously, they have "par-v0.1alpha.tar.gz", when suse has "par-1.1-62" [...] AH! It is hidden as "older releases", "par-v1.1.tar.gz". [...] The make run (par2cmdline-0.4) fails... reedsolomon.cpp:54: error: explicit specialization of bool ReedSolomon >::SetInput(const std::vector&) must be introduced by template <> reedsolomon.cpp:54: error: template-id SetInput<> for bool ReedSolomon >::SetInput(const std::vector&) does not match any template declaration reedsolomon.cpp:54: error: invalid function declaration And a lot more. ...

With the values I use, I should be able to recreate upto 5 missing files, or significantly more files if dd can copy most of the data.

Interesting :-)

...

What are you using, where did you get it from?

Source code from sourceforge, patched it to handle GCC4, and then built an RPM for it. I keep copies of it built for multiple versions of SUSE here:

URL:http://www.davjam.org/~davjam/linux/par2/index.htm

Ah! So you had to modify them... But... that is version "par2-0.4-5". At http://sourceforge.net/projects/parchive I can only see release 0.3 (feb 2006). Where does the 0.4.5 comes from?

...

Now I wonder if the "dar" we have in the distro has that implemented [...] it seems it does.

Dar may have PAR support built in but, since PAR2 hasn't been included in SUSE, I don't think it'll have PAR2 support. It may have but, since I haven't used dar, I've no idea.

No, it is "par" - form man dar: This has of course its limitations, in particular when a data corruption occurs in the vital part of the backup, i.e. the few first bytes of each slice, and the last part of the archive (the catalogue). In case you need to store archive on a bad quality medium, you could protect each slice with a Parchive recovery file. (see NOTES for more information about Parchive, and how to transparently run Parchive from dar) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGPhC0tTMYHG2NR9URAom+AJwNj09SaMRL4UWSFDiojK+Bjz+RmgCfc3Bg vJObtCmQMWPd7AUfN0JEPXM= =R2fq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2007-05-06 at 19:23 +0100, David Bolt wrote: ...

...

declaration reedsolomon.cpp:54: error: invalid function declaration

And a lot more.

GCC4 is a lot more strict than GCC3. You need to apply a patch to the sources to get it to build using GCC4. If you grab the source RPM from my site and unpack it, you'll have a copy of the .diff file you can use to patch the sources. Then you'll be able to compile without errors[0] :-)

Yes, I already did that, while writing that email. It built fine :-) But I find curious that the project people haven't adapted their sources yet.

...

But... that is version "par2-0.4-5". At http://sourceforge.net/projects/parchive I can only see release 0.3 (feb 2006).

That would be the gpar2 release. I don't build that, since I have no use for it. I don't build the libpar2 either, for the same reason.

...

Where does the 0.4.5 comes from?

It's the same as par2cmdline-0.4. I just dropped the "cmdline" bit. The 0.4.5 is actually 0.4-5, which is the fifth release of the 0.4 package.

AH! I see: your par2 is par2cmdline, I understand now.

[0] You'll still get loads of warnings, but the build will succeed.

Yes, I saw then. I ran a few scripts that form a test suite, no errors. Now I'm preparing a dvd backup, and will add par2 files to it, too. I have to study the possible command options first. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGPoUGtTMYHG2NR9URAtLDAKCO6C4oKf1ch+Cqpz44aLb7E/G8xACcCDw6 o0YmQArZQidbHpShSRTYxkM= =O/dW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Mon, 7 May 2007, Carlos E. R. wrote:-

The Monday 2007-05-07 at 03:46 +0200, I wrote:

...

Yes, I saw then. I ran a few scripts that form a test suite, no errors. Now I'm preparing a dvd backup, and will add par2 files to it, too. I have to study the possible command options first.

I'm baffled...

Ok, I have a dozen of big files (roughly the same size each) in a dvd, with about 250 MB free space that I could use for par data. What options should I use to create them?

I'd use something like this: par2 c -s1024000 -c235 -l * c is to create the recovery files -s1024000 gives a recovery block size of a little under 1MB -c235 says to create 235 recovery blocks -l limits the size of the par2 recovery files to just a bit bigger than the largest file. That should create a few recovery files which, with the par2 overheads, occupy about 235MB and leave around 15MB free. Once it's finished, and if you're the sort of person that just has to be sure, you can verify the freshly created files using: par2 v And, if there's a failure after the contents has been burnt, copy the contents off the DVD using either dd or ddrescue, and then use: par2 r Now, the bad news is that for a dozen files, totalling a bit over 4GB, you may not be able to rebuild a broken file with only 235 blocks without rescuing as much data as possible from the DVD. My guess is that the files are around 350MB[0], which means you'd need at least 350-360 recovery blocks to rebuild a completely missing file. As long as only one file is broken, and you manage to recover more than a third of the data, there _should_ be enough to rebuild it. There are ways to reduce this problem, and the one I chose was to limit the size of files to 100MB[1]. That, combined with my using 535 blocks means I can have 5 completely unreadable files before I am unable to recover. And when I want to recombine the split files, I just use cat :-) [0] After rounding to the nearest MB: 4.35GB - 250MB = 4.1GB 4.1GB / 12 = 350MB [1] split -b 100M -a 3 -d <filename> <filename>. ^ That is to allow creation of names in the format filename.000, filename.001, etc. Regards, David Bolt -- Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/ RISCOS 3.11 | SUSE 10.0 32bit | SUSE 10.1 32bit | openSUSE 10.2 32bit RISCOS 3.6 | SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit TOS 4.02 | SUSE 9.3 32bit | | openSUSE 10.3a3 32bit -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-05-09 at 21:20 +0200, I wrote:

Right now I'm running it like (275M free):

time nice par2 c -m500 -s1024000 -c250 -l recovery *avi .... Block size: 1024000 Source file count: 11 Source block count: 4305 Recovery block count: 250 Recovery file count: 8 ...

It finished like this: ... Computing Reed Solomon matrix. Constructing: done. Wrote 256000000 bytes to disk Writing recovery packets Writing verification packets Done real 146m40.182s user 71m22.424s sys 1m17.965s I expected the "real" time to be large, as I was doing other "heavy" things (a kdar backup that crashed), but the "user" time I expected to be the same of previous times. I see par2 is very heavy computation program... I wonder if it could be optimised. cer@nimrodel:~/crypta.mm_dvd1.x> du -hc recovery* 88K recovery.par2 1,1M recovery.vol000+001.par2 2,2M recovery.vol001+002.par2 4,2M recovery.vol003+004.par2 8,2M recovery.vol007+008.par2 17M recovery.vol015+016.par2 32M recovery.vol031+032.par2 64M recovery.vol063+064.par2 121M recovery.vol127+123.par2 248M total I ended with 28 MiB of free space. Not bad. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGQl3qtTMYHG2NR9URAhGUAJ0fHcWoVrwJ8oN+Ly4lMiU+BN/6hQCfdjny Lygk2WwNDaEqSNb49w4ddXk= =9frD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thu, 10 May 2007, Carlos E. R. wrote:-

The Thursday 2007-05-10 at 01:48 +0200, Carlos E. R. wrote:

...

I expected the "real" time to be large, as I was doing other "heavy" things (a kdar backup that crashed), but the "user" time I expected to be

I found an interesting thing. I'm doing a test run of dar - after kdar crashed I saw the command line it uses and it is not so difficult - and I then told it to use "par". I thought it was going to use "par", but no, to me surprise it uses par2:

... Adding file to archive: /usr/share/susehelp/mecreating PAR file for file /Grande/kdar/system_backup_10.2_20070509.2.dar ... par2cmdline version 0.4, Copyright (C) 2003 Peter Brian Clements.

<Snip>

and it is the version I compiled, too. Curious!

Very interesting.

The dar command is told to use par via the option:

-B /usr/share/doc/packages/dar/dar_par.dcf

which runs that script at the end of each dar slice, I understand. It contains:

<Snip>

So, for creation it calls "/usr/share/doc/packages/dar/dar_par_create.duc", which in turn contains this:

# change according to you need PAR=par2

I did not touch that, it is dated "2006-11-25". Funny that SuSE contains a script calling a program they do not supply.

That's in the documentation, which means it's supplied by the original authors/packagers, not by SUSE.

Maybe I'll bug the bugzilla chaps a bit ;-)

Maybe bug them to include par2. The sources are the same as from sourceforge, except for repackaging them as a .tar.bz2, and there's the patch for it to compile using GCC4.

(The par calling code is:

exec $PAR c -r$6 -n1 "$1/$2.$3.$4"

with the positional parameters being:

<path> <basename> <slice number> <extension>

Which explains why par2 can do the same job as par. That dar script doesn't use any of the features that aren't common to both par and par2. Regards, David Bolt -- Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/ RISCOS 3.11 | SUSE 10.0 32bit | SUSE 10.1 32bit | openSUSE 10.2 32bit RISCOS 3.6 | SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit TOS 4.02 | SUSE 9.3 32bit | | openSUSE 10.3a3 32bit -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

I have raised a bug because the current system back in yast only offers an incremental backup - so if you loose the first achieve your stuffed. The reply came back and described it as a Hugh code re-write within Yast and it was just a font end based on ---I forgot: I suggested that the new front end should be written around CPIO . The bug is now Assigned for a LATER status.. - Cross you fingers everyone Scott Carlos E. R. wrote:

The Friday 2007-02-23 at 12:39 -0000, David Bolt wrote:

...

...

What is par2? The home page describing it is here:

...

URL:http://parchive.sourceforge.net/

Interestingly, the distro has a "par" from that same page, but not "par". There isn't even a man page for "par". I guess from what you say that they are not the same. [...] I saw a link explaining the differences.

What would I need to compile - from sourceforge?

gpar2-0.3.tar.gz libpar2-0.2.tar.gz par2cmdline-0.4.tar.gz

Curiously, they have "par-v0.1alpha.tar.gz", when suse has "par-1.1-62" [...] AH! It is hidden as "older releases", "par-v1.1.tar.gz".

[...]

The make run (par2cmdline-0.4) fails...

reedsolomon.cpp:54: error: explicit specialization of bool ReedSolomon >::SetInput(const std::vector&) must be introduced by template <> reedsolomon.cpp:54: error: template-id SetInput<> for bool ReedSolomon >::SetInput(const std::vector&) does not match any template declaration reedsolomon.cpp:54: error: invalid function declaration

And a lot more.

...

...

With the values I use, I should be able to recreate upto 5 missing files, or significantly more files if dd can copy most of the data.

Interesting :-)

...

...

What are you using, where did you get it from? Source code from sourceforge, patched it to handle GCC4, and then built an RPM for it. I keep copies of it built for multiple versions of SUSE here:

...

URL:http://www.davjam.org/~davjam/linux/par2/index.htm

Ah! So you had to modify them...

But... that is version "par2-0.4-5". At http://sourceforge.net/projects/parchive I can only see release 0.3 (feb 2006). Where does the 0.4.5 comes from?

...

...

Now I wonder if the "dar" we have in the distro has that implemented [...] it seems it does. Dar may have PAR support built in but, since PAR2 hasn't been included in SUSE, I don't think it'll have PAR2 support. It may have but, since I haven't used dar, I've no idea.

No, it is "par" - form man dar:

This has of course its limitations, in particular when a data corruption occurs in the vital part of the backup, i.e. the few first bytes of each slice, and the last part of the archive (the catalogue). In case you need to store archive on a bad quality medium, you could protect each slice with a Parchive recovery file. (see NOTES for more information about Parchive, and how to transparently run Parchive from dar)

You only back or-order to restore - How do you fully restore and incremental backup if you loose the first file? Scott Carlos E. R. wrote:

The Sunday 2007-05-13 at 08:17 +1000, Registration Account wrote:

...

I have raised a bug because the current system back in yast only offers an incremental backup - so if you loose the first achieve your stuffed.

I don't understand this sentence... could you clarify, please?

...

The reply came back and described it as a Hugh code re-write within Yast

would that be "huge"?

...

and it was just a font end based on ---I forgot: I suggested that the new front end should be written around CPIO . The bug is now Assigned for a LATER status.. - Cross you fingers everyone

I have not used yast backup in a long time. I did study it, and I have a script somewhere that reproduces it's capability somehow.

It was based on the rpm command ability to generate a list of files that are included in the rpm database, but which were later on modified; parsing that list it generates a backup of those files in a modified tar gz format (one tgz per package in a bigger tar, I think). If you combine this with autoyast, you can recreate the system part of an install, storing just the files that were modified.

The snag is that new configuration files that are not in any rpm are not stored either, unless you tell it to store all files not in rpms - in which case the backup can be huge if you forget to tell it not to include home etcetera - and you need enough space to keep a temporary uncompressed copy of all.

Not very usable, but that was two years ago, I don't know wht they have improved on it.

I find all backups programs I try in linux to be lacking a lot.

PS. Yes, I also think cpio would be better than tgz. Much safer. There was a cute backup script inlcuded in the distro around version 7 or 8, using cpio.

This is the fundamental concept, we backup in a certain was so that if there is a data failure we can restore. If you need to restore a system to a particular date,and you use incremental backups The first part of the restoration is to get the backup file that we first complete as it contains every file. The next setup is to get hold of the incremental backup of the point in times the original full backup files were taken and when it is run it will over-right all files from base line full functionality to current required date. The expression "we backup so that we CAN restore" is covered more precisely in data security. The expression is based upon the issue if you are not correctly backing up you you can Never recover and hence the money you put into back is useless. The expression is timeless and covered in detail in data centre which have to be able to loose all data and then restore to a designated point in time. Scott :-) Carlos E. R. wrote:

The Wednesday 2007-05-16 at 08:36 +1000, Registration Account wrote:

...

You only back or-order to restore - How do you fully restore and incremental backup if you loose the first file? Scott

Sorry, I don't understand what you say :-?

What is "back or-order to restore"?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Registration Account wrote:

This is the fundamental concept, we backup in a certain was so that if there is a data failure we can restore. If you need to restore a system to a particular date,and you use incremental backups The first part of the restoration is to get the backup file that we first complete as it contains every file. The next setup is to get hold of the incremental backup of the point in times the original full backup files were taken and when it is run it will over-right all files from base line full functionality to current required date.

The expression "we backup so that we CAN restore" is covered more precisely in data security. The expression is based upon the issue if you are not correctly backing up you you can Never recover and hence the money you put into back is useless. The expression is timeless and covered in detail in data centre which have to be able to loose all data and then restore to a designated point in time. Scott :-) Carlos E. R. wrote:

...

The Wednesday 2007-05-16 at 08:36 +1000, Registration Account wrote:

...

You only back or-order to restore - How do you fully restore and incremental backup if you loose the first file? Scott Sorry, I don't understand what you say :-?

What is "back or-order to restore"?

Agreed, but there is a bit more to it than that. There are crudely two cases, the home user case, and the business case. (This is a very crude distinction). The backup strategy should be based on how one intends to restore the system. It is of no value if you can successfully save and restore operationally useless data. It is not just how you backup it is also what you backup, and thought needs to be given about what you backup and why you are backing it up. This also means that data management strategies should facilitate backup and restore procedures. The classic backup everything in sight approach while simple is probably rarely appropriate for most cases. One first has to look at the scenarios in which one has to restore.... a) The machine is physically unavailable. This can be due to hardware failure, physical destruction, or it has been half inched (stolen). b) Software failure due to malware, software bugs, user error, and data corruption. (One can get the latter as a result of a of course). Most people design their disaster recovery program around a, and tend to ignore b. However this classic backup technique does not give anything but minimal protection against b, and b is rather more frequent than most people are prepared to acknowledge. All you likely to recover is the same mangled set of data just before everything went pear shaped. It is probably not a bright idea to restore something only for everything to fall over again. Data integrity strategies such as raid or drive synchronisation are equally vulnerable to b. A differential (rather than incremental) strategy can protect against b to some extent because one gets a historical perspective on the status changes on a machines and ones has a better chance of restoring to a last good state, and plotting a recovery path so that good changes are not lost with the bad. However, full recovery can be time consuming especially when one has no idea when things started going pear shaped. It can take a bit of time for a problem to start and the effects to be discovered. The main problem with an incremental approach is that one can acquire a lot of unrequired data that can slow this process considerably. Either strategy is more of shotgun rather than a surgeons knife approach. It does help in the business case if database based systems are not only designed to backup current record status, but the transactions that lead to that status, and some kind of document management system is in place. The data can be dumped in an application specific format, and stored to appropriate media. Any backup strategy then becomes more application focused than system focused, and based on the history of application usage. (Which can make it easier to identify points of failure). One can then break down backups to system focused and application focused requirements. In the business case the initial objective is get the system operational ASAP. On could argue at its simplest user data on a system is in three different states (one can have more complex definitions of course) ... i) Currently Active ii) Recently Active iii) Historical (retained for legal or policy reasons). Other data should be archived to media. (A recent survey suggested that up to 50% of data on a system will never be accessed again). One does not need to restore everything immediately, merely that data which gets the business operational. As ii) and iii) are usually going to be significantly larger than i) it is best to prioritise i) and have it as a discrete media set. One also really needs to only backup religiously i), as data in ii) and iii) by definition will change little if at all and need a different backup policy. So one has a further breakdown of application focused backup by data state... I have never really understood why some people insist on backing up the OS structures in their entirety on a regular basis. One can either have a baseline image using a tool like dd, Ultris, or ghost, or just backup the configuration files and a record of applications installed. In a b type failure it is probably better to install a clean OS and application set than restore the old setup. In case a) it is usually unlikely one will end up with the same hardware configuration so an OS build from scratch would make more sense. So a system focused backup would tend to be more based on backing up configuration data rather than the system OS. This is a more sophisticated and complex approach than that required by a home user, and the home user is mostly poorly served by backup software. However some of the principles still apply. The home user also may have a further problem in that for those who do a lot of multi-media work file sizes can be massive, and appropriate removable media devices do not exist. Replication to drives based on the same machine is problematic, as is the caddy drive approach. One can encourage people to backup to media personal projects before further work is performed on the project (but how many take any notice), and most tools for writing data to DVD/CD are pretty clunky on both Windows and Linux platforms which does not really encourage the user to perform this task. What is probably needed is a simple tool which saves the changes to the system onto media after a days work or on request. (And flags things like iso images as needing copying separately). (After testing out KDar/dar, star and tar I have found a way of working with tar and DVD/CDs. Dar and star have been proved to be inadequate for my purposes for different reasons). I have been following Carlos's examination of par and media integrity checking with some interest but personally think media data integrity is probably not as significant an issue on optical media as the rather erratic stability of device support on both Windows and Linux platforms. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGTZm9asN0sSnLmgIRAm4yAKCoxuMYpXjv81HweIQVsDL77VcZlACgscIs 0gPdS3B6KJA6co/fuTtGnBw= =m1s4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

And for the last few years, just to make sure my backups are going to be recoverable, I have a quite decent[2] backup system:

1, use tar to create an archive; 2, split the archive into 100MB pieces; 3, use par2 to create parity files for recovery in case of a media failure, using a 1MB block-size and 535 recover blocks; 4, burn about 3.5GB of data, plus the 530MB of par2 files to DVD; 5, make a duplicate of the DVD.

Results are that if there is a failure of the disc, I can use dd to salvage the readable files, recreate the broken ones and burn a fresh couple of copies. The only time this would fail is if both copies of the DVD, or more than 530MB of data on both discs, were unreadable.

[0] Unknown because they're full-face printable, so no branding, and I no longer have the label for the 50-disc cakes.

[1] From the time-stamps on the files.

Regards, David Bolt

RAR also provides a options to "Create recovery volumes".... Ciro -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thu, 17 May 2007, Ciro Iriarte wrote:- <snip>

RAR also provides a options to "Create recovery volumes"....

AFAIK[0], you can't _create_ a RAR file under Linux, only unpack them. If that is still the case, being able to create recovery volumes isn't much help. [0] without actually searching any further than the contents of the SUSE DVD. Regards, David Bolt -- Member of Team Acorn checking nodes at 50 Mnodes/s: http://www.distributed.net/ RISCOS 3.11 | SUSE 10.0 32bit | SUSE 10.1 32bit | openSUSE 10.2 32bit RISCOS 3.6 | SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit TOS 4.02 | SUSE 9.3 32bit | | openSUSE 10.3a3 32bit -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

2007/5/17, Carlos E. R. :

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Thursday 2007-05-17 at 12:26 +0100, David Bolt wrote:

...

On Thu, 17 May 2007, Ciro Iriarte wrote:-

...

RAR also provides a options to "Create recovery volumes"....

AFAIK[0], you can't _create_ a RAR file under Linux, only unpack them. If that is still the case, being able to create recovery volumes isn't much help.

There is, I think, a linux shareware version of rar, which I tried years ago and found lacking a lot. Maybe they have improved, dunno. Also, the first version of the algorithm was some kind of opensource, but I haven't seen a linux version of that (and it couldn't compete with any of the current compressors, any way).

The wikipedia says (under "Archiver features"):

Variable amounts of redundancy (recovery record) can be added to an archive, making it more resistant to corruption. Even if parts of an archive are damaged, it is possible to fully recover the stored data if a large enough recovery record exists.

It is, of course, interesting, that a compression algorithm handles internally things like volume spanning and redundancy.

[...]

Yes, there is a current shareware linux version here:

http://www.rarlab.com/download.htm

- -- Cheers, Carlos E. R.

Just tried, and with the v3.60 SHAREWARE i can create archives with Recovery Records, and even add them to an existing archive.... I'm not sure what are the limitations, if any... Ciro -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-05-17 at 16:21 -0700, Randall R Schulz wrote:

On Thursday 17 May 2007 07:22, Carlos E. R. wrote:

...

...

Yes, there is a current shareware linux version here:

http://www.rarlab.com/download.htm

Really? I see only a "trial" version, nothing marked "shareware." Usually I interpret "trial" as being limited in either functionality or duration of operability, though I don't see any specific information on what precisely "trial" means for RARLAB.

I speak from memory. Years ago, when I used it, it was shareware: try it, pay later. There are references to the word in their page, and also to "buy". And if you look at the license file, you would see: "The RAR archiver is distributed as try before you buy". - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGTOfatTMYHG2NR9URAk+UAJ97j6SCUd7y8qmF2mwcLq8ub6tcvgCbBqp0 YW13p4hy2NcjO8KkkFgZhps= =VtOF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

...

...

Really? I see only a "trial" version, nothing marked "shareware." Usually I interpret "trial" as being limited in either functionality or duration of operability, though I don't see any specific information on what precisely "trial" means for RARLAB.

I speak from memory. Years ago, when I used it, it was shareware: try it, pay later. There are references to the word in their page, and also to "buy". And if you look at the license file, you would see:

"The RAR archiver is distributed as try before you buy".

-- Cheers, Carlos E. R.

It also says:

"Anyone may use this software during a test period of 40 days. Following this test period of 40 days or less, if you wish to continue to use RAR, you must purchase a licence."

The license is found at:

/usr/share/doc/packages/rar/license.txt

- James W

Well, i installed it 6 months ago, and still works.... Ciro -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday 17 May 2007 16:53, Gabriel wrote:

...

Mmm, try this http://www.7-zip.org/ it support a lot of formats including Rar and it's open source.

Not to mention this: % rpm -qa |egrep -i 7zip p7zip-4.39-2.guru.suse100 And if you have it installed (or install it) and do the obvious: % man p7zip p7zip: nothing appropriate. or % apropos 7zip or % aproppos p7zip p7zip: nothing appropriate. ... you should know that the command and the man page are "7z", "7za" and "7zr": % apropos 7z 7z (1) - A file archiver with highest compression ratio 7za (1) - A file archiver with highest compression ratio 7zr (1) - A file archiver with highest compression ratio Kind of boastful, eh? Sort of like "Best and lasts longest."

Regards.

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-05-17 at 20:34 -0400, Ciro Iriarte wrote:

Well, the key feature discussed is media error recovery....

Yes. Doing backups with redundancy (and posibly compression) with error recovery. What I have yet to verify is how well does rar save/restore linux filesystem attributes. When I tried it years ago it did badly. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGTWv7tTMYHG2NR9URAoL4AJ9rEgaEnmsz6VQ0D/KZHDoUZmzv+wCeK77u pB0NlHb3ShG+wxYa7D9E/No= =evK8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Monday 19 February 2007 19:55, Billie Erin Walsh wrote:

A while back I read an article, aimed primarily at genealogists, about archival quality DVD's. <snip>

How can any outfit claim 100+ years reliability for any product that hasn't existed for more than a few years? And, more importantly, how can anyone believe their claims? On that note, I have a bridge for anyone who does. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tuesday 20 February 2007 07:03, Carlos E. R. wrote:

The Tuesday 2007-02-20 at 06:51 -0600, Stevens wrote:

...

How can any outfit claim 100+ years reliability for any product that hasn't existed for more than a few years?

It is done by ageing tests. The item is subjected to stress, temperature extremes, vibrations, humidity, etc, to see how it behaves and make a durabilty prediction. They can be mistaken, but it is the best that can be done.

For instance... have you seen in Ikea a demo of a drawer being closed and opened about once per two seconds, with a compressed air piston? Measuring the wear they can predict durability in years for normal ussage of a few operations per day.

-- Cheers, Carlos E. R.

Sorry, old man, but you mistook my cynicism to be lack of knowledge. Auto manufacturers try to predict how their interiors and their paints will last, too, but until both are subjected to the Texas sun they are only guessing. The North has salt that kills cars; in the South it is the sun. Only when they obtain empirical data can they be sure and that data takes a long time to gather. The same goes for optical media manufacturers. Any longevity rating is a SWAG, at best, which is the reason for my cynical view. Fred (SWAG = Scientific Wild Assed Guess) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Tuesday 20 February 2007 13:39, David Brodbeck wrote:

Stevens wrote:

...

Auto manufacturers try to predict how their interiors and their paints will last, too, but until both are subjected to the Texas sun they are only guessing. The North has salt that kills cars; in the South it is the sun. Only when they obtain empirical data can they be sure and that data takes a long time to gather. The same goes for optical media manufacturers. Any longevity rating is a SWAG, at best, which is the reason for my cynical view.

Sure. As anyone who's ever had a couple of hard disks fail can attest, MTBF numbers are mostly fiction.

They're statistical measures. Everyone will experience a different actual failure incidence. It's also important to note what counts as a failure for the purpose of the values quoted by manufacturers. If they don't specify what their MTBF numbers quantify, _then_ I'd be suspicious. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

David Brodbeck wrote:

Sure. As anyone who's ever had a couple of hard disks fail can attest, MTBF numbers are mostly fiction.

Well, I can attest that you don't seem to know much about statistics. ;-) ;-) At one of my customers, 10,000s of disks are in use at the servers. There MTBF numbers are reliable indicators of how much disks one has to buy in advance to exchange the defect ones. Of course, being a statstical measure, it doesn't tell at all which disk will fail next, so it can only be used for purchasing decisions and not for precautionary actions. See also the recent Google report on that topic. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 21 February 2007 06:42:19 am Joachim Schrod wrote:

Joachim Schrod wrote:

...

David Brodbeck wrote:

...

Sure. As anyone who's ever had a couple of hard disks fail can attest, MTBF numbers are mostly fiction.

Well, I can attest that you don't seem to know much about statistics. ;-) ;-)

At one of my customers, 10,000s of disks are in use at the servers. There MTBF numbers are reliable indicators of how much disks one has to buy in advance to exchange the defect ones.

For the record, I should add that one needs to collect MTBF numbers (actually, MTTF and MTTR numbers) onself. Data from other organizations is not reliable, the variance seems to be quite high.

Therefore, this may be only of use for large installations, and not for SOHO or mid-sized environments that are probably most common on this mailing list.

Joachim has a valid point. Though this may be off-topic, I felt it important to state: In our data center, we have 4 EVA 5000 machines each with 168 physical drives. The drives range in size from 72GB to 300GB. We use MTBF in order to calculate our drive replacement costs for these machines. So far we're only replacing about one drive per month. The oldest EVA is roughly five years old. Now, the data center is climate controlled and entirely supplied by redundant UPS units. In addition we have a diesel generator for backup. The generator gets tested at least twice a year to ensure it kicks in. IOTW, the power never goes off and the temperature does not go above 65f/18c. OTOH, I remember getting a call in the early '90s from one of my then-clients. She ran a stationary store in Beverly Hills and her Novell 3.11 server was failing. When I got onsite, I found her mirrored 500MB drives were overheating due to the amount of dust encasing the drives and choking the fans on her DX/66 server tower. The server was enclosed in a closet in a back room of the store and had only been there less than a year. In other words, MTBF is an estimate one can use for professional data centers and is actually fairly reliable when the drives are appropriately used. -- kai Free Compean and Ramos http://www.perfectreign.com/?q=node/46 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2/21/07, John Andersen wrote:

On Wednesday 21 February 2007, Kai Ponte wrote:

...

So far we're only replacing about one drive per month. The oldest EVA is roughly five years old.

Well, according to that google report you can expect to see a significant rise in replacement rates, I'd wager.

Google's report is about commodity PATA / SATA drives. Those EVAs have quality SCSI drives. They are far more rugged than PATA/SATA and they are designed to work hard their entire life. (ie. IIRC 20% duty cycle is the design goal for PATA/SATA, 100% duty-cycle for SCSI) There really is a reason that SCSI costs more in general, and HP uses good SCSI drives on top of that. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

John Andersen wrote:

On Wednesday 21 February 2007, Greg Freemyer wrote:

...

There really is a reason that SCSI costs more in general, and HP uses good SCSI drives on top of that.

The good reason is that people believe they are better, not that they actually ARE better. Compare some drives side by side of similar vintage and size and you will find there is well in excess of 90% parts inter-changeability.

A reason for us to go to SCSI is that it's sometimes not obvious if an IDE drive can turn off the write-cache or have a battery-buffered write-cache. Both capabilities are essential for databases. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

|From: Kai Ponte [mailto:kai@perfectreign.com] |On Wednesday 21 February 2007 11:44:33 pm Joachim Schrod wrote: |> John Andersen wrote: |> > On Wednesday 21 February 2007, Greg Freemyer wrote: |> >> There really is a reason that SCSI costs more in general, and HP |> >> uses good SCSI drives on top of that. |> > |> > The good reason is that people believe they are better, not that |> > they actually ARE better. |And another good reason is that they are DESIGNED to run 24/7 |for extended periods. IDE drives are not built to the same |tolerances. You'll also find the MTBF is much shorter. This paper show there is NO connection between price, interface technology and MTBF: (The study covers more than 100.000 disks over many years): http://www.usenix.org/events/fast07/tech/schroeder/schroeder_html/index.html Google failure trends in large disk drive populations: (more the same but not so diverified) http://www.usenix.org/events/fast07/tech/pinheiro.html -- MortenB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday 22 February 2007 14:21, John Andersen wrote:

...

Yet some here persist (you know who you are Kai, ;-) in echoing the dogma of yesteryear as to why scsi is better. ...

I suppose "better" can be measured many ways. I can find 15,000 RPM SCSI drives but only 10,000 RPM SATA drives. I put one of each in my newest system. The 15,000 RPM SCSI is Ultra 320 and used as the system / root file system drive. The SATA drive uses the newer (SATA II, is it?) 300 Mbps interface. The SCSI drive is much smaller--only 36 GB--while the SATA drive holds 150 GB. The system is zippy, though. Let's hope the drive lifetimes are decent. One thing I've noticed is that as drives get faster (especially head positioning speed), mounting them properly seems to be more important. If the drive can physically vibrate within its mounting, it appears that ordinary head motion can lead to a head crash when the drive as a whole begins to move in response to the head be repositioned. My hunch is that sometimes head activity pattern creates a resonance with the drive as a whole and the magnitude of the drive's motions (in its ill-fitting mount) become sufficient to cause a head crash, or at least to increase the probability of one significantly. It's all a hunch though, but I had a couple drive blow-outs (full-blown head crashes--the data recovery people said there was a lot of brown dust inside when they opened it up!). Both of them happened on a tower I had assembled rather shoddily. Up 'til then, I'd never thought about the possible consequences of letting a drive simply rest, unsecured inside the box. Since then I've been careful to mount my hard drives very securely.

...

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday 22 February 2007 02:21:08 pm John Andersen wrote:

On Thursday 22 February 2007, Morten Bjørnsvik wrote:

...

|From: Kai Ponte [mailto:kai@perfectreign.com] | |On Wednesday 21 February 2007 11:44:33 pm Joachim Schrod wrote: |> John Andersen wrote: |> > On Wednesday 21 February 2007, Greg Freemyer wrote: |> >> There really is a reason that SCSI costs more in general, and HP |> >> uses good SCSI drives on top of that. |> > |> > The good reason is that people believe they are better, not that |> > they actually ARE better. | |And another good reason is that they are DESIGNED to run 24/7 |for extended periods. IDE drives are not built to the same |tolerances. You'll also find the MTBF is much shorter.

This paper show there is NO connection between price, interface technology and MTBF: (The study covers more than 100.000 disks over many years): http://www.usenix.org/events/fast07/tech/schroeder/schroeder_html/index.h tm l

Google failure trends in large disk drive populations: (more the same but not so diverified) http://www.usenix.org/events/fast07/tech/pinheiro.html

-- MortenB

Thanks for the references.

My point was that the historical differences between disk interface technology no longer exist, and manufacturer claims, in light of > 90% parts interchange-ability, are simply not believable, nor born out by actual use.

Tolerances are hardly germane when the entire physical structure other than electronics is often identical across drive sizes, interfaces, and product lines.

Yet some here persist (you know who you are Kai, ;-) in echoing the dogma of yesteryear as to why scsi is better. There was a time this was true. There was a time when a Lincoln was way better than a Ford.

I guess that is why I'm a pointy-haired manager - and why they don't let me in the server room. :P I can still find my way around stored procedures, though!

Seagate offers 5 year warranties on sata these days. When it comes to buying drives, given two offerings with close-enough specs, I always go for the longer warranty. Any minor saving in price today will be lost when the drive fails in three years instead of 5 or 8.

Wow - five years! I had no idea. I just bought some maxtor 320 GB thingy at fry's. I have no idea what warranty it has. -- kai Free Compean and Ramos http://www.perfectreign.com/?q=node/46 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday 22 February 2007, Kai Ponte wrote:

...

I just bought some maxtor 320 GB thingy at fry's. I have no idea what warranty it has.

Maxtor is Seagate's "Crap" line IMHO. I don't think the maxtor label carries 5 years warranty.

-- _____________________________________ John Andersen I wish I knew how many Maxtor drives I've thrown out, or seen thrown out! And I wasn't even in IT! I've had fairly decent luck with IBM drives, altho

On Friday 23 February 2007 01:48, John Andersen wrote: they're not made by IBM anymore--one of the Japanese companies makes them--I forget who. Anyway, treat your Maxtor tenderly. From what I've read--most recently here, BTW--heat is your worst enemy, so one of these drive-cooler fans that mounts right under the drive might be worth buying. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Greg Freemyer wrote:

On 2/23/07, Doug McGarrett wrote:

...

...

On Thursday 22 February 2007, Kai Ponte wrote:

...

I just bought some maxtor 320 GB thingy at fry's. I have no idea what warranty it has.

Maxtor is Seagate's "Crap" line IMHO. I don't think the maxtor label carries 5 years warranty.

-- _____________________________________ John Andersen I wish I knew how many Maxtor drives I've thrown out, or seen thrown out! And I wasn't even in IT! I've had fairly decent luck with IBM drives, altho

On Friday 23 February 2007 01:48, John Andersen wrote: they're not made by IBM anymore--one of the Japanese companies makes them--I forget who. Anyway, treat your Maxtor tenderly. From what I've read--most recently here, BTW--heat is your worst enemy, so one of these drive-cooler fans that mounts right under the drive might be worth buying.

IBM Laptop drives are now Hitachi. Not sure about normal size drives.

RE: Heat The Google white paper says they looked for a correlation between failure and heat. To their surprise they could not find one.

Greg Heat is an issue for hard drives. I use removal hard drives and the housing has an internal fan. The fan stopped. I didn't know it and I went through two harddrives very quickly before replacing the fan. Drives do well within certain temperature limits but the MTBF goes down quickly when one exceeds the specifications as I see it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 23 February 2007, Eberhard Roloff wrote:

John Andersen wrote:

...

Seagate offers 5 year warranties on sata these days. When it comes to buying drives, given two offerings with close-enough specs, I always go for the longer warranty. Any minor saving in price today will be lost when the drive fails in three years instead of 5 or 8.

Hi,

While it is always a good thing to have a longer warranty, I wonder what the perception of warranty is. Ex. I had drives fail well within the warranty timeframe. And it just means that you get your drive replaced or your money back. IMHO it does not necessarily mean that the drive will be more reliable.

Well that's about as cynical a viewpoint as I can imagine. They are warranting to me that I will have the use of their drive for 5 years for the same money that their competition will only warrant for 2 or 3 years. -- _____________________________________ John Andersen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Eberhard Roloff wrote:

John Andersen wrote:

...

Seagate offers 5 year warranties on sata these days. When it comes to buying drives, given two offerings with close-enough specs, I always go for the longer warranty. Any minor saving in price today will be lost when the drive fails in three years instead of 5 or 8.

Hi,

While it is always a good thing to have a longer warranty, I wonder what the perception of warranty is. Ex. I had drives fail well within the warranty timeframe. And it just means that you get your drive replaced or your money back. IMHO it does not necessarily mean that the drive will be more reliable.

Warranties give the manufacturer an incentive to make drives that will outlast the warranty period. Handling replacements or refunds costs far more than any profit they might have made. Warranties are not a guarantee that no drive will fail in that time. Only that they'll be replaced, repaired or refunded. So, longer warranties simply mean that most drives will last to the end of the longer warranty period. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

jdd wrote:

James Knott wrote:

...

Warranties give the manufacturer an incentive to make drives that will outlast the warranty period.

of course

...

So, longer warranties simply mean that most drives will last to the end of the longer warranty period.

of course not. Having a life insurance don't mean you will live longer...

this is better only if the street price is the same and if you can be sure your dealer will still be here then (I have a "lifetime waranty" ram on my desk nobody want to take back)

jdd

Although you can purchase insurance type warranties, you can't really compare life insurance with a product warranty. We all know that most of us will die eventually and insurance only helps with the financial details, supporting family etc. A warranty offered by the manufacturer states that they believe the device has some expected lifetime and with replace it if it fails sooner. They have a financial incentive to ensure too many devices don't fail prematurely, as replacements cost more than they earned on the sale. If they cut back on quality, they can expect the warranty costs to climb. The only thing comparable in life insurance, would be premium adjustments, based on life style i.e. non-smokers etc. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Saturday 24 February 2007, jdd wrote:

...

 So, longer warranties simply mean that most drives will last to the end of the longer warranty period.

of course not. Having a life insurance don't mean you will live longer...

Bad analogy. You don't get a new life from an insurance policy. You do get a new drive from a warranty. -- _____________________________________ John Andersen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

David Brodbeck wrote:

John Andersen wrote:

...

Bad analogy. You don't get a new life from an insurance policy. You do get a new drive from a warranty.

Actually, you don't get a new drive. You get someone else's broken drive that's been "factory refurbished." At least from every manufacturer I've ever dealt with.

So, the insurance companies should give you a refurbished life back? ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-02-21 at 12:10 +0100, Joachim Schrod wrote:

Of course, being a statstical measure, it doesn't tell at all which disk will fail next, so it can only be used for purchasing decisions and not for precautionary actions. See also the recent Google report on that topic.

Right. However... an example. The chaps maintaining my car do some kind of "preventive maintenance": they replace some pieces based on time and kilometers. When I check those pieces, they seem ok, but... who knows, I know they will not break on the road. Hopefully. I'm curious. On large installations such as those you and Kai mention, are SMART tests useful to predict failure? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF3J5itTMYHG2NR9URAj65AKCSIrHqqyQJdBZ9yyQ6MfZBdwcx3QCeMvJL 9NiFH3x3BiPt++kNCdyJhVU= =qKRv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Feb 20, 07 13:39:27 -0800, David Brodbeck wrote:

Stevens wrote:

...

Auto manufacturers try to predict how their interiors and their paints will last, too, but until both are subjected to the Texas sun they are only guessing. The North has salt that kills cars; in the South it is the sun. Only when they obtain empirical data can they be sure and that data takes a long time to gather. The same goes for optical media manufacturers. Any longevity rating is a SWAG, at best, which is the reason for my cynical view.

Sure. As anyone who's ever had a couple of hard disks fail can attest, MTBF numbers are mostly fiction.

Mean time between failure states the average time between to undetected read errors. This is completely unrelated to MTBB (Mean time between breakdowns ;) So de-facto MTBF doesn't tell you much. IMHO it's just good that the MTBF is usually much larger than the typical disk life time. Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-02-20 at 18:07 -0500, Doug McGarrett wrote:

Someone else sort of indicated, and I agree, that it is extremely unlikely that any device which can read any digital recording media of today will exist in 100 years. I would put that number at 25 years, myself, but it's unlikely that _I_ will exist in 25 years, so I won't know. The problem with data is that it is so massive. A phonograph record could easily last for 100 years (and some have) and the mechanism for playing one is not difficult to create, even if all of the existing machines are shredded in some horrible war, but there's no way to put enough useful data on a phonograph record.

I think there would ;-)

And in what format would it be? Is it expected that Unix/Linux will exist in the (quite distant for us) future? Or Fortran? Or even C++? Or M/S Word?

No, the language wouldn't be much of a problem, data is data. The main problem would be the hardware: having a dvd reader that still worked. I heard the NASA has problems reading their old tapes, and the main reason is that there are no readers and computers of that type.

I wonder if anyone is seriously considering these problems. or if anybody actually cares. I would think that scientists care, but what, if anything, is anyone actually doing about it?

Oh yes, absolutely. There are serious projects for that. I think there is an OS project that stores data in several formats and the software needed to read it. If the software dissapears, the data is translated, or a reader maintained. I can't remember the name. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF24yBtTMYHG2NR9URAm+AAJ9Rrs6G/y2vGp+l6q9opH9z4IHP9QCfYNbQ 4m9R4QBcuuzL/MR6sShXV30= =BSDE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 21 February 2007 00:07:07 Doug McGarrett wrote:

I wonder if anyone is seriously considering these problems. or if anybody actually cares. I would think that scientists care, but what, if anything, is anyone actually doing about it?

The work in this area covers a number of areas. One is, of course, the physical media. The other is the content. For that, I suggest looking at: http://www.digitalpreservation.gov/ I especially like to discussion of formats. It covers proprietary and open standards. http://www.digitalpreservation.gov/formats/index.shtml -- Roger Oberholtzer OPQ Systems AB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Monday 19 February 2007 12:55, Carlos E. R. wrote:

The Monday 2007-02-19 at 11:32 -0500, Greg Freemyer wrote:

...

AIUI, it relates to designed life of the media. For most CDs/DVDs it is pretty short (a year or two I think. And the glue from the back of the label will eat away your data. Don't use them.)

The initial designed life was ethernal. A century at least. Actual life expectancy after "improvements" is much lower. Well, maybe I'm thinking of CDs.

...

Check these out: http://www.kmpmedia.com/kodak-gold.html

That should be long enough for you (rated 100 to 300 years).

FYI: I was curious about the cost. $122 for 100-pack at http://www.datamediastore.com/kodak-cd-r-29150.html.

I wonder if there are more makers claiming similar durability?

-- Cheers, Carlos E. R.

Over many years, I have always found Kodak to be a very reliable outfit. What they say, they mean. If they promise 100 years minimum, I would take their word. I do not know of too many companies that I would take the word of. The difficulty with Kodak, is that if they are not selling a lot of the product, it's deleted, so if you decide on this media, you might want to consider getting enough to last for a while. At least until something better comes along--which it will, of course. --doug --doug -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org