You can never have too many backups. Also, you can never have too many backups In this modern era when massive amounts of storage can be had for pennies on the gigabyte, it's easy to forget that it was not always thus. Once upon a time, keeping business data safe was a cost- and labor-intensive process. In this week's instalment of Who, Me? we meet "Boyle," who wrote a COBOL program in the early 1980s …
Honestly, I couldn't really follow the article after reading that back up procedure. I think it got my mental processing into a bit of an infinite loop. Does it sound like he just copies things back and forth from the live to removable and vice versa until quitting time?
It seemed straight-forward to me, but then I have the advantage (?) of having had to go through the exact same rigmarole at around the same time.
It's pretty much the same process you'd have to go through to copy a byte from one memory location (=exchangeable) to another, when you can only go via the accumulator (=fixed), and you have to leave the accumulator untouched.
Ee it was fun in the old days.
The application used both the fixed and removable disks. The problem was then to back up both of these whilst only having the removable drive. The only backup route is fixed to removable.
So first remove the working removable and replace with a blank disk to back up the fixed. Half the job done.
Now how do we back up the working removable? Because it can only be backed up from the fixed disk it has to be downloaded to that first, then backed up to a second blank disk.
We now have the fixed disk occupied by the copy of the working removable so that has to be overwritten by the backup taken at the first stage.
All understandable when you think about it. It's also easy to understand how it can go wrong if you're not thinking too carefully about it.
There's a vital, but missing, bit of information, which is that the machine would seem to have just a single disk drive unit, which consists of two recordable disk volumes on a common drive shaft. Each disk volume can store 5MB of data and has its own, independently addressable set of read/write heads. Only one of the disks is removable.
Lets call the volumes F (fixed) and R (removable), and the pair of removable disks they will be backed up to, B1 and B2.
The backup operation the article describes is the only way you can back up both F and R. This requires the following set of operations:
1) remove R and replace it with B1.
2) copy F to B1. This is the backup copy of F.
3) remove B1 and put it temporarily on a desk.
4) replace R.
5) copy R to F.
6) remove R and replace it with B2.
7) copy F to B2. This is the backup copy of R.
8) remove and store B2 in the data safe.
9) replace B2 with B1 (on the desk).
10) copy B1 to F. F is now the same as it was at step 1
11) remove and store B1 in the data safe. It is the backup copy of R.
I was once familiar with these shenanigans because the ICL 2903 also had one of these fixed and removable, 5MB per volume, drives. The fixed 5MB volume was usually the system disk, with the business programs and data on the removable 5MB volume.
The one I developed a system on also had a separate 60MB removable drive, so we only used the removable 5MB volume for backups, which was good, but this rig had its own problems because, while the 2903 was happy in an office environment, the 60MB drive wasn't - and the whole system was in a normal NYC office environment.
This was fine in summer because both people and the 2903 system needed cooling, but caused fights in winter because the office could only have heat or aircon on - never both - and so the ESD60 played up in winter.
That sounds like a wordy and overly complicated way of saying it's a Tower of Hanoi problem :-)
Or the old fox, goose and grain puzzle, in which a farmer has to get all three across a river, using a boat that can carry only one at a time, without any unapproved eating going on in his absence. (It's a bit of a mystery why a farmer would be transporting a fox, but that's the problem as stated.)
I think step 11 should say "It is the backup copy of F" but, apart from that, your interpretation is the same as mine.
You have no downvotes as I write this. If you get one, is not me: the process is confusing enough that the error is understandable.
This post has been deleted by its author
That's correct - step 11 should say F, not R. Spotted that myself just now (next day), which is embarrassing since I'd checked it twice before hitting 'POST'.
Thank Dog I never had to execute that process as a routine backup procedure - its far too complex to be safe.
I don't recall where we kept the system backup, but it was probably on an EDS 60 diskpack, since we needed one of those to install software updates - IIRC ICL's NYC head office system was a 1903S which only had EDS 60 disk drives.
@Martin Gregorie - Nice description. Makes it easy to see that from step 5 to step 10 there is only a single copy of F, which is the weakness of the procedure and probably contributed to the snafu. The classic solution would be using a Grandfather-Father-Son rotation (should we call that Grandparent-Parent-Child now?), so there would still be two older copies in the event of any mistakes. Alternatively, use a single scratch disk to make a second copy of F after step 3. Or do both.
But how to justify getting all those extra expensive disk packs? Telling the boss, "it's in case I make a stupid mistake" would probably be career limiting. However, the backup is when the disks are most heavily used, read and written from end to end, and therefore the most likely time for a fault.
This post has been deleted by its author
At first reading it made no sense to me either. I suspect it was a case of Programs + Data > 5MB. So they had the software on the fixed 5MB drive and the data on the removeable 5MB. So the procedures was probably:
1) Remove existing data removeable (R1).
2) Insert blank removeable (R2)
3) Copy software on fixed (F) to (R2).
4) Delete software on (F).
5) Insert (R1)
6) Copy data from (R1) to (F)
7) Insert blank (R3)
8) Copy data from (F) to (R3)
At this point you actually have 3 copies of the data on (R1), (R3), and on (F).
9) Insert (R2)
10) Delete the data on (F) and copy the software from (R2) to (F)
11) Insert either (R1) or (R3), and label and store the other as a data backup.
At this point you are done.
Yeah, it was convoluted, but the cause was that the actual (F) drive was too small to fit all of the software + data and so the (R) drive was being used for live storage.
Now, if you really want to talk about kludges from that era let's talk about using a videocassette recorder for backup...
We never (for specific values of never) had any problems with the Alpha and its backup system. VHS was so much more manageble for the customers (they weren't afraid of a VCR)
BTW Did you try restoring the Tomorrow's World transmission, claimed to be the whole of Alice in Wonderland? Well it wasn't, it was the first couple of chapters... we asked Alpha about that and they guy said he got bored after typing for a while.
I would say that being able to restore data from a public TV transmission is an indication of how adequate the VCR solution was!
I really liked the Alpha Micro - we had all sorts of fun with them (or, more specifically, with the software that needed porting over to them from some other machines).
Ah yes - AlphaMicro Systems! I remember that videocassette backup. The newer systems remotely controlled the video recorder as part of the procedure.
On the older systems however.... the video recorder was NOT remotely controlled. So you had to set the video recorder to start recording at a certain time - exactly as if you were trying to record a TV program on a schedule. Then you made sure (tried to make sure) that the backup started shortly afterwards.
Many a happy* day spent searching for the start of the backup which was hopefully somewhere on the tape.
* For a given value of "Happy".
Copy both the live fixed and live removable each to a blank removable and store the two no longer blank removable as your backups.
Having to overwrite the live fixed during the procedure is necessary since you can only read or write from one removable so copying the live removable means its contents must be written to the live fixed, which has to be restored from the backup later. The procedure is a bit of a shell game as a result of that limitation - being able to use two removables at once would have made things MUCH easier.
If I had to do it I wouldn't be worried about about forgetting that rather simple procedure I'd be worried about losing my place in it (since I'm sure those copies took a decent amount of time, leaving you to find something else to do while you wait) or forgetting which removable was which as you'd be leaving them lying about nearby as you completed the process.
You'd need to have the live removable and two blank removables clearly labeled, plus a separate sheet to check off which steps you had completed so when a copy finishes you know which step needs to be performed next.
When I read that procedure in the article I thought the story would be something like he was leaving it up to the operators to do and they screwed it up, or an emergency on a different machine caused them to stop halfway through and they forgot their place.
And that's exactly what I did... afterwards. It was 1980. It was a minicomputer. I was 24; it was one of those 'Hey, Tim, you're going to school for computers - set us up a computer'. So I looked on the Internet for advice, and there was nothing there! :)
There were no 'operators' - there was me. And I lost my place.
I'd have killed for two removables. A few years later we got 1/2" tape, and I thought I was in heaven.
Physical reasons. The drive units were combined fixed and removable controlled by a processor. For performance reasons it was better to add a new set rather than daisy-chain another storage unit to the controller and have it struggle managing 2x storage. Processor memory was sparse back then. You couldn't back up across two controllers for network speed reasons, but disk to disk on one controĺler worked reasonably fast.
The drive units consisted of a fixed drive and a removable drive pack. On Datapoint, we put the indexs on removable and data on fixed. At backup time, shutdown app, remove index pack, install backup pack. Copy fixed data to backup pack. remove backup pack, reinsert index pack and restart app.
If fixed fails, copy from backup pack to new fixed. install index pack, run a reindex script to regen all index files on the removable pack. Start app.
On large systems, there were multiple drive units that were backed up in parallel. Backup/restore times were consistent. Run out of storage, add another drive unit and storage processor. Redistribute data and indexs across all drives as required.
Easy money.
The DG issue is they had data everywhere making backups a lot more complex and time consuming.
The procedure is maybe the best that can be done, but as the fixed disk's content is overwritten with the temp copy of the removable, any failure (wet, soft, or hardware) at that point and your system is FUBAR.
Having e.g. a tape would have been better but possibly too expensive.
Also it's not thread safe :-)
Tapes were of the IBM Mainframe Open Reel variety, probably not even available at the time. There were 8" floppies; mainly useful to import or export a dataset for another system. These systems started out as cost effective data entry environment vs. expensive mainframe terminals. Eventually they grew with the 10meg disks and later 60meg multiplatter storage options, enough to run complex apps in their own right.
4030J/R 9 track, 45 IPS 800 BPI
4030L/T 9 track, 12.5 IPS 800 BPI
6021/6023/6025 9 track, 75 IPS 556/800 BPI
4169A/B 9 track, 45 IPS 1600 BPI
They also had some 7-track units. Info from Data General's "User's Manual / Programmer's Reference / PERIPHERALS" pub # 015-000021-07, Rev 07, August, 1977.
Yes, I owned a Nova 4 (no tape drives, just 5+5 fixed/removable hard disc and a floppy drive).
This story reminds me of talks with my dad, an IT guy in the times when all IT guys knew each other by name. He would say "you youngsters have it easy with IDE ATA. I used to spend whole weekends with a screw driver and an oscilloscope to get the heads in line". Or "you youngsers have it easy with BIOS and MBR. I used to have to enter the first 16 opcodes by hand to make the machine eat the punched tape with program on it". Or - to me and my brothers when we requested another 16 MB memory for our Cyrix 266 - "what on earth you need another 16 MB memory for? We ran a whole steel factory on 8 kilowords of memory for a decade!"
On his last job before retirement he got a company iphone. He called me asking for help: "I got a black fondleslab, I don't know what to do with it." What brand is the smartphone, I asked. "I don't bloody know, there is nothing written on it, must be some cheap Chinese thing"... After a bit of to and fro, my dad understod it quite well actually: "so it's just a portable computer with a modem in it, nice thinking, I can live with that." He called me a week later: "I think I understand it now. One question though: How do I end programs to save battery?!"
Even today, he lives on 70 MB monthly plan.
Not much to do with the article, I know. It just reminded me of how cool my dad is. I fear that getting DisplayLink to work without systemd or wrestling with NPM will never qualify as cool...
You've reminded me of the very snazzy video recorder I had in the last big years of VHS. It could pull titles off the analogue programme guide when you queued up a recording and let you search a database of (I think) up to 99 cassettes by title on the internal storage. It would then prompt you to insert a specific cassette number and cue up the programme based on data it added to the tape. Incredibly cumbersome by modern standards but incredibly futuristic at the time.
When school got an RM 380Z with a floppy drive, our head of maths (isn't it always) was convinced that CP/M only allowed single letter filenames. His SOP was to have one floppy disc per class, and assign a letter to each pupil. Some pupils had to share their letter, with predictable results... He thought it was wizardry when I showed him what was possible. Didn't ever change though, as it was written down.
I spent an unholy amount of time writing a RENUMBER routine for the C64 in 6502 assembler, calling subroutines of the built-in BASIC interpreter. Although I would regularly run out of line numbers while hacking around with BASIC, I am quite sure that I saved only a fraction of the time that I invested in writing RENUMBER.
Fortran.... The language I was never taught but the one I didn't need any lessons (for my purposes). I must dig out my old programmable calculator that used a version of Fortran.... My colleagues thought I was a wizard because my (ostensibly simple) calculator could produce answers to some complex problems.
What? Of course I haven't thrown it away.
FORTRAN was what I learnt at university in 1971 (a module in the first year of a Materials Science BSc). I never used FORTRAN since that course - but my first employer (in 1974) had a computer network that ran PROCAL on local teletypes and the basics of FORTRAN made it straightforward. A year later I had to learn BASIC for a project (using a Varian V/70, if my memory serves me well) and, again, I just treated that as a tweak to FORTRAN. Even the bits of VB I used in my last job before retiring were little more than a dialect of FORTRAN to me.
In one job, I had a project that ran on COBOL. I was just the lead user in the company, the IT department did all the hard work - but I helped out wading through code printouts to find an elusive bug during commissioning. For this topic, the company mainframe (in the factory in Scotland) was backed up to computers at the HQ in the USA (via leased lines, and satellite, as this was in the days before the internet had escaped DARPA).
Around 2000, I switched college majors to engineering. They grudgingly approved an exception to the curriculum so I wouldn't have to take FORTRAN, on the basis that I had (before changing majors) taken several programming classes taught in C++ and Java. (And written code in C, Perl, Pascal, Basic, DOS/Windows batch scripts, and Linux shell scripts, but those weren't in my transcript.)
I've never once had an employer express any interest whatsoever in FORTRAN.
I used to have to enter the first 16 opcodes by hand to make the machine eat the punched tape with program on it
Been there, done that, in the early 70s. Honeywell DDP-516. We didn't need to do it every time but that small amount of bootloader sometimes got corrupted - no memory protection there!
I used to spend whole weekends with a screw driver and an oscilloscope to get the heads in line
Wow, that takes me back. The first bit of kit I built on a computer hardware course many decades OK was called a disk exerciser. One bread board, a few TTL chips and some caps and resistors, squeezed into a plastic kit box with a couple of buttons and switches on the panel. Plug a PSU and oscilloscope into the exerciser, then plug the exerciser into a 5 1/4" floppy drive (which were over £500 a pop in early 80's money so well worth re-calibrating or repairing if they were getting unreliable.) Use the panel switches to read or write high-density or low-density frequencies to each track on a blank disk and move the heads in and out to change tracks, or use a reference disk to check the position of the read / write heads on the actuator and adjust if necessary.
Today I log in to the Azure console and check my storage accounts. Computing's not really the same game at all today if you ask me. And yes my beard is significantly greyer than it was back then...
I've posted this before. I went to a client site because their backup tape drive had failed. The "fault", which no one had noticed 'till then, was that all the backup tapes had "expired". The person responsible for changing the tapes would pull the old one, pre-ejected, out in the morning, then just before leaving would put the next overnight tape in. No one ever noticed that it would spend a minute or two examining the tape, making whirring noises for a while as it read the tape headers and then immediately ejected it. So I called their head office, the people who called me out, to tell them. The tape was about 9 months past it's "use by" date, as was probably every backup tape across every one of the local offices all over the UK. I'm not sure if they had not set up the the option for the backup system to email success/failure or if the emails were going to to someone no longer with the company. Either way, this large UK insurance company had no local office backups at all, across their entire business.
I'm not sure exactly what was supposed to be backed up, but I'd imagine a lot of their stuff was on a mainframe at HQ since lots of people, while running Windows (3.11 I think), most of them were in terminal sessions. But there was definitely the sound of a bum clenching as I reported the situation to HQ IT.
I remember those discs - top half removable, bottom half fixed. You had to screw the top half down onto the bottom half, making sure the locating pin on one half matched the hole on the other half, otherwise a nice head crash eventuated.
I think our system was a Singer System Ten at that time.
I recently upgraded to FileZilla Server 1.5. It was used to download backups via FTPS from a Windows machine using wget from a TrueNAS server. The upgrade procedure broke, because it looks wget compiled with OpenSSL has a bug that leads to a segfault when used with TLSv3 - and when compiled with GnuTLS won't resume the TLS session. FileZilla Server requires the session resumption. Both of them refuse to be set to use TLSv2 only instead of TLSv3, because you know, security - even if it means that to make it work you have to get back to plain text transfers, or get rid of everything and switch to something else...
So right now backups are moved manually - "copy file x to A, file y to B...."
AFAIK, rsync doesn't work over FTP(S). Nor it runs on Windows natively. The machine is a remote one - that's why the FTP(S) server. Of course there are alternatives (use HTTPS or SSH, or maybe setup a VPN between the two machines) - all of them require non trivial modifications to the current setup, which will be made - but to keep backups flowing right now the procedure became manual... because you cannot tell to applications - hey, support for TLSv. 1.3 is broken, switch to 1.2 - you can only have the latest and greatest security or nothing at all.
Rsync is NOT FTPS. Rsync encryption is, when used, classic openssl. You can set up your whole certificate stuff by yourself, if you want. Though I personally recommend a VPN, when possible.
It does run on Windows "Natively": Just yesterday I updated my rsync packages. I.e. get the cygwin dlls needed to run rsync. And then, when you have the x64 version of rsync.exe extracted from cygwin and working, you can overwrite the .exe with the latest version from samba.org official site. No need to install cygwin. Unpack, works. Of, if you want to pay, use cwrsync which was free a few years ago. Or one of those many other programs which internally use rsync.
Though I have one hint: Let the rsync server run with an account which cannot set ACLs - in Windows remove the "full access" right, in Linux remove the same (forgot the flag...). Else an rsync client might mess up the access rights on the server when syncing to the server.
Have you ever found yourself lost in a procedural maze of your own making?
Yes.
And the pain still endures.
tl;dr
My temporary but actually years old store in a local drive with admin-only access back-up procedure failed.
It was bound to happen, eventually.
Why?
Because it is not proper practise, that's #$%& why. 8^|
I had let something I would not by any means accept at my IT day job slide and eventually forgot about it.
Till it failed.
So I got myself a 1Tb network drive and used sync to manually make weekly backups of the daily backups generated by timeshift and back in time as well as the contents of a local storage drive with archives.
What could possibly go wrong?
sync? Nah!
Tears are starting to flow again, so I'll stop here.
Thankfully, I have more than 80% (?) on paper, but there's content I cannot even recall that is gone.
Forever.
O.
Guilty on more than one occasion. "I'll remember which is newest...surely".
Aeons ago, I relied on the creation date of files to get them in the correct order. Then I started using POSIX minimally compliant file systems that do not store file creation dates. So I ended up putting creation datestamps in filenames,
e.g. ‹Random-filename›-2022-08-30.dat ; or, if the time of day is important
‹Random-filename›-2022-08-30T09:49.dat
It might not be pretty, but 'it works for me'™.
NN
Bob? Is that you? We used to work together!
New.zip
New_new.zip
Old_new.zip
New-tuesday.zip (inevitably had a last modified stamp corresponding to a Friday)
Alpha.zip
Beta.zip
Delta.zip
I pushed very hard to introduce SVN to our workflow. Most of the staff was very happy to let the rev control software take care of things.
Users - Don't create a backup of all the files on your PC, including the previous years backup that included the previous years backup, repeat for 15 years................
Users have driven me to Icon, which is nice but I was already hitch-hiking down that road anyway.
We had a little stand-alone p.c., with a tiny monitor whose only purpose was to send information to FHA and VA via a dedicated phone line. Every night I had to 'park' the drive using this complicated procedure of shutting it down, hitting a button that disconnected the drive (I think, wasn't in IT at the time, just a lowly administrative assistant who automated FHA and VA reporting on a dare but before 'lightning fast interwebs'). Then I had to start it up again to verify it and write down the number that displayed in a log, which then I verified with the number before. Every day. I myself documented what to do, but that wasn't enough. So I had to come in on Saturday and Sunday morning and do it even though nobody had anything to transport. Well, clever me decided to skip the weekend on the theory that nothing would happen.
Flash forward to 1994 and the Northridge Earthquake. The whole building was a mess and a ceiling tile took out the poor little computer. When I was finally allowed to enter the building, walking up stairs that were still a little crooked and groaned in places, I reached my floor along with two IT guys. We go over and look at the destroyed mess. One quips "well did you park the drive?"
Gawd! *Every* bit of repeated routine processing I do I ensure is written down as an "aircraft cockpit" step list. *Including* the steps that don't involve the computer, such as: Obtain new user's prefered name, note as name/surname pair, ensure this is correct, *EVERYTHING* will be copy'n'pasted from this.
I tear my hair out at the horrifying number of cases where people *type* *in* the same data repeatedly, adding in their own unique errors every time. Get it in the computer *ONCE*, then use that. Do. Not. repeatedly process it through somebody's brain.
When I make payments on a business account, it attempts to verify the sort code and account number with the payee's name given. Somewhat amusingly, given GDPR, Data Protection and all that, it most often gives me the person's full name, which I was usually unaware of before. Some people do have very interesting middle names!
Banks often get to assign whatever sequence of numbers they want (if you're lucky, it's just numbers), but if they want to, there are several methods for defending against transposed digits. The Luhn algorithm is popular and freely available, so it's more an issue of persuading those not using it to start doing so. That article does list a lot of places using it to protect against fumbling or misreading numbers.
Hmmmm, will have to look into Greasemonkey, although I hate JS.
I use Keepass with some convoluted 'autotype' definitions. Best I've come across for me so far, as (a) I'm paranoid and clear cookies/data on browser exit, (b) don't want to put stuff like that in the cloud as my internet connection is a bit ropey, and (c) if you use Keepass portable, you can take it on hols using a thumb drive.
The last trick is beloved of my less-technical friends.
I'm a Keepass user also, for largely the same reasons. Ain't no way I'm putting a master list of all my passwords into the cloud, encrypted or not; eventually somebody will get a copy of it, then it's a waiting game until they crack the password. Local storage **ONLY**. (With backups, of course.)
Eh. My Keepass lives in the cloud, uber convenient, and my master password is in the "billions of years" class to crack. Any one of the devices Keepass is synced to could fall into the wrong hands anyway, and I assume the cloud provider with a team of top notch security people are better at it than me.
There should be a place reserved in hell for those people who design system, where you have to enter a name or other details more than once.
My sister was a nurse, and said that on some systems, you enter the patients name, then click on a link (haematology) for the results of the blood test, and have to enter the patients name again. Then back and click on another link ( xray) and enter the patients name etc all over again. This was an improvement on the previous versions when she had to logon to the main system, click on haematology, enter her login details (every time), then the patients details etc.
The "improved user interface" was just lipstick on the pig.
An understandable precaution, but surely it could present the name prefilled and ask for confirmation that's the patient you want so you don't have to type the whole name again?
Not really a problem with a short name like John Smith, but if you have a patient with an eastern European or Asian name that's lengthy or difficult to spell there's a risk of mistake where you might type it wrong the second time but hit another patient's name by mistake!
So I don't think forcing people to retype is a guarantee you're still working with the same patient's data - at least not at a large hospital system that may have tens or even hundreds of thousands of patient names in its database making a "typo mismatch" all the more likely.
A couple of students were identical twins. Still living at home, so same address. First names differed by one character (like Harry and Barry but different names and the character that changed was inside the name not the beginning). Took me days to convince the system and its operators that one of them was not a typo of the other.
"An understandable precaution, but surely it could present the name prefilled and ask for confirmation that's the patient you want so you don't have to type the whole name again?"
What? Like "There has just been an error. Here's the code to report to the helpdesk. Click OK to make it go away before you bother to read it and report it"
If a user has to click something to make a box go away, they will very quickly get into the habit of just clicking the box and NEVER checking what the box is there for or why. Windows users especially have been trained for years to click OK on dialogue boxes to make them go away. Especially what UAC first came along and it was an annoyingly constant "feature" for many.
If a user has to click something to make a box go away, they will very quickly get into the habit of just clicking the box and NEVER checking what the box is there for or why
Perhaps so, but requiring them to type in the full name on every screen is a worse solution than risking they get too used to clicking OK.
Maybe give them a dialog that says "using patient name XXX", to proceed type '23' (it will give two random digits so it is different every time) or choose 'cancel' to re-enter patient name". That at least that will require affirmative action on their part, but not require them to enter the full patient name over and over again.
Yes, that would be better than just a "click OK" box. But I suspect the problem would still remain of people looking at the numbers. The risk of putting in or getting out information on the wrong patient may or may not be high, I'm not in that business, but the consequences of getting it wrong could be catastrophic.
It's tough one to deal with and I'd not like to be the one making the decision on what is the best way to deal with it.
"An understandable precaution, but surely it could present the name prefilled and ask for confirmation that's the patient you want so you don't have to type the whole name again?"
The risk is forming a habit that's hard to break. The user sees that box a few hundred times, and the name's always right. They get very fast at clicking through it so they can get to the important stuff. Then, on time 472, the name's not right, but they click through anyway and the data's misaligned. This gets even worse if the thing's running in a batch mode where it shows multiple patients in a row, because then they could have an off by one error that cascades through everyone else in the list.
This can still be improved by using a shorter identifier, E.G. first three letters of the name followed by the last three letters, although if you implement that, make sure you can handle a name like "Al Hu" somehow without confusing everyone.
Not really a problem with a short name like John Smith, but if you have a patient with an eastern European or Asian name that's lengthy or difficult to spell there's a risk of mistake where you might type it wrong the second time but hit another patient's name by mistake!
Or Chinese names (or other non-alphabetic writing systems) where there might not be a consistent transliteration. My late wife's name could (quite correctly) be transliterated in several different ways. She always used the same one, but the symbol she transliterated as "Yau" could easily be transliterated as "Chiu"
I remember having to do backups the same way back in the mid 80's. We were using a Control Data Hawk hard drives with the same 5 fixed / 5 removable configuration.
I always did the backups when no one was around so there was no chance of distraction and forgetting where I was in the backup process.
It was always interesting going through security when I would have to fly somewhere with one of those 5meg (14") cartridges as carry on.
Ahhh.... the good old days.
Several years ago (something over 10) I was conducting a supplier assessment (aka audit) and my victim (sorry, auditee) had had a local computer crash the previous day. Yes, perfect timing for a client audit - aren't they always? It wasn't a big company and their system was little more than a LAN with half a dozen PCs and a file server/gateway. My question of why hadn't they restored from their backup was met with a sad "no backup"! A definite oops moment for them, one that didn't look like helping their chance of getting a lucrative contract*. Their recovery plan was to trawl through email archives that, fortunately, were on their mail server in Norway, and almost all business involved both UK and Norwegian sites. It took them a week or three to get a usable network back, whilst their operations staff struggled by with what paper copies they had to hand and using up whatever "credit" they had with customers and suppliers (which wasn't insubstantial as they were actually a good team to work with).
*The fact that they managed to recover (and then learn the lesson of regular backups) actually put them in a good position for further work.
A crucial point about backups is checking that you can successfully restore from them, on different hardware.
A couple of stories:
1) Backups performed to 9-track tape. Tapes can successfully be read back in. Job done (so the operations team though). We then later do a Business Continuity recovery test at the recovery site and...tapes are unreadable. Turns out a head on one of the tape drives at the original site was misaligned, and while it could quite happily read tapes written by itself, no other properly aligned tape drive (like the ones at the recovery site) could. Lesson learned. The operators had become very good at reading particular tapes on particular drives and regarded having to move tapes around to do so as normal practice - their target had been to get the tape read, not to work out why it didn't work on particular drives.
2) Backups performed. Business Continuity test done at recovery site performed. Slight oops as the model of IBM mainframe at the recovery site was different, so while the data on the tapes could be read, the operating environment could not be IPLed (Initial Program Loaded). I'm not an IBM chappie, but the IBM team ran a combination of VM, MVS and CICs, and for some reason (I know not why) the Operating System backup image could not be used on the recovery site hardware, which meant that for the purposes of the recovery exercise, they had to rebuild the environment from scratch, which apparently took 'some time'.
NN
... a head on one of the tape drives ...
Reminds me of yet another one from long ago, though not as bad.
3.50" HD diskettes written with a new perfectly aligned drive would be read by that same drive without issues, as long as that drive remained properly aligned which, as I once found out, was not always the case.
The problem got worse when the manufacturing quality/QC of the ubiquitous FDD drives started to lose favour in the IT world.
O.
I worked as an operator in the late 70s and it's not for nothing they called us tape jockeys. Imagine a bank with all its customer records on magnetic tapes. Feed in a tape with today's transactions and update the records on to another set of tapes. Make two copies of each tape and ship them off site. We spent most of the night copying tapes.
Worked for a large retail chain which had tape backup for its system.
It was the task of every closing shift to copy the day's business to tape, remove the tape and store it, and replace it with a new tape.
That was fine, until it was noticed that the last backup tape had no data on it! whoops
Lot's of busy keystrokes the following day!
Many moons ago, I worked for a large car auction company. We were, back then, using some large boxes (mainly fresh air and a RAID 10 array) running SCO Unix (remember that?).......
One of our auction sites, in the midlands, religiously backed-up to tape every night (DDS2 back then) and rotated the tapes as they should, so a good, if not great backup regime (one would think). However, rather than do what was instructed by us IT bods, and take the tapes out of the server room to be locked in the safe in the site's security office, they wisely (perhaps not) decided to just store the tapes on an available free surface in the server room, which happened to be on top of a very large, very old UPS. When the inevitable fan-clogs-up and server overheating issue finally occurred, taking multiple drives out on the RAID array, restore was the only option, with nicely degaussed tapes having been left on top of the UPS. Back then, all transactions through the auction were still captured on paper (remember that too?) and though it was a real nightmare, and took a team of people re-keying data for days, at least not all was lost.
The old adage of "a backup is only as good as the last restore" or perhaps more pertinently "don't store your F*****G tapes on top of a big electromagnet" was never so true.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
