Re: IOMEGA Rev intermittent failures - SCO

This is a discussion on Re: IOMEGA Rev intermittent failures - SCO ; : --------------------------- clipped --------------------------- : | >1) The BackupEDGE data format includes full-file error : | >checksumming, not just header checksumming like Lone-Tar. This is : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : Bill, : Tom has made some comments about LONE-TAR that are incorrect ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Re: IOMEGA Rev intermittent failures

  1. Re: IOMEGA Rev intermittent failures

    : --------------------------- clipped ---------------------------
    : | >1) The BackupEDGE data format includes full-file error
    : | >checksumming, not just header checksumming like Lone-Tar. This is
    : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    : Bill,
    : Tom has made some comments about LONE-TAR that are incorrect and he's
    : been doing this for some time. I may prepare a more detailed reply to
    : these inaccuracies, but in the mean time, here's where the info is on
    : bit-level failures.

    Hi Jeff. First of all, if I said ANYTHING that isn't correct in my email,
    I want to apologize to you in advance. I spent all of last weekend wondering
    whether I needed to respond, and when I decided I had to, I spent four days
    back-checking my tests before I posted this. I didn't want anything to be
    incorrect. Sometimes you just have to stick up for yourself.

    I was defending my product against the following statement.
    > I think BackupEdge is crap with REV drives (too many bad experiences)....
    > Get LoneTar instead. It's flawless with REV drives.


    The client had one bad experience (which I guess is too many) on a host
    adapter he shouldn't be using. That doesn't make BackupEDGE "crap with
    REV drives" in any general sense. Nor does it make Lone-Tar "flawless
    with REV drives" by any measure I can envision.


    : # ltmenu
    : 7 -> 5 -> 9 -> 1
    : 7 -> 5 -> 9 -> h This HELP Screen is informative.
    : ... or ...
    :
    : # more /log/changed.V
    : ^^^^^------------- $TARDIR set inside ltar.cfg (or ENV for older copies)
    :
    : | >incredibly important when switching from tape drives, which have
    : | >built in error checking, to other media types and network backups
    : | >which do not.
    : |
    : | I have the few remainging sites I do work for running BackupEdge
    : | and Lone-Tar.
    : |
    : | I just double checked the Lone-Tar - version 4.1.5 - and the
    : | default is bit-level-verify - which has parens after it that
    : | says (recommended). The check-sum verify is the second option
    : | on the verify menu. I also had a failed bit-level verify last
    : | night and I checked and it pointed to where the byte vefify failed.
    : | It identifes the failure with a message of "bytes differ at
    : | kilobyte 269213". I'd prefer finer-grained reporting, but at
    : | least it does bit-level.
    :
    : Bill... Not only is bit-level recommended, we will WARN you if
    : fail to do bit-level. Making sure the data is safe, and recoverable
    : to another system is what its all about... weither with edge or lone-tar,
    : or anything else for that matter. Weither Tom appreciates it or not,
    : competitive products are good for the public. It keeps everyone on their
    : toes not only with features, but pricing as well. Tom is one of my
    : best salesman.

    I've never had a problem with competition. I LIKE being compared. Good,
    FULL comparisons really show where our products shine.


    : --------------------------- clipped ---------------------------
    :
    : Best Regards,
    : Jeffrey Hyman, CEO/President
    : .--.
    : ___________________________ .-. | | _____________________________________
    : Lone Star Software Corp. | | | | .-. Home of World Famous LONE-TAR(tm)
    : Cactus International, Inc. | |_| | | | Backup Software for UNIX and LINUX
    : Sales: 800.525.8649 _ |___ |_| | 24x7 Support Available
    : Support: 301.829.1622 _| ~- | ___| RESCUE-RANGER(tm) and AIR-BAG(tm)
    : http://www.LONE-TAR.com \, _} | | Disaster Recovery Software
    : -------------------------- \( -- | | --------------------------------------
    : | |

    Ok, let's go back to that first statement and look at it again.

    : --------------------------- clipped ---------------------------
    : | >1) The BackupEDGE data format includes full-file error
    : | >checksumming, not just header checksumming like Lone-Tar. This is
    : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    That statement has NOTHING to do with bit-level-verify, which is in both
    BackupEDGE and Lone-tar, and is a Good Thing(tm).

    Bit Level Verify is good and necessary at backup time.

    I said that your _ data format _, i.e. the way you store data on the archive,
    has a checkum for the header, and that the data format in BackupEDGE has
    a checksum for the data. I believe that to be correct, and if I am wrong,
    please tell us. I've got the backbone to admit I'm wrong.

    Full file checksum can tell you when there is a difference between the bits
    you stored (which bit-level-verified perfectly at the time) and the bits you
    restored years later.

    Cheers!

    Tom Podnar
    Microlite


    "Good Thing" is a trademark of someone on this group, maybe Jeff Liebermann -

  2. Re: IOMEGA Rev intermittent failures

    D. Thomas Podnar typed (on Thu, Jul 13, 2006 at 04:51:53PM -0400):
    | : --------------------------- clipped ---------------------------
    | : | >1) The BackupEDGE data format includes full-file error
    | : | >checksumming, not just header checksumming like Lone-Tar. This is
    | : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    | : Bill,
    | : Tom has made some comments about LONE-TAR that are incorrect and he's
    | : been doing this for some time. I may prepare a more detailed reply to
    | : these inaccuracies, but in the mean time, here's where the info is on
    | : bit-level failures.
    |
    | Hi Jeff. First of all, if I said ANYTHING that isn't correct in my email,
    | I want to apologize to you in advance. I spent all of last weekend wondering
    | whether I needed to respond, and when I decided I had to, I spent four days
    | back-checking my tests before I posted this. I didn't want anything to be
    | incorrect. Sometimes you just have to stick up for yourself.
    |
    | I was defending my product against the following statement.
    | > I think BackupEdge is crap with REV drives (too many bad experiences)....
    | > Get LoneTar instead. It's flawless with REV drives.
    |
    | The client had one bad experience (which I guess is too many) on a host
    | adapter he shouldn't be using. That doesn't make BackupEDGE "crap with
    | REV drives" in any general sense. Nor does it make Lone-Tar "flawless
    | with REV drives" by any measure I can envision.
    |
    |
    | : # ltmenu
    | : 7 -> 5 -> 9 -> 1
    | : 7 -> 5 -> 9 -> h This HELP Screen is informative.
    | : ... or ...
    | :
    | : # more /log/changed.V
    | : ^^^^^------------- $TARDIR set inside ltar.cfg (or ENV for older copies)
    | :
    | : | >incredibly important when switching from tape drives, which have
    | : | >built in error checking, to other media types and network backups
    | : | >which do not.
    | : |
    | : | I have the few remainging sites I do work for running BackupEdge
    | : | and Lone-Tar.
    | : |
    | : | I just double checked the Lone-Tar - version 4.1.5 - and the
    | : | default is bit-level-verify - which has parens after it that
    | : | says (recommended). The check-sum verify is the second option
    | : | on the verify menu. I also had a failed bit-level verify last
    | : | night and I checked and it pointed to where the byte vefify failed.
    | : | It identifes the failure with a message of "bytes differ at
    | : | kilobyte 269213". I'd prefer finer-grained reporting, but at
    | : | least it does bit-level.
    | :
    | : Bill... Not only is bit-level recommended, we will WARN you if
    | : fail to do bit-level. Making sure the data is safe, and recoverable
    | : to another system is what its all about... weither with edge or lone-tar,
    | : or anything else for that matter. Weither Tom appreciates it or not,
    | : competitive products are good for the public. It keeps everyone on their
    | : toes not only with features, but pricing as well. Tom is one of my
    | : best salesman.
    |
    | I've never had a problem with competition. I LIKE being compared. Good,
    | FULL comparisons really show where our products shine.
    |
    |
    | : --------------------------- clipped ---------------------------
    | :
    | : Best Regards,
    | : Jeffrey Hyman, CEO/President
    | : .--.
    | : ___________________________ .-. | | _____________________________________
    | : Lone Star Software Corp. | | | | .-. Home of World Famous LONE-TAR(tm)
    | : Cactus International, Inc. | |_| | | | Backup Software for UNIX and LINUX
    | : Sales: 800.525.8649 _ |___ |_| | 24x7 Support Available
    | : Support: 301.829.1622 _| ~- | ___| RESCUE-RANGER(tm) and AIR-BAG(tm)
    | : http://www.LONE-TAR.com \, _} | | Disaster Recovery Software
    | : -------------------------- \( -- | | --------------------------------------
    | : | |
    |
    | Ok, let's go back to that first statement and look at it again.
    |
    | : --------------------------- clipped ---------------------------
    | : | >1) The BackupEDGE data format includes full-file error
    | : | >checksumming, not just header checksumming like Lone-Tar. This is
    | : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    | That statement has NOTHING to do with bit-level-verify, which is in both
    | BackupEDGE and Lone-tar, and is a Good Thing(tm).
    |
    | Bit Level Verify is good and necessary at backup time.
    |
    | I said that your _ data format _, i.e. the way you store data on the archive,
    | has a checkum for the header, and that the data format in BackupEDGE has
    | a checksum for the data. I believe that to be correct, and if I am wrong,
    | please tell us. I've got the backbone to admit I'm wrong.
    |
    | Full file checksum can tell you when there is a difference between the bits
    | you stored (which bit-level-verified perfectly at the time) and the bits you
    | restored years later.
    |
    | Cheers!
    |
    | Tom Podnar
    | Microlite
    |
    |
    | "Good Thing" is a trademark of someone on this group, maybe Jeff Liebermann -

    Tom,

    I'm glad I'm here to defend myself. I would hope you do not do these
    type of tactics on other newsgroups... or anywhere for that matter. It's not
    good business... at least for Microlite. The original comment was about
    the REV drive. You took the opportunity to exploit the original thread
    with a big edge sales/tech pitch against LONE-TAR that IMHO distracted
    from the original issue/problem... the REV drive. The bottom line
    is LONE-TAR worked and BackupEDGE did not. We both know there are
    occasions where BackupEDGE works and LONE-TAR does not work, and
    occasions where neither product is used. We all need to work a little
    more "together" as a team weither competition or not.
    Everyone will benefit.

    PS: You owe me a (double) CC and Ginger at SCOforum! :-)

    See ya,
    Jeff H

  3. Re: IOMEGA Rev intermittent failures

    On Thu, 13 Jul 2006, Jeff Hyman wrote:

    > ...
    >
    > I'm glad I'm here to defend myself. I would hope you do not do these
    > type of tactics on other newsgroups... or anywhere for that matter. It's not


    As an observer who has read this entire exchange, here's my take on this.
    I don't have a vested interest in this, and I don't know the technical
    details of either product. But I sometimes like to play "argument police"
    (or "grammer police, but that's for another day).

    Tom did not use any nasty "tactics", and I don't know why you're
    complaining. In response to broad-brush negative statements, he made a
    careful, narrow, precise, technical, and civil case for the strengths of
    his company's product. I enjoyed its thoroughness, and learned a lot.

    OTOH, you have complained of "tactics", accused him of making untrue
    statements without elaborating, and made fuzzy statements such as "one
    product worked and the other didn't". How about some facts, beyond the
    checksum dispute? For instance:

    1. Can Lone-Tar recover more than 2GB from a Rev?

    2. Does it behave well when media is (are) not present?

    3. Does it behave well when it fills the disk?

    4. What untrue statement(s) did he make?

    In short, Tom may owe you a drink, but I think you owe your market a solid
    presentation of the facts.

    Regards,
    .....Bob Rasmussen, President, Rasmussen Software, Inc.

    personal e-mail: ras@anzio.com
    company e-mail: rsi@anzio.com
    voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
    fax: (US) 503-624-0760
    web: http://www.anzio.com

  4. Re: IOMEGA Rev intermittent failures


    ----- Original Message -----
    From: "Jeff Hyman"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Thursday, July 13, 2006 5:34 PM
    Subject: Re: IOMEGA Rev intermittent failures


    > D. Thomas Podnar typed (on Thu, Jul 13, 2006 at 04:51:53PM -0400):
    > | : --------------------------- clipped ---------------------------
    > | : | >1) The BackupEDGE data format includes full-file error
    > | : | >checksumming, not just header checksumming like Lone-Tar. This is
    > | : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > | : Bill,
    > | : Tom has made some comments about LONE-TAR that are incorrect and he's
    > | : been doing this for some time. I may prepare a more detailed reply to
    > | : these inaccuracies, but in the mean time, here's where the info is on
    > | : bit-level failures.
    > |
    > | Hi Jeff. First of all, if I said ANYTHING that isn't correct in my
    > email,
    > | I want to apologize to you in advance. I spent all of last weekend
    > wondering
    > | whether I needed to respond, and when I decided I had to, I spent four
    > days
    > | back-checking my tests before I posted this. I didn't want anything to
    > be
    > | incorrect. Sometimes you just have to stick up for yourself.
    > |
    > | I was defending my product against the following statement.
    > | > I think BackupEdge is crap with REV drives (too many bad
    > experiences)....
    > | > Get LoneTar instead. It's flawless with REV drives.
    > |
    > | The client had one bad experience (which I guess is too many) on a host
    > | adapter he shouldn't be using. That doesn't make BackupEDGE "crap with
    > | REV drives" in any general sense. Nor does it make Lone-Tar "flawless
    > | with REV drives" by any measure I can envision.
    > |
    > |
    > | : # ltmenu
    > | : 7 -> 5 -> 9 -> 1
    > | : 7 -> 5 -> 9 -> h This HELP Screen is informative.
    > | : ... or ...
    > | :
    > | : # more /log/changed.V
    > | : ^^^^^------------- $TARDIR set inside ltar.cfg (or ENV for
    > older copies)
    > | :
    > | : | >incredibly important when switching from tape drives, which have
    > | : | >built in error checking, to other media types and network backups
    > | : | >which do not.
    > | : |
    > | : | I have the few remainging sites I do work for running BackupEdge
    > | : | and Lone-Tar.
    > | : |
    > | : | I just double checked the Lone-Tar - version 4.1.5 - and the
    > | : | default is bit-level-verify - which has parens after it that
    > | : | says (recommended). The check-sum verify is the second option
    > | : | on the verify menu. I also had a failed bit-level verify last
    > | : | night and I checked and it pointed to where the byte vefify failed.
    > | : | It identifes the failure with a message of "bytes differ at
    > | : | kilobyte 269213". I'd prefer finer-grained reporting, but at
    > | : | least it does bit-level.
    > | :
    > | : Bill... Not only is bit-level recommended, we will WARN you if
    > | : fail to do bit-level. Making sure the data is safe, and recoverable
    > | : to another system is what its all about... weither with edge or
    > lone-tar,
    > | : or anything else for that matter. Weither Tom appreciates it or not,
    > | : competitive products are good for the public. It keeps everyone on
    > their
    > | : toes not only with features, but pricing as well. Tom is one of my
    > | : best salesman.
    > |
    > | I've never had a problem with competition. I LIKE being compared. Good,
    > | FULL comparisons really show where our products shine.
    > |
    > |
    > | : --------------------------- clipped ---------------------------
    > | :
    > | : Best Regards,
    > | : Jeffrey Hyman, CEO/President
    > | : .--.
    > | : ___________________________ .-. | |
    > _____________________________________
    > | : Lone Star Software Corp. | | | | .-. Home of World Famous
    > LONE-TAR(tm)
    > | : Cactus International, Inc. | |_| | | | Backup Software for UNIX and
    > LINUX
    > | : Sales: 800.525.8649 _ |___ |_| | 24x7 Support Available
    > | : Support: 301.829.1622 _| ~- | ___| RESCUE-RANGER(tm) and
    > AIR-BAG(tm)
    > | : http://www.LONE-TAR.com \, _} | | Disaster Recovery
    > Software
    > | : -------------------------- \( -- |
    > | --------------------------------------
    > | : | |
    > |
    > | Ok, let's go back to that first statement and look at it again.
    > |
    > | : --------------------------- clipped ---------------------------
    > | : | >1) The BackupEDGE data format includes full-file error
    > | : | >checksumming, not just header checksumming like Lone-Tar. This is
    > | : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > |
    > | That statement has NOTHING to do with bit-level-verify, which is in both
    > | BackupEDGE and Lone-tar, and is a Good Thing(tm).
    > |
    > | Bit Level Verify is good and necessary at backup time.
    > |
    > | I said that your _ data format _, i.e. the way you store data on the
    > archive,
    > | has a checkum for the header, and that the data format in BackupEDGE has
    > | a checksum for the data. I believe that to be correct, and if I am
    > wrong,
    > | please tell us. I've got the backbone to admit I'm wrong.
    > |
    > | Full file checksum can tell you when there is a difference between the
    > bits
    > | you stored (which bit-level-verified perfectly at the time) and the bits
    > you
    > | restored years later.
    > |
    > | Cheers!
    > |
    > | Tom Podnar
    > | Microlite
    > |
    > |
    > | "Good Thing" is a trademark of someone on this group, maybe Jeff
    > Liebermann -
    >
    > Tom,
    >
    > I'm glad I'm here to defend myself. I would hope you do not do these
    > type of tactics on other newsgroups... or anywhere for that matter. It's
    > not
    > good business... at least for Microlite. The original comment was about
    > the REV drive. You took the opportunity to exploit the original thread
    > with a big edge sales/tech pitch against LONE-TAR that IMHO distracted
    > from the original issue/problem... the REV drive. The bottom line
    > is LONE-TAR worked and BackupEDGE did not. We both know there are
    > occasions where BackupEDGE works and LONE-TAR does not work, and
    > occasions where neither product is used. We all need to work a little
    > more "together" as a team weither competition or not.
    > Everyone will benefit.
    >
    > PS: You owe me a (double) CC and Ginger at SCOforum! :-)
    >
    > See ya,
    > Jeff H


    Well, assuming Tom isn't flat out lying, then I think one question needs to
    be nailed down.
    The original poster says "lonetar just worked no problems"
    And Tom described situations where LoneTar certainly appeared to "just work"
    but certainly did not actually work.

    So the question is, has anyone proved that this rev drive is really working
    for the original poster? All the way?
    As in, did a restore that included more than 2 gigs? Did a restore that
    exceeded the size of a single media?
    Did a restore from an incomplete media and had LoneTar alert the user "hey
    this volume is incomplete by the way"?
    Tom described situations where even a bit level verify could be fooled into
    thinking all was well because the data just cut off at 2 gigs or at the
    un-noticed end of the media, and the verify would only show that the data on
    the media is good but says nothing about data thats missing altogether,
    especially if the file at the end of the media just happend to get naturally
    updated on disk by the time the verify reached it.
    Are you claiming that any of the things Tom tested are in fact not true?
    Do you claim his results were the result of some fluke of his test bed
    hardware and OS and not representative in general?

    Or that they just don't matter because the verify obviates any other
    diagnostics?

    Or, another possibility, do you maybe claim that while his statements were
    true and representative, they were slanted to point out only specific things
    that backupedge gets right that lonetar gets wrong, and that you could point
    out different, equivalently bad things that lonetar gets right that
    backupedge gets wrong?

    I would be interested if your rebuttal to Tom even merely included the kind
    of systematic empirical proofs his post 100% consisted of.

    I think his post was perfectly on the topic of a rebuttal to the original
    poster and not a BackupEdge vs LoneTar smear tactic.
    The point he was making was not about lonetar. It was to claim and then show
    that the original posters comments were both unfounded and false. To do that
    he necessarily had to show what makes the unfounded claims unfounded and
    what makes the false ones false. The only problem anyone should have with
    any of that is if Tom was actually wrong about anything. And he repeatedly
    expressed willingness to BE proven wrong. If he is, just show us.

    Aside from all that, if his goal really was an excuse to pitch BackupEdge,
    he could have written a novel and he didn't. Whole classes of awsome
    features he never even mentioned because they weren't relevent to the actual
    goal, which was to clear up misinformation about rev drive compatibility.

    And lest you think I'm just in love with backupedge, well I certainly like
    it, but personally, I'd actually rather Unitrends hadn't stopped selling
    ctar!
    All our own and our customers boxes had ctar on them up to last year.
    Blissful consistency and familiarity and uniformity.
    Though I do make good use of some of BE's exotic features now that I have
    them, that are just impossible with ctar.
    The (relative) crudeness of ctar is actually a benefit sometimes even though
    it does come hand in hand with lack of flexability and modern features.
    The complexity of BE introduces failure points that I've hit that just
    didn't even exist in ctar. In order to make my backups really reliable, I
    had to make a script that knows how to find edge processes and kill them,
    and find edge job lock files in the /usr/lib/edge tree and remove them, and
    add that to cron just before the edge backup is scheduled. I never had to do
    that with ctar and I was very incredulous to discover that a problem with a
    bad tape or an ungracefully killed edge or some other transient problem one
    night could cause _every subsequent backup to fail to even try to start_!
    Due to a silly lockfile being left behind. To me that was way too delicate
    of an arrangement for backup software. With ctar I would never have to worry
    about that possibility of some customers box that is almost completely
    un-monitored suffering a real crash and we discover that all 14 nightly
    tapes were hopelessly obsolete because backups just stopped working one day
    months or years ago because one day the server lost power while backups were
    running. Every time the cron job fires up ctar, it's a completely fresh
    attempt so no matter what happened yesterday, there is a as good a chance as
    possible that today it will work. Transient problems are properly transient.
    There are a few other things but I have no wish to slam BackupEdge. I merely
    wish to show I'm not unduely biased in how I interpreted Tom's post.

    Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  5. Re: IOMEGA Rev intermittent failures

    Brian K. White wrote:

    > The complexity of BE introduces failure points that I've hit that just
    > didn't even exist in ctar. In order to make my backups really reliable, I
    > had to make a script that knows how to find edge processes and kill them,
    > and find edge job lock files in the /usr/lib/edge tree and remove them, and
    > add that to cron just before the edge backup is scheduled. I never had to do
    > that with ctar and I was very incredulous to discover that a problem with a
    > bad tape or an ungracefully killed edge or some other transient problem one
    > night could cause _every subsequent backup to fail to even try to start_!
    > Due to a silly lockfile being left behind. To me that was way too delicate
    > of an arrangement for backup software. With ctar I would never have to worry
    > about that possibility of some customers box that is almost completely
    > un-monitored suffering a real crash and we discover that all 14 nightly
    > tapes were hopelessly obsolete because backups just stopped working one day
    > months or years ago because one day the server lost power while backups were
    > running. Every time the cron job fires up ctar, it's a completely fresh
    > attempt so no matter what happened yesterday, there is a as good a chance as
    > possible that today it will work. Transient problems are properly transient.
    > There are a few other things but I have no wish to slam BackupEdge. I merely
    > wish to show I'm not unduely biased in how I interpreted Tom's post.


    These sound like serious issues with BackupEDGE, so I hope you have
    properly communicated them to MicroLite. I hear a little detail bug
    (with a big impact), a medium sized bug, and a serious behavior problem:

    - not properly breaking stale lock files
    - some sort of edge process hang (needs more detail)
    - not adequately alerting the administrator when periodic scheduled
    backups are failing

    (From the way you describe it, I would guess these are problems you had
    long ago with probably not the current version of BE. Which doesn't
    mean they've necessarily been fixed since then -- but if not, again,
    have you made sure ML knows about the problems?)

    >Bela<


  6. Re: IOMEGA Rev intermittent failures

    Bela Lubkin wrote (on Fri, Jul 14, 2006 at 08:54:48AM -0700):
    > Brian K. White wrote:
    >
    > > There are a few other things but I have no wish to slam BackupEdge. I merely
    > > wish to show I'm not unduely biased in how I interpreted Tom's post.

    >
    > These sound like serious issues with BackupEDGE, so I hope you have
    > properly communicated them to MicroLite. I hear a little detail bug
    > (with a big impact), a medium sized bug, and a serious behavior problem:
    >
    > - not properly breaking stale lock files
    > - some sort of edge process hang (needs more detail)
    > - not adequately alerting the administrator when periodic scheduled
    > backups are failing
    >
    > (From the way you describe it, I would guess these are problems you had
    > long ago with probably not the current version of BE. Which doesn't
    > mean they've necessarily been fixed since then -- but if not, again,
    > have you made sure ML knows about the problems?)
    >
    > >Bela<


    >From my own (extensive) use of BE, #1 *is* a problem, never had #2, and

    I *always* had a printer/emailed report when a backup failed - for any
    reason, including lock files. So, really, #1 isn't a problem, as the
    admin is made aware of it. Now, when no one read the emails ...

    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  7. Re: IOMEGA Rev intermittent failures

    On Fri, Jul 14, 2006 at 08:54:48AM -0700, Bela Lubkin wrote:
    > Brian K. White wrote:
    >
    > > The complexity of BE introduces failure points that I've hit that just
    > > didn't even exist in ctar. In order to make my backups really reliable, I
    > > had to make a script that knows how to find edge processes and kill them,
    > > and find edge job lock files in the /usr/lib/edge tree and remove them, and
    > > add that to cron just before the edge backup is scheduled. I never had to do
    > > that with ctar and I was very incredulous to discover that a problem with a
    > > bad tape or an ungracefully killed edge or some other transient problem one
    > > night could cause _every subsequent backup to fail to even try to start_!
    > > Due to a silly lockfile being left behind. To me that was way too delicate
    > > of an arrangement for backup software. With ctar I would never have to worry
    > > about that possibility of some customers box that is almost completely
    > > un-monitored suffering a real crash and we discover that all 14 nightly
    > > tapes were hopelessly obsolete because backups just stopped working one day
    > > months or years ago because one day the server lost power while backups were
    > > running. Every time the cron job fires up ctar, it's a completely fresh
    > > attempt so no matter what happened yesterday, there is a as good a chance as
    > > possible that today it will work. Transient problems are properly transient.
    > > There are a few other things but I have no wish to slam BackupEdge. I merely
    > > wish to show I'm not unduely biased in how I interpreted Tom's post.

    >
    > These sound like serious issues with BackupEDGE, so I hope you have
    > properly communicated them to MicroLite. I hear a little detail bug
    > (with a big impact), a medium sized bug, and a serious behavior problem:
    >
    > - not properly breaking stale lock files
    > - some sort of edge process hang (needs more detail)
    > - not adequately alerting the administrator when periodic scheduled
    > backups are failing
    >
    > (From the way you describe it, I would guess these are problems you had
    > long ago with probably not the current version of BE. Which doesn't
    > mean they've necessarily been fixed since then -- but if not, again,
    > have you made sure ML knows about the problems?)
    >
    > >Bela<



    Thank you Bela. You are exactly correct. It may be a support issue.

    The first questions I would ask deal more with social engineering, i.e.
    sometimes you get so used to one behaviour on one program (like ctar) that
    you expect that behaviour with other products, and it may not exist.

    1 - BackupEDGE schedules are designed not to allow the next schedule to run,
    (like tomorrow's backup) to run as long as it thinks a current backup
    is still running.

    2 - BackupEDGE is designed to exit gracefully (kill processes, remove lockfiles,
    notify users, etc.) for every KNOWN condition that causes a failure.

    3 - Even if you reboot a server in the middle of the backup, BackupEDGE runs
    a startup script to remove lock files. If you have a system where this
    is not happening we need to know.

    4 - It is always possible for a process to die a horrible death and leave a
    lock file behind that is not covered by (2) or (3). These are the cases
    that we can only try to cure if someone actually has a problem and
    lets us know.

    It is most useful to determine the CAUSE of a lockfile and process to be
    running before just killing/removing them.


    ALMOST 100% of the time, when we have a "lock file" support question, it is
    simply because BackupEDGE is still running, patiently waiting for user input,
    i.e. for a volume change. When this happens it always sends an email
    notification,

    Sometimes people's old habits dictate that if back software is still running
    the next morning, or the next night, they just "kill -9" the process and then
    they are stuck removing the lockfile.


    The actual correct procedure for BackupEDGE is simply to launch edgemenu. If a
    process is waiting for user input, you'll be prompted, before the main menu
    even appears, to either insert a new volume and press [Enter], or to cancel
    the backup entirely.

    If edgemenu is already running, select "Schedule -> Acknowledge All" and
    again prompts will appear for any and all active processes waiting for a prompt.

    Currently, new volume prompts are sent to any and all users identified in
    the "Mail Summary To" section of each Schedule. If it is helpful, we could
    easily make the "Print Summary To" notifiers also get new volume prompts,
    along with a flag to turn them off for those not wanting them. You opinions
    on this would be valuable.


    If there is a case that is not covered by this response, i.e. a process is
    still running or a lock file exists a day or to later, please call our support
    department before taking action, so we can ask questions to help determine
    the actual issues.

    Regards,
    --
    Tom
    D. Thomas Podnar
    Microlite Corporation
    2315 Mill Street
    Aliquippa PA USA 15001-2228
    724-375-6711
    888-257-3343 Sales
    Developers of Microlite BackupEDGE

  8. Re: IOMEGA Rev intermittent failures

    On Fri, Jul 14, 2006 at 01:25:37PM -0400, D . Thomas Podnar wrote:
    > ...
    >
    > ALMOST 100% of the time, when we have a "lock file" support question, it is
    > simply because BackupEDGE is still running, patiently waiting for user input,
    > i.e. for a volume change. When this happens it always sends an email
    > notification,
    > ...
    > Currently, new volume prompts are sent to any and all users identified in
    > the "Mail Summary To" section of each Schedule. If it is helpful, we could
    > easily make the "Print Summary To" notifiers also get new volume prompts,
    > along with a flag to turn them off for those not wanting them. You opinions
    > on this would be valuable.


    YES, please separate "New Volume" requests as well as "Overwrite warnings"
    into separate notifiers.

    I dont' recall ever seeing new volumne requests ever, and now that you
    tell us it goes same place as print-summary, i can just assume moron end
    users delete email and change tape by rote, no thinking process involved at
    all, so we as support people never find out until the next day's backup
    fail message on lockfile and have to backtrack why.

    -joe

    p.s. i've often scheduled my own cron job a few hours after backup-edge
    that checks process tree for any still-running edge jobs and emails
    around if found - this might be of use to add to product as well.

    --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
    -Joe Chasan- Magnatech Business Systems, Inc.
    joe@magnatechonline.com Hicksville, NY - USA
    http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264

  9. Re: IOMEGA Rev intermittent failures

    In article <20060714132537.A792@mlite.microlite.com>,
    D . Thomas Podnar wrote:

    [Huge deletion - wjv]


    >1 - BackupEDGE schedules are designed not to allow the next
    >schedule to run, (like tomorrow's backup) to run as long as it
    >thinks a current backup is still running.


    Years ago I had a clinet with a fairly large system - about 130
    users in 22 cities.

    They had problems ejecting the DAT tape unless the shut down the
    system. They didn't call me on this.

    This had happened a few times, and I found out when the HW support
    firm called me to be there when they changed out the DAT drive.

    The client - as I said - never called me - and assumed the Sony
    DAT drive was dead.

    Then a week or so after the new drive was in they had the same
    problem. Their software - which was a huge package in one
    of the BASIC languages - which from my POV was slow and awkward -
    especially in the way it searched - was locking files and
    BackupEdge was patiently waiting for some user to exit the program.

    I found this when they called me the second time - and spotted
    the messsage in the log. They called the person who had been
    logged in overnight, and had him exit the program.

    Almost instantly the tape drive fired up, finished that one
    last file, BackupEdge exited, and the tape was able to be removed.

    The biggest problem I've had with several clients it to get them
    just to call me when they have any problem. So often a HW problem
    looks like SW, and vice-versa.

    And some would only call me for HW problems, and others only for
    SW, as they had met so many who knew only one or the other so they
    assumed I only knew about the orginal problem I was called about.

    Never had any real problems with BE that users hadn't created
    for themselves.

    Bill
    --
    Bill Vermillion - bv @ wjv . com

  10. Re: IOMEGA Rev intermittent failures


    ----- Original Message -----
    From: "Bela Lubkin"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Friday, July 14, 2006 11:54 AM
    Subject: Re: IOMEGA Rev intermittent failures


    > Brian K. White wrote:
    >
    >> The complexity of BE introduces failure points that I've hit that just
    >> didn't even exist in ctar. In order to make my backups really reliable, I
    >> had to make a script that knows how to find edge processes and kill them,
    >> and find edge job lock files in the /usr/lib/edge tree and remove them,
    >> and
    >> add that to cron just before the edge backup is scheduled. I never had to
    >> do
    >> that with ctar and I was very incredulous to discover that a problem with
    >> a
    >> bad tape or an ungracefully killed edge or some other transient problem
    >> one
    >> night could cause _every subsequent backup to fail to even try to start_!
    >> Due to a silly lockfile being left behind. To me that was way too
    >> delicate
    >> of an arrangement for backup software. With ctar I would never have to
    >> worry
    >> about that possibility of some customers box that is almost completely
    >> un-monitored suffering a real crash and we discover that all 14 nightly
    >> tapes were hopelessly obsolete because backups just stopped working one
    >> day
    >> months or years ago because one day the server lost power while backups
    >> were
    >> running. Every time the cron job fires up ctar, it's a completely fresh
    >> attempt so no matter what happened yesterday, there is a as good a chance
    >> as
    >> possible that today it will work. Transient problems are properly
    >> transient.
    >> There are a few other things but I have no wish to slam BackupEdge. I
    >> merely
    >> wish to show I'm not unduely biased in how I interpreted Tom's post.

    >
    > These sound like serious issues with BackupEDGE, so I hope you have
    > properly communicated them to MicroLite. I hear a little detail bug
    > (with a big impact), a medium sized bug, and a serious behavior problem:
    >
    > - not properly breaking stale lock files
    > - some sort of edge process hang (needs more detail)
    > - not adequately alerting the administrator when periodic scheduled
    > backups are failing
    >
    > (From the way you describe it, I would guess these are problems you had
    > long ago with probably not the current version of BE. Which doesn't
    > mean they've necessarily been fixed since then -- but if not, again,
    > have you made sure ML knows about the problems?)
    >
    >>Bela<



    Oh it alerted perfectly well. My own boxes get monitored and it wasn't a big
    problem. It was just an unpleasant surprise and I was glad it wasn't a
    customers box where I first discovered it.
    Customer boxes often aren't monitored at all. Some mployee has the chore of
    swapping the tapes every day and generally that gets done, and generally
    thats it, they don't even turn on the screen or even have a keyboard out in
    a handy place sometimes.
    It's not good enough (IMO) to keep telling the customers they need to pay
    attention to that printout every morning.
    Some do, some don't, and I think it's best to try to be as robust as
    possible even for users that don't do their job.

    Sometimes a thing needs to be smarter and more complex in order to be more
    reliable.
    Sometimes exactly the opposite is true.

    I'm not quite willing to say backups should be simpler and cruder either.
    I'm just pointing out one situation where it worked out that way.
    Now that I use BackupEdge, I don't think I'm willing to give up all that
    great stuff it does myself.
    I'm sure my edge resetter script actually breaks edge horribly in some other
    situations and I'm glad I wasn't within strangling distance of Tom when I
    described what I'm doing to his wonderful app.
    For example, I just happen to know that I sized my fs and my tapes so that a
    full system backup always fits on a single media, and so I just happen to
    know what edge can't, that I'll never have a legitimately hung process thats
    waiting for a volume 2.
    If a media is bad and it would have halted for a volume 2 from that, I
    happen to know that I would rather have that days backup simply fail and not
    get in the way of the next days.
    I can't say that's the more proper behaviour for anyone else.

    --
    Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  11. Re: IOMEGA Rev intermittent failures

    On Fri, Jul 14, 2006 at 03:16:34PM -0400, Brian K. White wrote:
    >

    Snip!
    >
    > Oh it alerted perfectly well. My own boxes get monitored and it wasn't a big
    > problem. It was just an unpleasant surprise and I was glad it wasn't a
    > customers box where I first discovered it.
    > Customer boxes often aren't monitored at all. Some mployee has the chore of
    > swapping the tapes every day and generally that gets done, and generally
    > thats it, they don't even turn on the screen or even have a keyboard out in
    > a handy place sometimes.
    > It's not good enough (IMO) to keep telling the customers they need to pay
    > attention to that printout every morning.
    > Some do, some don't, and I think it's best to try to be as robust as
    > possible even for users that don't do their job.


    I can send them emails. I can send reports to their printers.

    You can modify one of our notifiers to set off the fire alarm if it is
    connected to your network.

    But alas, some level of client responsibility is involved. If they aren't
    reading reports or email, they probably aren't changing tapes (and ignoring
    the warnings we send when we overwrite a backup), and probably not cleaning
    their tape heads, just wearing them right off the drive.

    One method is to tell them, if the piece of paper comes out, file it.
    If it doesn't, call me. They may not read the report for errors, but if they
    get nothing, the backup didn't complete, good or bad.


    > Sometimes a thing needs to be smarter and more complex in order to be more
    > reliable.
    > Sometimes exactly the opposite is true.
    >
    > I'm not quite willing to say backups should be simpler and cruder either.
    > I'm just pointing out one situation where it worked out that way.
    > Now that I use BackupEdge, I don't think I'm willing to give up all that
    > great stuff it does myself.
    > I'm sure my edge resetter script actually breaks edge horribly in some other
    > situations and I'm glad I wasn't within strangling distance of Tom when I
    > described what I'm doing to his wonderful app.
    > For example, I just happen to know that I sized my fs and my tapes so that a
    > full system backup always fits on a single media, and so I just happen to
    > know what edge can't, that I'll never have a legitimately hung process thats
    > waiting for a volume 2.
    > If a media is bad and it would have halted for a volume 2 from that, I
    > happen to know that I would rather have that days backup simply fail and not
    > get in the way of the next days.
    > I can't say that's the more proper behaviour for anyone else.


    It is true to say that every scenario is different. I wish there was a
    "one size fits all" solution. The scenario you described could, in the right
    situation, terminate every nightly backup and they'd never know it.


    While we're dreaming up the perfect solution, here's another helper.

    In our Scheduler, under Notify/Advanced, there is an "Eject/Verify" flag.
    Setting this assures that, if and only if the backup and verify were
    successful, BackupEDGE will eject the tape.

    So the user gets trained, if the tape is ejected when you come in in the
    morning, put in another one. If the door is still closed, don't open it
    and call me.

    It is not quite as useful for some CD/DVD devices that may close on a
    reboot or time out and close, but for tapes, It can be a good visual cue.

    Hope this helps.

    There is also an eject on new volume flag, but I see it as less useful in
    your environment. If the tape drive is truly hung, it is of no help.
    >
    > --
    > Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
    > +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    > filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
    >


    --
    Tom
    D. Thomas Podnar
    Microlite Corporation
    2315 Mill Street
    Aliquippa PA USA 15001-2228
    724-375-6711
    888-257-3343 Sales
    Developers of Microlite BackupEDGE

  12. Re: IOMEGA Rev intermittent failures

    On Fri, Jul 14, 2006 at 02:03:18PM -0400, Joe Chasan wrote:
    > On Fri, Jul 14, 2006 at 01:25:37PM -0400, D . Thomas Podnar wrote:
    > > ...
    > >
    > > ALMOST 100% of the time, when we have a "lock file" support question, it is
    > > simply because BackupEDGE is still running, patiently waiting for user input,
    > > i.e. for a volume change. When this happens it always sends an email
    > > notification,
    > > ...
    > > Currently, new volume prompts are sent to any and all users identified in
    > > the "Mail Summary To" section of each Schedule. If it is helpful, we could
    > > easily make the "Print Summary To" notifiers also get new volume prompts,
    > > along with a flag to turn them off for those not wanting them. You opinions
    > > on this would be valuable.

    >
    > YES, please separate "New Volume" requests as well as "Overwrite warnings"
    > into separate notifiers.
    >
    > I dont' recall ever seeing new volumne requests ever, and now that you
    > tell us it goes same place as print-summary, i can just assume moron end
    > users delete email and change tape by rote, no thinking process involved at
    > all, so we as support people never find out until the next day's backup
    > fail message on lockfile and have to backtrack why.


    Actually, I said that the email notifiers currently get new volume prompts,
    not the print notifiers, but we could look into changing that.

    I actually thought our two levels of escalation, one group of email / printer
    for "All" messages, another group only getting "Failures and Warnings", was
    pretty innovative, as no one else we know of does this. I'll have to see
    what it takes to expand on that. We see LOTS of dealers emailing failures and
    warnings back to themselves.

    As with any new feature request, all are invited to send their thoughts
    to "whats next at microlite dot com" (modified to not have any spaces, etc.)
    which is an email alias we created a while back to gather this kind of
    feedback.

    >
    > -joe
    >
    > p.s. i've often scheduled my own cron job a few hours after backup-edge
    > that checks process tree for any still-running edge jobs and emails
    > around if found - this might be of use to add to product as well.
    >
    > --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
    > -Joe Chasan- Magnatech Business Systems, Inc.
    > joe@magnatechonline.com Hicksville, NY - USA
    > http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264


    Thanks for the feedback. It is appreciated.

    --
    Tom
    D. Thomas Podnar
    Microlite Corporation
    2315 Mill Street
    Aliquippa PA USA 15001-2228
    724-375-6711
    888-257-3343 Sales
    Developers of Microlite BackupEDGE

  13. Re: IOMEGA Rev intermittent failures

    On Thu, 13 Jul 2006 16:23:26 -0700 (PDT), Bob Rasmussen
    wrote:

    >On Thu, 13 Jul 2006, Jeff Hyman wrote:
    >
    >> ...
    >>
    >> I'm glad I'm here to defend myself. I would hope you do not do these
    >> type of tactics on other newsgroups... or anywhere for that matter. It's not

    >
    >As an observer who has read this entire exchange, here's my take on this.
    >I don't have a vested interest in this, and I don't know the technical
    >details of either product. But I sometimes like to play "argument police"
    >(or "grammer police, but that's for another day).
    >
    >Tom did not use any nasty "tactics", and I don't know why you're
    >complaining. In response to broad-brush negative statements, he made a
    >careful, narrow, precise, technical, and civil case for the strengths of
    >his company's product. I enjoyed its thoroughness, and learned a lot.
    >
    >OTOH, you have complained of "tactics", accused him of making untrue
    >statements without elaborating, and made fuzzy statements such as "one
    >product worked and the other didn't". How about some facts, beyond the
    >checksum dispute? For instance:
    >
    >1. Can Lone-Tar recover more than 2GB from a Rev?
    >
    >2. Does it behave well when media is (are) not present?
    >
    >3. Does it behave well when it fills the disk?
    >
    >4. What untrue statement(s) did he make?
    >
    >In short, Tom may owe you a drink, but I think you owe your market a solid
    >presentation of the facts.
    >
    >Regards,
    >....Bob Rasmussen, President, Rasmussen Software, Inc.
    >
    >personal e-mail: ras@anzio.com
    > company e-mail: rsi@anzio.com
    > voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
    > fax: (US) 503-624-0760
    > web: http://www.anzio.com


    Very interesting thread.

    I can answer your first and second question:

    1. Can Lone-Tar recover more than 2GB from a Rev?

    Yes. I do successful Lone-tar master backups and
    full restores from those backups quite regularly
    on SCO OSR507/MP3 systems.

    2. Does it behave well when media is (are) not present?
    Yes, and prior to the start of the backup.

    The REV drive(s) I use are the USB model connected to
    Dell PowerEdge 700 servers that contain PERC/4 SCSI HA's.

    So, can I now get a free drink from somebody at SCO Forum?

    DDinaz




+ Reply to Thread