Path: utzoo!utgpu!watmath!xenitec!edhew From: edhew@xenitec.uucp (Ed Hew) Newsgroups: comp.misc Subject: Re: Backup motivation (Was: Need HELP recovering files from tar damage) Summary: using a smattering of war stories Keywords: Backup Message-ID: <1989Jul30.055705.6641@xenitec.uucp> Date: 30 Jul 89 05:57:05 GMT References: <4385@merlin.usc.edu> <18567@mimsy.UUCP> <11668@orstcs.CS.ORST.EDU> <200@iclswe.UUCP> <1096@nbife.NBI.COM> Reply-To: edhew@xenitec.UUCP (Ed Hew) Followup-To: comp.misc Distribution: na Organization: Xenitec Consulting Services, Kitchener, ON Lines: 67 In article <1096@nbife.NBI.COM> ron@nbife.NBI.COM (Ron Schweikert) writes: >In article <200@iclswe.UUCP>, lars@iclswe.UUCP (Lars Tunkrans) writes: > >> How do you guys make people do their bakups ? > >Unfortunately with most customers, they don't *want* to until they >have lost data. All you can do in advance is to try to tell them that no >matter how great your hardware is, you can't control the thunderstorms, the >power company etc. Things happen that are unforseen. I can't recall >personally that I've ever had to work with a customer who lost data *twice*. > >They learn after the first time, unfortunately the hard way... I teach SCO Xenix classes (amoungst other duties). Aside from covering the course materials, there are three areas I stress: 1/ Security 2/ Backups 3/ only be root as long as necessary To illustrate points 2 and 3, I use the following (true) story: One night I was adding some sxt devices to eliminate a "lack of resources" problem when using shell layers in SCO Xenix (this was long before we had mscreen and the nifty new hardware we now have that let you run 8 ports per serial tty, etc). Unfortunately before I knew it, my script had gone off and created several *thousand* additional sxt's, and I really didn't want them lying around, so I used a nifty little program called "keep" (the opposite of "rm") to keep the ones I wanted and discard the rest. Too bad I didn't specify my paramaters correctly, because (logged on as root), it did exactly what I told it to do, and rm'd all my devices, keeping of course the two sets of 7 sxt's I *did* want. It was about 3am after one of those marvelous 18 hour days, and I went digging for my distribution media (for a partial reinstall), and my *backups*. I had both handy (especially #2), so the system was up and waiting for it's users in a couple of hours, long before they came in to work. Since my average class consists of prospective corporate system administrators, they usually understand the portent of the scenario, and have their employers call the sales dept for some DC600's. It's inevitable that over a period of time everyone makes a mistake, so all you can do is to backup your data as insurance against that day. I try to use the personal approach to all this: "How pleased is *your* boss going to be when you go in and tell him his company is down because you didn't make backups"? Small companies where it's the employer taking the course really get the message. As you point out, they only have to make the mistake once, and I try to let them use this example as their mistake. (There are a few others I toss in during the course if they seem dubious). This makes our tech support people happier too. Nobody ever likes to tell a client that "it's gone!", and for $85./hour we'll verify that fact. One little tidbit I use: "The only question is not *if* your hard disk will fail, but rather *when*". >Ron Schweikert >303/444-5710 x5026 >{allegra,ucbvax,ncar,isieng}!nbires!hardy!nbife!ron Ed. A. Hew Technical Trainer Xeni/Con Corporation work: edhew@xenicon.uucp -or- ..!{uunet!}utai!lsuc!xenicon!edhew ->home: edhew@egvideo.uucp -or- ..!{uunet!}watmath!egvideo!edhew ->home: changing to: edhew@xenitec.uucp [but be patient for new maps] # I haven't lost my mind, it's backed up on floppy around here somewhere!