Not scarred at all - happily nostalgic! We worked out that the machine had an IBM PC compatible mode, which allowed us to boot from floppy disk to play Commander Keen. I recall that lots of other software didn't work correctly (the emultation/compatibility must have been pretty poor) but back in 1994 it kept us entertained on rainy days when we weren't allowed outside to play.
The problem with physical drives is that they can (and do!) fail. The authors point is surely that the backup would need to be checked periodically, and drive failures dealt with.
Does magnetic media like this (especially spinning disk) suffer from bit-rot? What about the possibility of mechanical failure?
I'd never rely on mechanical disks as the one and only backup of any data critical to me - a two tier approach of mechanical for fast retrieval, and cloud/online backup seems to be the safest bet.
The 15-pin I/O connector for ethernet was part of the PCMCIA CardBus standard, which is why dongles could be shared between cards. After PCMCIA picked up speed, a "non-practicing entity" pulled a patent out of their portfolio for a "programmable connector". Because the PCMCIA ethernet card itself plugged into the computer and presented a different connector to the outside world, the NPE was able to sue and/or settle with something like 90% of the companies making PCMCIA ethernet cards & modems.
3COM had a cool connector on some of their cards called XJACK. It was a little tray you slid out of the card. It had a hole that your RJ-45 plug slid into and some pins. It would certainly make for thinner devices today, but the connectors broke pretty easily and you ended up with an ethernet cable sticking out at a weird angle.
Before everybody standardized on RJ-45, there was a standard called AUI which used a 15-pin D connector. Your network card would have an AUI connector and you'd buy an adapter for whatever kind of network you needed to attach to. Apple had their AAUI which was much, much smaller (about the size of 2 mini Display Ports?). But I think licensing kept that from taking off as a standard.
Well, that's actually an alternative. Instead of having a full standard RJ45 port, having a smaller laptop-friendly proprietary socket with a cheap plastic adapter to RJ45. The adapter would just be a piece of plastic and therefore this would avoid all the driver related problems and would not require manufacturers to pick up the phone to agree on a standard with their peers. That would work for me.
I think that was before my time. All it would take is a different plastic socket format. The top 10 laptop manufacturers could agree on a standard in a 10 minutes conference call.
The reporting is very poor also - if the backups don't run, you arent alerted to failure or success, they just dont appear on the emailed reports. Many a server has not been backed up because of this...
Each backup job reports when successfully completed to provide an audit trail for your successful backups. If you are scheduled to run daily backups and you do not see the daily email the backup did not successfully run. We're open to understanding if there is a better behavior for this process. My worry is if we email on both cases people see the message come through and ignore the details where it shows 'failed'.
Thanks for reaching out Bret. The issue I've found is it's much harder to monitor on an email NOT arriving, than one arriving with specific text. With the latter I can be as lazy as setting up a GMail fiter, with the former... I'd have to build my own reporting system that knows you'll email about 8-9am and if the email doesn't arrive, assume it's failed. That's a lot of overhead.
How to best monitor something doesn't happen (e.g. a scheduled, remote job) is something I've yet to solve.
