Re: My Vintage Dream PC

High reliability = 2nd CPU is back up, not slave.

Andrew Swallow

Well, we've never had to do a full restore. I do occasionally dig into The Cave and pull an old CD or DVD backup, like when I'm working at home and want to see an older design, or the rare occasion when a file is missing or otherwise wrong in the M:\\LIB directory. The files are always there, no problems so far.

They're just files burned into DVDs. Not a lot can go wrong. Doing zero-based weekly backups onto write-once media gives us a lot of redundancy.

John

We burn and verify. Of the ones I've pulled from storage, some many years old, I've had no read errors. And the backup redundancy - a full set burned every week - is huge.

WHAT? These are ARCHIVE BACKUPS. Why would any sane person shred them? We KEEP them.

They're not cheaper unless you reuse them, and that has the propagating-corruption problem as noted.

Fee? The guy who burns the backups works for us, and it doesn't take much of his time to do it. The Cave is under my garage. One other employee takes an occasional set home for storage. And I take a set up to Truckee now and then.

What sort of backup procedures do you do?

John

It works and is very, very unlikely to allow us to lose anything.

Yes, but it over-writes existing copies of those files, no?

"Corrupted" can mean missing, or changed for some reason. We may not know that happened for years. Sometimes somebody will, for example, change a manual or a parts list, and later we want to see the older versions. A rolling backup would lose the old versions. We've also had a few occasions when a file just went missing, but both the original release medium, floppy or whatever, and the weekly backups are available in storage.

All burns done before the file was corrupted will be correct, and ones after the corruption date are bad. But we have them all.

Newly-released files are inherently tested, because they are what manufacturing uses to make stuff. It;s the older infrequently-used stuff that doesn't get tested often, but by that time we have tens, maybe hundreds of good archive copies.

Why is keeping baggies of DVDs, in boxes, in a few secure locations, a risk?

Can't do this kind of stuff in large, heavy

I don't do large or heavy.

My son-in-law does nuke weapons stuff, and works with explosives. I commented that that must be fun and he said, no: by the time you deal with the management, range safety, security, blah blah blah, you get nowhere near the shot, and there's no fun at all. When we want to blow something up, we go into the lab, or onto the roof, and blow it up.

Thank Goodness I don't have a real company. We just have fun and make money building electronics.

John

Those words, "hundreds of releases of the design", give me cold shudders. We use a military drawing control system, and any product - hardware, software, mixed - is formally released as a set of standalone, numbered documents with rev letters, all under a master bill of materials, itself numbered and rev lettered. Only manufacturing makes and ships things, and only from the formally released files.

The idea of casually shipping rev 2.3.04b is a nightmare.

Also

How do you know that you'll be able to run the VCS ten years from now, and that all the files will be intact? How do you know which customers are running which of the hundreds of possible versions of one product?

Who manages the VCS?

More important, of the copies of your things that have ever been shipped to customers, what fraction had one or more bugs?

Each of our formal letter release packages has a README file that notes the reason for and nature of all changes. If a bug was fixed, it's documented there. Releasing another package is a big public deal, and if it was because of a bug, everybody knows it. It seldom is.

John

Oh, yes. Compare to the cost of having someone write them, I suppose you _could_ give the job to an intern. And on the data is much easier to verify latter if it's on a hard disk. Even USB drives can be bought for around $100 a Terabyte and I AFAIK the data retention is better and naked drives would be better.

I'd checksum them though. That way one could do a quick check now and again. I remember on company that lost it's data even though it was backed up to two drives, because the writing machine had a bad SCSI board.

Chez Watt?

It's either zero or it's non zero. If you a one in a million guy in China there are a thousand people just like you.

Few real companies around, I suppose.

It's shocking how many companies can't find source files, or can no longer assemble the tools to edit and regen products. I've shipped over 3000 temperature controllers because a biggish British company lost the business; they refused to modify some code, because they couldn't modify the code. Well, their thermocouple front-end sucked, too.

John

Proper file maintenance and backup won't (probably) affect *this* quarter or the next, so it gets put under the VP of blue sky which is a position generated mainly to satisfy equal opportunity laws.

The Silicon Valley culture - use the trendiest tools and languages, job-hop often, product lifetimes measured in months - doesn't encourage long-term planning.

John

There is no such thing as a write once hard drive, idiot.

That stupidity is pretty damned pathetic coming from someone claiming to be an engineer.

No, it does not. You are supposed to check your system for errors BEFORE performing the backup, ass.

If you performed it correctly NO files will be corrupt. If they were written as a valid file, and the app put corrupt data in there, that is another thing entirely, and that will still propagate onto any backup media or methodology you are planning on using.

You are obviously clueless about it, and not caring to reduce the cost of your belabored method of choice.

Also, if you had any brains at all, you would simply create a RAID solution with bit striped, hot swap drives in place, and then you only need to do an incremental off site-over-the-net backup each day to another HARD DRIVE device at the remote location. Your in house data is

That is where things are right now. You go out and get an ultra SCSI SAS solution that incorporates a RAID array, and a chassis with hot swap drive bays and power supply bays.

Once a file is (successfully) written, it is impossible for it to become corrupted short of the entire bank of drives taking a dump all at once. Even then, it is technically recoverable, just a bit more costly to do so.

The data is more secure (absolutely secure, in fact), and it reads and writes faster by way of both the interface as well as the array schema.

SAS is the way to go. You can even get 15,000 rpm mini drives and make small arrays that you could slip in and out of a system as an entire array. No need for drive bays with those little critters.

So what?! The whole idea is to write the CURRENT data set, dingledorf!

Especially thankful that it is not "large or heavy" as well.

Buy some hard drives and an NAS chassis John. It is cheaper, faster, more reliable, and you can stop pissing and moaning about your engineers' private directory sizes.

Deviation approvals are a pain in the ass too.

That is why full revs are utilized often, and also why the number climbs quickly until the final design cycles have been run through.

Mid rev shipments MUST show as deviant from the final design or you can experience serious field problems that in some cases could cause serious failure or repair mode problems at inopportune times.

Full write with full verify against original data.

We never ship "mid rev" anything. Only formally released things are shipped, and releases advance by rev letter. And we know exactly what hardware and firmware every customer has, on every serial numbered product. If we do find a bug, or make an improvement, everybody gets notified.

Bug fixes are free, forever.

John

I am one from upwards of twenty billion, when one considers once living souls. Perhaps even more.

Hard drive on-drive-electronics does a pretty good job of checking EVERY write, and examining the sector condition, and automatically mapping out bad sectors. With the SMART turned on, before the drive dies, one usually gets a warning, if one watches one's BIOS screen during boot like one should.

So it is pretty much zero chance to write it wrong and have it get reported as having been written correctly. Particularly since the write gets checked internally at the hardware level by the drive itself, regardless of the file system or control that performed the write. The odds are astronomical, in fact. That is the whole idea with mass storage of data.

We have gotten better and better at it all along. Look at the current densities. They shattered records!

As a counter, examine the way a floppy drive works on current mass produced, mass quick formatted cheap media. It is hard to maintain a drive that works well, and it is hard to keep the discs' data integrity up.

My 2.88 drives or media NEVER fail, but finding BIOS support for it is no longer existent for the most part.