Re: My Vintage Dream PC

Not running Linux on Cray.

These are Linux boxes, and more affordable as well. Likely even faster than the desktop Cray.

But you stored it on tape, not hard drives.

=20

be=20

Just to be nasty about it. Tell us what happens when you integrate monthly practice bare metal restores.

Damn, but you are amazing. When you make any statement of fact, I know I can prove you wrong with about 10 seconds of googling.

Always, always wrong!

John

Wasn't this a Borland evolution originally? C+ ?

Writing fast does NOT "make" bugs.

Why do that?

Once in a great while somebody loses a library file, usually a parts list, for some reason, so I go down into The Cave and find a backup with that file on it, and bring it back to work.

The server runs Linux on hot-plug RAID drives, and we have a bunch of spare machines around, and some working image disks. If the server explodes, we grab another machine and move the drives. If the drives are corrupted, we use one of the backups for the OS, and I'll have to drive home and pick up last Friday's DVDs to restore the company library. The whole thing might take an hour. [1]

Anything that is released to the library is presented to our librarian as hard media... floppy, CD, or DVD. After she copies it to M:\\LIB as the formal, logged release, I take the release media home and stash it in The Cave, too. So even the last week's stuff is available to restore.

It's worked for about 15 years now.

We archive tools, assemblers and compilers and such, too.

Some of my guys like to use a VCS, for reasons I can't understand. That's OK, as long as real, solid file sets are released that don't depend on the VCS.

John

He does incremental schema of some kind. OR he only has 20 or 30 GB of data. That would be pretty expensive anyway, and using re-writables is ludicrous. Optical is ludicrous actually.

With hard drives as cheap as they are these days, having shadow drives are really the best way. eSATA and even USB drives both write data way faster than a DVD writer does, and have ZERO likelihood of writing an errant bit for the most part.

One merely leaves work with the off site back up, and brings it back each day. If you feel it to be a problem, you can buy seven (or five) and have one for each day, like the old DAT schemas used to be.

SAS or Serial Attached SCSI is the best way if you have the bucks. The interface is also SATA 2 compliant, IIRC.

Anyway, that one blazes.

The most reliable optical solution is DVD RAM, and it ain't cheap. VERY reliable, however. Most current PC writer drives will write to DVD RAM. Unless you buy crap.

Your "backup guy" is in the Barnum family, and you are... well... every minute...

Which one? The big floor model or the desktop unit? Try again.

No. I said zero-based backup.

OR he only has 20 or 30 GB of

Yes.

That would be pretty expensive anyway, and using re-writables is

Blank DVDs are cheap. We buy them in packs of 200, around $50.

The problem with reusing any backup media is that if you lose or corrupt a file on the server, the corrupted file sooner or later winds up on all the backups... in just one week in your example. That's why we do backups to burn-once DVDs.

We use DVD-R, cheap one-time disks, write and verify. I store each backup set in a ziploc baggie, in The Cave mostly. It's cool and dry there, under the garage. Even if 95% of the backups go bad, there will still be plenty of good ones. So far, I've never had a read error on ones I've pulled to look for old files.

John

No. CHEAP blank DVDs are cheap. They are also not very good at archiving data reliably. High quality blank DVDs are not cheap. Buying in bulk helps, but your price sounds like it is a cheap brand as well.

I guess you are shredding the older sets?

What a waste.

Hard drives are far cheaper, and you don't have some dope that talked you into letting him do your backups for you for a fee some time ago. Is he bonded? Does your government contract holder know that you do this?

You really do not know much about it then.

ALL files on the volume get re-written on each session.

The five day schema actually ensures that you will likely be able to find the non-corrupted file, if you catch that it was corrupted soon enough.

And your disc based burn once method doesn't change the fact that if you write a corrupt file down to it, it will still be there the next day, and unless you catch it on the server, it will also migrate down to any subsequent write sessions and fill up your archive with the same file. Your method escapes nothing. It just forces you to keep your archives longer, even more risk. Can't do this kind of stuff in large, heavy government contract oriented companies.

Of course real companies have hundreds of servers and facilities in several cities, and they have the right backup mediums being used at all times, and no third parties are ever involved.

Version control systems are quite handy in storing data. You don't have to keep hundreds of releases of the design in some file hierarchy. Also all the tools can be stored in to the VCS. And with proper VCS including configuration management the same enviroment can be brought up in a few seconds (the time it takes to edit configspec etc.).

VCS is quite nice also while figuring out when a bug was fixed by browsing trough version history, or who to blame for the bug :) And in multisite environments VCS can be used to replicate data reliably.

--Kim

If you look at them with the assumption of their primary business, it gets even clearer.

None of their work, AFAICT, has enough paranoia. Putting pieces of an app's context directly into the kernel would have given us the willies.

/BAH

None of the above. I was thinking about xray scanning at airports, etc.

I have no faith in EMC requirements. I had a stove in Southboro which had to be unplugged in order to tune the radio to any AM station. The tech who was called about this problem made the comment, "Nobody listens to AM radio anymore."

that's what the kiddies are getting taught these days.

/BAH

I doubt it will be eventually. You'ld see it almost overnight. Coders do not code well if the resource seems to be unlimited.

You haven't been out in that cold cruel world much.

TW lost a bet with Jim when TW commented that the RP07 couldn't ever get filled up. It only took us about 3 months before we had to start deleting files on that structure.

/BAH

Let me see if I can explain better. When we increased the CPU speed, the system became I/O bound. When we increased the disk controller speed, the same system would become CPU-bound. When we increased the speed of the CPU, the same system became I/O bound... The same things happen in today's biz. Hardware developers concentrate on the solving the problem of today. So if the CPU needs to be speeded up, they'll work on speeding up the CPU. Then, when that's done, the performance lags show that the I/O needs to be sped up. So the next project is to produce a faster peripheral. This gets out to the field and, all of a sudden, the CPU performance sucks. It's a cycle.

/BAH

But the second one is the one who is doing the I/O that is required to "save" the data. [I'm using John's proposal of master/slave].

/BAH