Advertorial?
letters
Recovering data after a user had somehow managed to microwave a hard disk or dropped a PC from a second floor window were among the more unusual data recovery problems successfully tackled by Disklabs during 2010. Other bizarre cases included helping a client who had managed to drive over his computer. Disklabs has put …
Disklabs has put together a list of its oddest data receiver(sic)* jobs of the last 12 months...
...Honestly? Sure they didn't put this list together down the pub the other night? It's a well known fact that a lot of top ten lists published by magazines and websites are made in this fashion. I'm sure the same holds true for PR departments too!
Paris, cos she features in all ten of my list of oddest data recovery jobs in the last 12 months.
*I've always wanted to say "sic" whatever the frigg it means, have I done it right?
Unable to determine the level of sarcasm in the previous post, I'll post a brief about the use of [sic]:
A bit of wording enclosed in square brackets [such as these] is used in journalism to denote editor's comments [Thanks for the ack. -Ed].
Sometimes, in particularly sarcastic writings as found here on The Reg, the author will use it as a stab at the sudo-journo stylings of would-be "proper" rags, pointing out terrible ("unprofessional") spelling or grammar. Therefore, if the article had sum impropur spelting [see? a "sic" would be due here], then you can ding the author for it, within a direct quote.
Sometimes, in particularly sarcastic writings as found here on The Reg, the author will use it as a stab at the sudo-journo stylings of would-be "proper" rags, pointing out terrible ("unprofessional") spelling or grammar.
So, journalists run their text editors as root??? Methinks you fell victim to Muphry's Law with regards to "pseudo"
...not merely another form of Internet snideness. It's quite handy in, for example, litcrit, if you're quoting an obscure passage which contains errors; some of your readers are likely concerned with the niceties of the source text, and "sic" tells them they don't need to go back and check the original.
Some style books even recommend it for quotations that are correct but may appear wrong, such as the double "you" in a sentence like "I'll tell you you are wrong". (Some authors would put punctuation between the indirect-object "you" and the direct-object clause "you are wrong" in a formulation like that, or avoid it entirely; but this sort of thing is not uncommon.)
I thought sic was an acronym for 'spelling is correct' (in the sense that it's true to the original snafu), although that had always sounded like a duff explanation to me, especially as usage isn't limited to mis-spellings. Latin for 'thus' will do nicely.
Now all I need to do is find the bastard who misled me all those years ago.
It's short for "sic in originam" - "thus (it is) in the original", meaning "I've not copied it wrong, that's what the original author wrote" (back before parchments had a cut-n-paste option). Any explanations like 'spelling is correct' are just backronyms.
Yes and no.
Seeing as how that was probably intended to read "data recovery jobs", then you are probably correct in performing the print equivalent of saying "this is how it read when they handed me the copy, not my fault", but you missed the rest of that sentence "...all of which concluded with the recover of data " in which "recover" was almost cetainly intended to be "recovery". That makes it a spelling mistake on the correct word, rather than the use of an incorrect word, which you example seems to be.
Wow! That brings back memories...
My cousin's kids were visiting my dad's place one day, and after it got dark they quit playing outside and came indoors.
Being sequestered in the den to keep them from being underfoot, they decided to stuff rubber bands into the 5.25" floppy drives in my dad's KayPro II.
He turned it on the next morning, and instead of hearing the pleasant "whirr" of diskette drives waiting for media, he heard a "twang-twang-twang" as the rubber bands kept fighting the read/write heads as they tried to seek to track zero...
.... and have either a system image (several?) or a fully cloned drive in a safe or bank box or both. I mean wow, given the low cost of hard drives, how much is your data worth to you? Sadly though, many people think "backup" is some sort of Michael Jackson dance move. Well, not sadly really ... not to me since I'm just a crusty old fart with paranoid tendencies who believe people generally get what they deserve and work so hard for.
If you removed the platter in the first place, just take an awl to it then give it a good hammering. The data may technically be there, but with the drive warped, dented, and scratched beyond recognition, it's likely the data isn't usable/retrievable anymore. Especially since it won't be able to spin at any decent rpm and allow read heads to pass over safely....
While denting or warping (or, apparently favourite for USA, umm, "deletion consultants" a bullet from a high-powered weapon) causes localised damage and makes spinning the platters difficult, I'd have thought that applying some wire wool to each surface of the spinning platters would do a far more comprehensive job of scrambling the data.
Reminds me of my early years with AT&T.
I remember watching one of the data center operators physically removing the platters from a decommissioned drive and then removing the magnetic media from disk platters...using a belt sander.
Yes, the data was rendered irretreivable, but the ensuing dust got everywhere.
All you need to do is obliterate the magnetic coating on the platter. Nothing works better for doing that than sand paper or emery cloth. Got to get at both sides of all disks, but once you do it's simple. But then so is using a planer, an end grinder, a bead or grit blaster. H3ll, I knew one fellow who dipped his in acid and another who seal welded the entire surfaces. No big deal. Lots of industrial processes that will work.
Yesterday,
All those backups seemed a waste of pay.
Now my database has gone away.
Oh I believe in yesterday.
Suddenly,
There's not half the files there used to be, And there's a milestone
hanging over me The system crashed so suddenly.
I pushed something wrong
What it was I could not say.
Now all my data's gone
and I long for yesterday-ay-ay-ay.
Yesterday,
The need for back-ups seemed so far away.
I knew my data was all here to stay,
Now I believe in yesterday.
(Sorry, I don't know who wrote this version but it's brilliant!)
I will usually remind folks that if they don't do backups, they may very well end up singing the blues with Barbra. Most everyone remembers the song and it is good for a chuckle when one of the IT folks is doing something with a boxen and I ask if they have done a backup. The misty water-colored memories as sung by her is particularly heart rending, as is not having a backup of hours of work when "the worst happens"TM. I will sometimes hum this tune when saving a router config to startup after making changes, or backing up my own boxen.
worked on a project (in a controlled environment)?
definition Milestone:
A point at which you can measure progress on the way to achieving an objective. Sometimes used interchangeably to show on a plan the production or completion of a Deliverable, or the meeting of an objective.
Milestones are usually phrased using the name of the relevant Deliverable, activity, or objective followed by a passive verb, for example: “submission agreed”, “website launched”, or “Project Team in place” to identify that the milestone has been achieved.)
have an *off-site* backup*).
Rule 3: do not expose to the internet what you wish to remain private.
Rule 4: have a backup*).
Rule 5: have a backup*).
Rule 6: there is noooo rule 6.
*) for definitions of 'backup' that include 'being able to restore same'.
I definately agree with " for definitions of 'backup' that include 'being able to restore same'."
I had to recover some data from a tape written with an arcane version of ArcServe. (guess how long it took me to figure out it was ArcServe, and what version.... and how I came about getting a copy with key...)
Since then, I've been hesistant to entrust my data to proprietary backup systems. It's always fun to have to not only backup the data, but to keep backups of the equipment used to write the data, plus the software with which to read the data back....any of which can fail along the way.
So what can one use? Well, tape is the go-to for large archives of data (multiple terrabytes), just remember that your tape is likely dead after 5 years. Perhaps 10 if kept in "ideal" storage conditions. <3TB of data? Hard disk is a good way to go. SATA may not be around forever, but I'm willing to bet it will outlive a 5-10yr lifespan of a tape. The hard disk itself may last as long or longer than the interface technology (think how long it took to kill onboard floppy controllers....and you can still get USB fdds). With data on a hard disk, it's definately speedy to recover random files. Tape does have the benefit of on-the-fly encryption and any number of protective measures....what what if your drive that you "backed up" (retired with the tapes) fails to work when dusted off? How will you decrypt your data now? At least with hard drives, the encryption can be software-driven. Perhaps TrueCrypt v6? Win/Lin compatible, and shouldn't be hard to dust off or download a copy of Ubuntu9 if it came down to it. Can't rightly say that about Symantec's BackupExec 2010. Since Win98 can't run on some newer hardware, it may be a bit difficult getting an LTO drive into a VM to be able to run your old BackupExec on an aging Win2k3.
Of course, it's all a moot point if one simply considers >7yr-old data "dead" and destroys it. Depending on your area of business, one can't do that. Home users? Likely won't care about anything deleted more than 6 months ago and a couple USB HDDs to cycle through would be plenty (just keep one a family/friend's house! encrypted preferrably).
/end rant/evangelizing.
A previous company where I worked moved their accounting system from mainframe to Sun servers (mid eighties). As part of the process multiple full back-ups were made of all the data on the mainframe. A number of successful restores were also made to test that it was working.
Once the Sun servers came on-stream, the two systems were run in tandem for six months and all transactions compared to make sure that a) all data were correctly migrated to the new system and b) that the new system worked correctly.
All fine and dandy, so the mainframe was decommisioned and disposed of and the backups safely stored in various locations (both on- and off-site).
Six months after the mainframe was decommisioned, a major error was discovered, which meant that data had to be restored from the mainframe back-ups.
It was only then that they discovered that back-ups can only be done to the mainframe, using the original equipment, which meant that the backups (which cost a couple of million) were worthless.
Case two: Exchange 5 (or was it 4?) (with its weird database that had to be restored in full in order to restore a single mailbox) also required that restores be done using similar equipment and equal-spec server hardware. Similar scenario as above when a mailbox needed to be restored (employee had left some months before, criminal activities discovered subsequently) and, despite an extensive DRP and reams of paper printed on the whole process, we found that, due to the fact that the mail servers had been upgraded in the mean time and the old (obsolete, not a one to be found anywhere) servers and back-up devices disposed of, all the Exchange backups were worthless.
I am sure that the inexorable march of progress has caused similar problems and will do so in future, as no-one bothers to transfer information/data from old media to new as the old gets replaced.
I can fill pages on this aspect - just read up on Knowledge Management, Libraries and preservation of information if you want an inkling of the size of the problem.
Anonymous, obviously.
...until it has been successfully restored.
I work as an analyst and constant. I can;t tell you the number of companies i've worked with that had $100,000+ backup systems, and still would routinely fail to recover anything more than a simple file or folder and would often fail to even do that.
Great, you ran a backup. Now:
- did you check the backup log for success?
- Is the size of data backed up consistent with the size of the data? (unmounted disk, typo in path, permission issues, etc)? Some "successes" are simply because it failed to find files it could not back up, but it if could not SEE the files, it doesn't know it failed... Go on, remove "system" read and write permission from directories, when your backup runs as system, and see what happens, lol.
- do you have the install media offsite too? license keys? ADSR passwords?
- do you know what order to recover things in? documented prerequisites, patch versions, etc?
I just helped a company finish a DR plan for 5 servers. It took 10 weeks of planning, testing building parallel systems, the writing of several scripts, and creation of a 120 page manual. They had a 3 day SLA for recovering this system, and The first recovery attempt took 16 days while we found all the bugs in the process. The 3rd test took 4 days, and had over 350 individual steps in the process. By the 9th week, we had that down to 4 hours and less than 80 typed commands or other steps. Week 10 they did it off site in a non-eventful DR test. This server system, which is just 1 component of a major infrastructure of more than 60 servers, but one critical to real-time business, was a system a dozen people supported daily, 4 of which knew inside and out, and yet could not recover on their own from simple file backups until we identified critical system settings, hidden files, mismatched versions, inconsistencies in the builds, and more.
If you have a backup, great. Now actually try to restore it in a secured VLAN, see how far you get. I've done this a hundred times, and short of recovering VMDKs to to VM infrastructures, or baremetal images to identical hardware, no company has ever successfully restored a single system inside of an SLA in a DR test if they had never practiced that recovery before. not ONE.
A folder structure, that's easy. Data inside of a database, that's easy. A fully functional system, top to bottom, exactly as it existed before a crash, on new hardware? you better test that........
"Nobody wants backups. What everybody wants is a restore."
"How do you convince family members to take periodic backups? Repeated, tragic data loss. Same as everyone else."
"The zen nature of backups: if you are wondering if you can just throw the tapes in the garbage, the answer is no, they have data on them. But if you're wondering if you can restore your crashed disk contents from a tape, the answer is no, they have no data on them."
"If you link /dev/tape to /dev/null, your backups go WAY faster - and only about 20% less likely to fail a restore than if you'd used Exabyte."