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.

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 -

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

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.

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.

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:

(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<

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 ...

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.

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.

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.

Re: IOMEGA Rev intermittent failures

>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

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.

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!
>

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

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.