Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Tech Magazine Loses June Issue, No Backup

Posted by CmdrTaco on Wed May 02, 2007 07:43 AM
from the happens-to-everyone dept.
Gareth writes "Business 2.0, a magazine published by Time, has been warning their readers against the hazards of not taking backups of computer files. So much so that in an article published by them in 2003, they 'likened backups to flossing — everyone knows it's important, but few devote enough thought or energy to it.' Last week, Business 2.0 got caught forgetting to floss as the magazine's editorial system crashed, wiping out all the work that had been done for its June issue. The backup server failed to back up."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • The first words from management were "You're kidding me, right?"

    Then the swearing started again.

    • by Anonymous Coward on Wednesday May 02 2007, @08:13AM (#18955463)
      Actually that is what you get for having Geek Squad as your outsourced IT staff.

      honestly, they CANT have competent IT. The FIRST thing you do in the morning is check the backups.

      I have a HP sdat jukebox here and I STILL check the backup logs to make sure the backup and verify succeeded last night. if they dont I mirror the important files right away and then run a manual backup to not lose the last 24 hours of backup.

      I hope that Business 2.0 learned that paying top $$$ for competent IT is a good idea and they should run a article about it.
      • by IdleTime (561841) on Wednesday May 02 2007, @08:44AM (#18955925) Journal
        I am not surprised.

        There is not a week going by without me getting an issue from one of out regular analysts with question about how the customer can salvage their data because they don't have a backup. My standard answer is that we may be able to save some data, but it's going to cost a lot of $$$. And I also say: "When you don't have a backup, you have either deemed that you can easily recreate the data or that they are not important for the company"

        And these are not mom&pop companies but big multi million/billion dollar companies.
      • by Auntie Virus (772950) on Wednesday May 02 2007, @08:48AM (#18955991)
        I have a HP sdat jukebox here and I STILL check the backup logs
        HP DAT? You'd better do more than check the logs. A test restore (if your users don't already test for you by deleting files) at least a few times a week might save your butt one day. Actually DAT or not, test restores are a must. Logs lie.
          • You can be using great software, have the logs tell you everything completed successfully, and still have useless backups. I was a consultant at a company. We were brought in to run the IT department that was fired (new management, cleaned house for some good reasons, some bad reasons). They skimped on the number of people they brought in. We were just keeping up with the help desk functions, and mentioned in the daily report that backups hadn't been checked, UPSs were bad, and all sorts of things that
      • Re: (Score:3, Insightful)

        I work for a backup company that makes D2D backup appliances supporting more than 20 operating systems.

        First, no one really understands best practices for backup, and a lot of systems that are backed up "successfully" can't be restored anyway (in fact, most commonly this is Microsoft Exchange, the most important system in most companies!). Second, Tape sucks! You MUST have Disk-to-disk backups to have any true recoverability in today's world. Third, check you logs EVERY day, there's no excuse! Fixing a
    • by shrubya (570356) on Wednesday May 02 2007, @10:23AM (#18957351) Homepage Journal
      Jerry: I don't understand. Do you have my data?
      IT: We have your backup, we just can't restore it.
      Jerry: But the backup keeps the data here, that's why you have the backup!
      IT: I think I know why we have backups.
      Jerry: I don't think you do. You see, you know how to MAKE the backup, you just don't know how to RESTORE the backup. And that's really the most important part of the backup: the restoring. Anybody can just make them.
  • by Anonymous Coward on Wednesday May 02 2007, @07:47AM (#18955129)
    who needs a magazine?
  • by ScentCone (795499) on Wednesday May 02 2007, @07:47AM (#18955137)
    Maybe not so bad as losing your entire monthly product, per se... but it does happen. I'll bet their accounting, HR, and other back office systems are probably fine. This stuff is always ugliest at the department server level in smaller operations. I'll bet they get some good Mea Culpa 2.0 editorials out of it, though.
      • by LurkerXXX (667952) on Wednesday May 02 2007, @10:23AM (#18957349)
        And if the data is that important then a suitable RAIDed disk array will sort things out.

        The topic here is backups, not RAID.

        Say it again with me everyone "RAID IS NOT A BACKUP"

        RAID increases-uptime by decreasing/eliminating the downtimes needed to do restores when an individual drive bites it. It is *NOT* a backup.

        RAID does not save you if someone accidentally deletes a needed file.
        RAID does not save you if your machine gets nailed by a virus/upatched-exploit.
        RAID does not save you if the drive power supply fries taking out attached hardware.
        RAID does not save you if a bugler steals your machine.
        RAID IS NOT A BACKUP.
  • by erroneous (158367) on Wednesday May 02 2007, @07:47AM (#18955139) Homepage
    Some stories should just come with Nelson Muntz [wikipedia.org] sound files embedded.

    Ha-ha!
  • err... (Score:3, Insightful)

    by cosmocain (1060326) on Wednesday May 02 2007, @07:48AM (#18955141)
    HAHA!

    *coughs

    TFA:

    Business 2.0 never had to rely on their backup software until that day, which is why they probably did not realize that it was either obsolete or dysfunctional.


    sorry, their MAIN problem is not in any way a dysfunctional backup system. ever heard of verifying backuped data?
    • Re:err... (Score:5, Informative)

      by Lumpy (12016) on Wednesday May 02 2007, @08:16AM (#18955531) Homepage
      hell with that. ever heard of competent IT staff? why has their CTO not been fired yet?

      honestly though, talking management into backup solutions is like pulling teeth, then they blame you for not having it in place when the failure does happen.

      Last place I worked at we were using 4 year old DLT tapes because management was too stupid and cheap to buy new ones.

      "we will buy new when those fail" is what we were told.
    • ever heard of verifying backuped data?


      Errr...uhh....umm...'verifying'? Uh, I'll be right back!

    • Re:err... (Score:5, Funny)

      by radtea (464814) on Wednesday May 02 2007, @08:36AM (#18955791)
      sorry, their MAIN problem is not in any way a dysfunctional backup system. ever heard of verifying backuped data?

      I'm sure they've heard of it, in a conversation that went something like this:

      IT Guy: We need a system for verifying our backups.

      Suit: How come? Don't the backups work?

      IT Guy: We need to be sure that if there is a failure, the backups will be ok.

      Suit: But they're just copies, aren't they? I copy files all the time and it never goes wrong.

      IT Guy: This is a little more complicated than that.

      Suit: How hard can it be?

      IT Guy: Well, I was thinking we might need to hire a part-timer just to take care of backups and verification.

      Suit: But we've never had a failure! Sounds like empire building to me. I know that's what I'd be doing in your position. Nice try. We'll keep the backup system the way it is, thanks.

      IT Guy: But..!

      Suit: Moving on to the next item on the agenda... ok, Executive Bonuses!
  • I imagine that they still can resemble a lot of it from other files - they should still have all the layout pieces for one, and all the authors ought to have at least rough drafts of their stories on their personal computers. The deadline's screwed, but they can probably get it out a few weeks late (or in July, depending on how often they normally publish).
      • by Red Flayer (890720) on Wednesday May 02 2007, @08:13AM (#18955479) Journal

        Yeah, great, that's the content - now how about the advertising? That's where they make their money.
        Editorial department server content was lost. Advertising content is normally handled by the production department.

        I think we can all relax and rest assured that the June issue of Business 2.0 will have all its intended advertising.
  • HAHAHA (Score:2, Funny)

    by Anonymous Coward
    HAHAHA
  • No June issue?

    That's OK, nobody reads Business 2.0 anyway.
    • Re:Rag (Score:5, Insightful)

      by UbuntuDupe (970646) * on Wednesday May 02 2007, @09:06AM (#18956227) Journal
      nobody reads Business 2.0 anyway.

      I wish. I wish people didn't read Time, either (the publisher), but they do. Time's writing style is the dumbed down, try-to-be-hip crap I wouldn't have gotten away with in sixth grade. Seriously. Like I said before [slashdot.org], to understand why its writing is like fingernails on a blackboard for me, consider how the same information would be conveyed by two sources:

      8-year-old: "6 divided by 3 is 2."

      Time magazine: "Okay, imagine you've got a half-dozen widgets, churned out of the ol' Widget Factory on Fifth and Main. Now, say you've gotta divvy 'em up into little chunklets -- a doable three, let's say -- and each chunklet has the same number that math professor Gregory Beckens at Overinflated Ego University calls a 'quotient'. The so-called 'quotient' in this case? Dos."

      Based on how that post got modded, I'm not alone in this.
  • It seems unlikely to have crashed in such a way that a data recovery specialist would be unableto get most of the data back.

    But whatever the case - there is a useful lesson here. Make sure your backups are backing something up.
    • Hum!!! Unless you are there looking at the data being backed up there is no way unless you get notification from your system that it has completed.

      usually that is the case but it has happened when one of my backup failed one night and someone needed a file restores from the previous day, if that company never checked it's backup or never configure some kind of noticaition upon failiure or success then they are very lame
  • by Rob T Firefly (844560) on Wednesday May 02 2007, @08:03AM (#18955323) Homepage Journal
    This reminds me of the recent uproar over a car crash involving the New Jersey governor. He was critically injured because he wasn't wearing his seatbelt, and people freaked, asking what sort of role model he could possibly be. I argued that he was an awesome role model, because sometimes people need to see a mistake end badly for someone else before they'll do what's necessary to protect themselves from making the same mistake. Seeing a high-profile magazine get hit like this can do the same for backup slackers the world over.

    I don't know about you people, but after reading this (and giving it the "haha" tag) I'm going home and catching up on a couple of backups I've been slacking off on for a while.
  • by Orange Crush (934731) * on Wednesday May 02 2007, @08:08AM (#18955397)

    There aren't a lot of ways for a machine to "crash" that loses all its data. Even a lightning-fried hard drive can have its platters removed by a data recovery lab and many files can be pulled off. A mechanical failure doesn't grind the platters into sand. As a network server it really should have a RAID too. So how exactly can "the server crash" so spectacularly that the RAID, backups, and widely available data recovery services all fail? Did the building blow up?

    • Re: (Score:3, Informative)

      The data "should" be recoverable, and the network server "should" have a RAID. I bet you anything that someone in IT asked for money for the RAID and it was denied, since lots of people with budget control think RAID is bug spray.

      Backups and fault-tolerant hardware cost money. You can talk about potential losses and risks until you're blue in the face, until it *actually* costs the company money, nobody will listen. What's going to happen here more than likely is the person who asked for the RAID will ge
      • by Rob T Firefly (844560) on Wednesday May 02 2007, @08:29AM (#18955715) Homepage Journal
        IANA publisher, but I would also imagine that in such a deadline-intensive business, data from a fried disk is about as good as lost. Sure, they can send their drives off to data recovery labs who could slowly recover an uncertain portion of the data for a pantload of money, but by the time that's done it'll be time for the next issue anyway. I'd guess it would be a lot quicker and cheaper to write off the disks and salvage what they can from everyone's local copies of the data.
      • Re: (Score:3, Insightful)

        `` I bet you anything that someone in IT asked for money for the RAID''

        Perhaps, although my experience is that IT people are incredibly bad at framing business cases in terms more compelling than my daughter's request for a mobile phone for her birthday: a few vague reasons, followed by a sulk when asked for specifics.

        I keep 20TB on RAID5, and replicate it daily to a RAID5 array that has no components or software above the spindle level in common (Solaris/EMC and Pillar Data). The data we really care

      • If they deleted the files in error, then the RAID would faithfully mirror that deletion across all physical disks...
    • by Paulrothrock (685079) on Wednesday May 02 2007, @08:31AM (#18955735) Homepage Journal

      A mechanical failure doesn't grind the platters into sand.

      Doesn't it? [ufl.edu]

    • I once lived with a roommate who got home early one day:

      Me: You're home early; not enough work to do?
      Roommate: No, the server burned out
      Me: Oh, that's no big deal; you just wait for them to get replacement parts and then you get back to it
      Roommate: No, seriously, it's burned out. The air conditioning unit failed, the entire server room heated up to the point of spontaneous combustion and the entire server room caught fire

      Lesson learned, keep your backups somewhere far, far away from the servers.
  • Tens of IT managers are getting Hundreds of IT minions to check Thousands of backup tapes and befor a senior manager walks in.
  • Wrong problem (Score:5, Insightful)

    by mseeger (40923) on Wednesday May 02 2007, @08:15AM (#18955507) Homepage
    Hi,

    the problem was, as always, not the backup. I've rarely seen problems resulting from the backup process. The troublesome process is the restore. Or as a friend put it once:

    Nobody wants backups, what everybody wants is a restore.

    In my twenty years of IT i've seen several companies making backups like a well oiled machine. The backup process was well documented and everyone was trained to a degree, they could do it with their eyes closed. But everything fell apart in the critical moment, because all they had planned was making the backup. Nobody ever imagined or tried a restore on the grand scale. So they ended up with a big stack of tapes with unuseable data.

    Backup is the mean, not the goal.

    Regards, Martin

    • Re:Wrong problem (Score:5, Interesting)

      by RetroGeek (206522) on Wednesday May 02 2007, @08:30AM (#18955725) Homepage

      The troublesome process is the restore.

      I heard a story about a LAN admin who was doing backups every night. The tapes would go into a safe, then would go offsite, then be used again.

      Everything worked well(?) until they needed to do a restore. The tape in the safe was corrupt. The tape at the offsite storage was corrupt. No tape was good.

      It seems that the LAN admin made tea every morning. The electric kettle sat on top of the steel safe.

      So the backup tape was placed into the safe, then the kettle was started, magnetizing the safe, and erasing the tape.

      Not ONCE did anyone try to do a test restore to prove the system.
      • Re:Wrong problem (Score:4, Informative)

        by ByteSlicer (735276) on Wednesday May 02 2007, @09:02AM (#18956179)
        I highly doubt that the kettle could demagnetize the tape in the safe, due to the Farraday shielding [wikipedia.org]. Even if the kettle was on top of the tape (outside the safe), the generated magnetic field would not be strong enough (although the heat would probably melt the tape).

        Nice story, though. Reminds me of the sysadmin in my first company who automatically back-upped our server every day. Only problem was: the proces put a copy of the backup on a drive that was being back-upped. You can imagine what happened after a few weeks (it failed, disk full). He only noticed a few months later when we asked him to restore some files.

      • Re:Wrong problem (Score:4, Interesting)

        by mseeger (40923) on Wednesday May 02 2007, @08:43AM (#18955915) Homepage
        > Would mirrored drives be a more effective solution?

        Yes and No:

        • Mirrored drives are a good protection against drive failures and (usually) offer an easy restore process. If you mirror a drive and put the copy away (e.g. into a safe) this is a real and widely used backup method. As always you should at least try once to boot the system while removing the primary disk. Somtimes RAID controllers have some irks too.
        • This method usually depends on the availability of a certain hardware, if you cannot get a new mainboard or raid controller of the same type, the mirrored disk contains data you may have trouble getting at. You may ignore this issue, if you have the same hardware at a safe location again.
        Regards, Martin
  • by hargettp (74445) * on Wednesday May 02 2007, @08:50AM (#18956027)
    Huh, I guess I wasn't paying attention to when Slashdot turned into Digg, even though I read both. Here's a link [iht.com] to the original article, rather than what might be a splog. Especially since the article text was copied verbatim.
  • by TomTraynor (82129) on Wednesday May 02 2007, @09:23AM (#18956435) Homepage
    I know that where I work we run a Disaster Recovery (DR) exercise every time we do either a hardware or software upgrade to prove that everything still works. If nothing has changed one is done every second year. We actually pull our off-site production tapes and restore to a new machine that is not in the same city where the current production machine resides. It may be over-kill for them, but, a test of that for them (or any other business) would be a fruitful exercise in that they prove that the backups are good and they can restore from a given point and carry on with a minimal loss of work.

    For one of our server apps we actually have two laptops configured with all of the required software and we do restore production data from backups on a regular basis as we use that for our system testing on projects. This happens several times a year so we know that the backup and restore procedures truly work. It is also very cool walking in to the client site, plug in the laptop and show them that in an emergency they have a working machine very quickly. Not as fast as a server, but, it gets them a working machine until the replacement server arrives.
  • by Stu101 (1031686) on Wednesday May 02 2007, @10:11AM (#18957169)
    This is my story and I bullshit you not! I work for a manufacturing company, the second largest in its field in the world. Great. However the boss really does not like spending money. We eventually got a backup system using offsite backups (with a special client) and it seems to work ok. However, when it got to 100 GBs I was told to start pruning stuff. So I did. Long and short of it, even with the most important files backed up, we still have most things not backed up. Basically I have almost half a TB of data that I am not allowed to back up because its expensive. I can only backup 5 days worth of data as they are unwilling to pay anymore money for it. The fun will come when someone wants a restore from last year. This people, is the reality sometimes. Me, well, I really dont care anymore. Im sick of having servers, important, mission critical machines sitting on single IDE disks. We sell online, great, problem is our firewall is non redundant single IDE disk. If it goes (like it has in the past) we were down for days, loosing emails, web traffic, web orders, remote ordering systems, EDI data, remote sessions, ftp, everything. DR? the solution proposed by upper management is, oh we will buy some dells and restore. Yeah thats a good idea. After waiting a week for them to arrive, what exactly are you going to restore ? This is more typical than you think, unfortunatly. Im just the guy that has to make do with what i can. No doubt when it fucks up I will be blamed.
  • Backup stories (Score:3, Informative)

    by dpbsmith (263124) on Wednesday May 02 2007, @12:55PM (#18959759) Homepage
    That's the usual fly in the ointment with backups. Backups are difficult and expensive. Management always thinks they can make them easy and cheap by buying some automated solution. But the main cost of the backup is regularly testing the backups... which can only be done properly by doing a full restore... which requires available disk space equal to the size of the backup, and hours of operator time.

    Story #1. Fortune 500 company. Lost some source. Big brouhaha. Edict went out: all files are to be backed up to diskettes and the diskettes sent to offsite storage which the management had contracted for with an outside firm. It took a lot of extra time, but people did it. After about two years, an important server with source code for a major product crashed. Developers tried to get the source back from offsite storage. It turns out that nobody at any point had taken any responsibility for cataloging, identifying, or indexing the diskettes. The diskettes might as well have not been labelled: the developers couldn't identify what diskettes were needed, and the offsite storage firm couldn't have retrieved them if they had.

    Story #2. Medium-size scientific research organization with a Digital 11/70 running RSTS. Enlightened manager pays operator overtime pay to stay late three nights a week and do backups. Backups are performed with the "verify" option enabled. Tapes are placed in a fire-resistant tape vault every night. But no actual restores are performed. Database (Oracle, in the days when Oracle Corporation's name was still Relational Systems, Inc). is corrupted. A restore is attempted. It transpires that this version of Oracle uses the maximum record length for its files, which happens to be 65,536 bytes, and the Digital-supplied backup-restore utility... you guessed it... has a bug with records of that length. Yep. Writes 0 bytes, verifies 0 bytes.

    Story #3. I worked at a place that recommended that individual developers perform individual backups using a cartridge tape system and some standard PC software. I set it up. There were two "verify" options. One used the cartridge system's read-after-write feature to read every block as it was written. The second performed the entire backup, then verified the entire backup in a second pass. Took twice as long, of course. I opted for the second method. The problem was: more than half the time, the verify would report one or two errors. And for some reason, probably efficiency of use of the tape, it didn't write file by file, it munged them into blocks. And it didn't even report the names of the files affected. Just "2 errors were encountered" or something like that. So, when that happened, I didn't see that a rational person had any alterative except to perform the whole backup again. And more than half the time, it would report a couple of errors the second time, and...

    When I asked colleagues about this, it turned out that I was the only one ever to have picked the second verify option. Everyone else had picked the read-after-write-verify option, "because it was faster."

    And told me not to fuss because "if it was only a couple of errors, the chances they were on files you needed to recover was too small to worry about."
    • smarmy: adjective ( smarmier , smarmiest ) informal - ingratiating and wheedling in a way that is perceived as insincere or excessive : a smarmy, unctuous reply.