Re: IOMEGA Rev intermittent failures
D. Thomas Podnar
> I think BackupEdge is crap with REV drives (too many bad experiences)....
> Get LoneTar instead. It's flawless with REV drives. Download a trial
> version and you'll see what I mean. Also technical support is more user
> friendly, you talk to the main programmer the first time you talk to
> someone. Don't need to escalate to the next level. Just my 2 cents.
Mr. Arredondo.
I normally ignore this kind of stuff. Responding properly requires pointing out
to a potential client that they might be wrong about something, and to talk
about someone else's product in a less-than glowing fasion. Neither are my
favorite things to do.
But now you've made this kind of comment twice in a 10 month period, and
perhaps bruised our reputation a bit with customers who don't know better, so
I feel it is necessary in this case to reply.
So lets look at your comments, statement-by-statement.
> I think BackupEdge is crap with REV drives (too many bad experiences)....
The only experience I'm aware of that you had was back in Sep '05 when you
attached the REV to a PERC 4 RAID controller and we had a problem. We
spent two weeks working to help you, even though the Dell web site
CLEARLY STATES...
"NOTE: The PERC 4/Di/Si and 4e/Di/Si RAID controllers support
hard disk drives only; they do not support CD-ROMs, tape drives,
tape libraries, or scanners."
Dell Reference:
http://support.dell.com/support/edocs/storage/RAID/perc4e/en/ug/chap1.htm?c=us&l=en&cs=04&s=bsd
So even though Dell says DON'T DO THIS (the REV has a CD-ROM-type BIOS)
you still thought it was a good thing to do. We tried to help.
Lone-Tar is MUCH less sophisticated in its REV error handling than BackupEDGE,
and I eventually made a decision to stop spending engineering time trying to
support a host adapter that that the manufacture says a REV should never be
plugged into.
> Get LoneTar instead. It's flawless with REV drives.
Let's examine that statement. I'll have to, in order to justify what I
said in my last paragraph, won't I?
Caveat. I really DON'T like talking about other people's products, but
sometimes manufactures are the only ones who really understand the differences
between hype and reality.
Scribbling data on a REV is quite simple. It took us about 10 minutes
from the time we saw our first REV to the time we were writing on it.
Adding the things necessary to make it it into a reliable backup device,
especially the error checking, took a lot longer. We favor not just doing the
10% of the work necessary to say we "support" something, but instead doing the
other 90% to fully integrate a new technology before we release it. we'll still
have problems, as customer environments differ, but we'll have done everything
we can to make a product reliable before shipping it.
We downloaded the Lone-Tar 4.2 that was available on their web site for demo
on 7/10/2006 and installed it along with BackupEDGE 02.01.05 build 2. The
machine is an HP ML330 G3 with 2 SCSI 73GB 10k hard drives and a SCSI REV
plugged in to the same HP OEM variant of the Adaptec 29160 that comes with
the G3. The system has OpenServer 5.0.7, a development system, and MP4.
There is also an ATAPI Sony DVD-Multi drive DRU-820A.
BackupEDGE and Lone-Tar were not modified from default, with device detection
settings unaltered.
The first thing we did was create a bunch of 1GB directories.
To do this we concatenated all the operating system files into one large
file, then split the first 1GB of this file into 8 slices. We then duplicated
these 1GB directories as many times as needed.
The first tests involved backing up 3 GB of data, using 3 directories, with
compression disabled.
-- Lone-Tar Test 1. Start Backup - no REV Media inserted.
Lone-Tar DID NOT NOTICE that I hadn't inserted any media. It merrily
proceded to do a 3GB backup at about 853 MB/min, then reported...
Status: 0 Backup was successful!!
Whoops.
Fortunately, the verify noticed that it had nothing to read, and failed.
Don't ever disable verify.
-- Lone-Tar Test 2. Start Backup - Media Inserted - Kill REV writer
lt.devcontrol after one minute.
Lone-Tar reports "NETWORK LINK just FAILED!", prompts for a new volume,
and waits. Couldn't answer "n" or anything else but "Y", so had to
core dump to escape.
-- Lone-Tar Test 3. Start Backup - Media Inserted - No test complexity
Lone-Tar did a relatively quick 3GB backup.
Speed: 17699130 Bytes/sec (1012.7 MB/min)
Elapsed: 3 minutes 2 seconds
However, after an hour, the verify wasn't complete, and the REV light was
out, so I started looking and the process was hung out. I killed it and the
log indicated that it had gotten through about 2GB of data before stopping.
So I tried to RESTORE the REV. After an hour, the light went out again and
I waited and waited. When I finally killed the process, it was obvious
that Lone-Tar FAILED TO RESTORE ANY DATA past the 2GB mark on the media.
A "lone-tar tvnf /dev/rcd1" also failed at 2GB.
When I couldn't restore more than 2GB of data from the REV, I decided
to duplicate this test on the Sony DVD-Multi using DVD-RAM. I tried
the no media test with the same results, and Lone-Tar was unable to
verify or restore more than 2GB of data from the DVD-RAM.
Now let's look at those same tests using BackupEDGE.
-- BackupEDGE Test 1. Start Backup - no REV Media inserted.
BackupEDGE failed during media prep/detection with "No Media Inserted".
-- BackupEDGE Test 2. Start Backup - Media Inserted - Kill REV writer
edge.tape after one minute.
BackupEDGE fails immediately. The error message is a little cryptic
but it knows what to do.
-- BackupEDGE Test 3. Start Backup - Media Inserted - No test complexity
BackupEDGE had a backup speed approximately 29% faster than Lone-Tar.
Elapsed Time = 00:02:21
Data Transfer Speed = 76.568 GB/hr
= 1306.786 MB/min
BackupEDGE verified the 3GB properly.
Elapsed Time = 00:02:15
Data Transfer Speed = 80.000 GB/hr
= 1365.354 MB/min
BackupEDGE restored the 3GB properly.
Elapsed Time = 00:05:34
Data Transfer Speed = 32.335 GB/hr
= 551.864 MB/min
Restore, of course relates more to the hard drive / filesystem write speed.
To complete the BackupEDGE part of the test, I backed up 33GB of data,
which assured I would need to use 2 volumes.
Data Transfer Speed = 33.741 GB/hr
= 575.876 MB/min
Segments Used = 2
Data Read = 33GB
Even though I can't restore anything more than 2GB into the REV media using
Lone-Tar 4.2, I thought I'd try a few more tests.
The Lone-Tar auto-detector arbitrarily sets the REV volume size at 34000000KB,
or about 32.42GB. This wastes over 177MB of available media space. However,
this is MUCH BETTER than the volume size their last release used, which
was 35000000KB, or about 799MB MORE than the actual capacity of a REV. For
over a year they didn't notice this, so one wonders if they never really tried
to fill a single REV.
So I set a very high volume size and tried to write 35GB of data to the REV.
Lone-Tar DIDN'T NOTICE WHEN IT RAN OUT OF MEDIA, and just continued to write
the data to nowhere until the 35GB was complete.
During verify, it may or may not notice that it threw that data away, depending
on whether the last block it DID write was the last block of a real file.
If you've got an older release of Lone-Tar with the size set to 35000000,
you need to go lower it before you fill a volume.
Question: If the Lone-Tar writer ignores the fact that it has no media, or that
it has filled the media, what does it do with normal, everyday write errors
or SCSI errors?
BackupEDGE actually ASKS THE MEDIA how many raw blocks are available, applies
the appropriate mmc-recommended formula, and calculates a reliable volume size. It does this on a PER-MEDIA basis during a backup.
This is even more important when using CD/DVD media, where BackupEDGE detects
media type, write strategy, preparation strategy and volume size on a
per media basis. A multi-volume backup can actually have a DVD+R dual layer
as volume 1, CD-RW as volume 2, DVD+RW as volume 3, and an 8cm 200MB CD-R
as volume 4, or any other combination of supported media. It will get
everything right, including preparing and finishing the media (if necessary)
and setting each volume size to the maximum usable space. No least-common
denominators that waste space, and no knowledge on the part of the end-user
required.
Note: Lone-Tar told me it couldn't identify my Sony DVD-Multi drive and
was going to set it to be a CD-RW drive, and did so with a
least-common-denominator CD volume size. When I re-set it to DVD-RAM, as an
end-user I would have had no idea what volume size to use. Fortunately for me,
I was able to ask BackupEDGE for the proper volume size to give Lone-Tar.
Full disclosure. If you take volume size out of BackupEDGE's hands and set
it too high, it can hang when media is full on the REV. It won't keep backing
up and pass the backup: it will just stop. We didn't notice that since
BackupEDGE, not the user, is responsible for volume size. We're looking to
see if we need to improve that.
So, so far, we have Lone-Tar 4.2...
- not detecting that the REV has no media.
- not properly recognizing when something bad happens to the writer.
- not detecting and using maximum storage space on the media.
- not detecting that the REV has filled the media if bad volume size is used.
- not being nearly as fast as BackupEDGE where we could test it.
and most importantly.
- not being able to restore more than 2GB of data from a backup.
They must have blown the 2GB thing in their rush to release 4.2. I know
they had this problem before but I thought they fixed it.
Flawless, huh?
I would point out that these are just two devices on one system, using one
version of Lone-Tar (the latest they had on Monday when I started these
tests). Your results may vary. And knowing what I know, I expect the 2GB issue
to be limited to OpenServer 5.
Should they get these problems resolved, I guess I'll mention a few more
reasons why BackupEDGE is the far better choice for REV (or any other media).
1) The BackupEDGE data format includes full-file error checksumming, not just
header checksumming like Lone-Tar. This is incredibly important when
switching from tape drives, which have built in error checking, to other
media types and network backups which do not.
2) It is 2006, and Lone-Tar will STILL fail to back up files with over 400
character pathnames or 170 character link pathnames. BackupEDGE handles
5,000 character pathnames of any type, far longer than UNIX can actually
traverse or create.
3) BackupEDGE has Instant File Restore, which can access files within seconds
from network, REV, DVD, and CD backups (even those with multiple volumes).
I couldn't make Fast Seek Restore from Lone-Tar work on the REV, so they'll
have to tell us if it is supposed to, or whether they still have to read
through the entire medium to get to the files / directories to be restored.
4) If you are a command-line writer, you'll want to note that BackupEDGE is
fully coupled for all media types. In other words...
edge cvf rev0 [files]
will take its que from your default REV device settings and write
directly to the REV, getting volume size, compression, etc. correct.
5) If you are running BackupEDGE on OpenServer 6, UnixWare 7, Linux, etc.
and using Access Control Lists (ACLs), BackupEDGE understands how to
archive and restore them.
6) The performance of our compressor is far higher both in compression ratio
and speed than the legacy Lone-Tar compressor, and far higher in speed
than their new bzip2 compressor, although it is a small percentage lower
in compression ratio than bzip2. We examined bzip2 (and other technologies)
three years ago when we replaced our compressor, but found it far too
slow to be useful in a day-to-day production backup environment. We
settled on ZLIB compression. It's balance of speed and compression ratio
is very well suited for backup, and we make all nine levels available
for users to tune.
Bzip2 is great for compressing files for things like internet downloads,
where it doesn't matter how long it takes to compress, since it is only
being done once, and the bandwidth savings are great. It is also great
for that one time when you have to compress as much as possible to fit
on a CD.
We also don't require any temporary disk space, as Lone-Tar does. This both
wastes space (which you may not have) and slows performance. If you compress
large files to REV with Lone-Tar and watch the drive, it simply shuts down
for long periods of time while the program is compressing to the temporary
file.
6) BackupEDGE fully supports the REV 1000 SCSI autoloader, including random
slot access and access by barcode label.
7) BackupEDGE fully supports the REV 280 USB autoloader on Linux. Supporting
it under OSR5, OSR6 and UW7 requires SCO to fix a small driver issue. We
have reported it and are waiting for the fixes.
So BackupEDGE has "the other 90% of the work", including...
- Media detection and preparation
- Volume Size detection
- performance optimization
- data format
- error checking
- "Instant File Restore"
- support for ALL REV technologies
to make REV technology a truly useful storage technology. It is DESIGNED
to fail when it encounters a problem. Any problem. Write or read.
> Also technical support is more user
> friendly, you talk to the main programmer the first time you talk to
> someone. Don't need to escalate to the next level.
Their programmer is also their tech support person? Oh, my. I' rather have
engineers programming and support people supporting, unless an escalation
is required. Most of day-to-day support does not require an engineer and
would keep he/she from doing what they are paid for.
> Just my 2 cents.
Yeah ;-)
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
Bill Vermillion
Just a couple of comments on two paragraphs - wjv.
In article <2006071316...@mlite.microlite.com>,
D. Thomas Podnar <t...@microlite.com> wrote:
>Enrique Arredondo <a...@sbcglobal.net> said...
>> I think BackupEdge is crap with REV drives (too many bad experiences)....
>> Get LoneTar instead. It's flawless with REV drives. Download a trial
>> version and you'll see what I mean. Also technical support is more user
>> friendly, you talk to the main programmer the first time you talk to
>> someone. Don't need to escalate to the next level. Just my 2 cents.
>Mr. Arredondo.
>I normally ignore this kind of stuff. Responding properly requires pointing out
>to a potential client that they might be wrong about something, and to talk
>about someone else's product in a less-than glowing fasion. Neither are my
>favorite things to do.
....
>BackupEDGE actually ASKS THE MEDIA how many raw blocks are available, applies
>the appropriate mmc-recommended formula, and calculates a reliable volume size. It does this on a PER-MEDIA basis during a backup.
>This is even more important when using CD/DVD media, where
>BackupEDGE detects media type, write strategy, preparation
>strategy and volume size on a per media basis. A multi-volume
>backup can actually have a DVD+R dual layer as volume 1, CD-RW
>as volume 2, DVD+RW as volume 3, and an 8cm 200MB CD-R as volume
>4, or any other combination of supported media. It will get
>everything right, including preparing and finishing the media (if
>necessary) and setting each volume size to the maximum usable
>space. No least-common denominators that waste space, and no
>knowledge on the part of the end-user required.
Now that is SLICK. So many things - not just computers - get
lockked in on what the first media is.
>1) The BackupEDGE data format includes full-file error
>checksumming, not just header checksumming like Lone-Tar. This is
>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.
Or did you mean something else when you said "full-file error
checksumming" ? If so, my apologies.
And even with devices that have built-in error checking I'd still
always go for a bit-level. I can envision some starnge happening
where the date becomes courrupt from the time it is read from the
disk and before it hits the tape drive. Then the tape-drive
will perform error checking against the corrupt data. This
could/should be extrememly rare. And the reverse should also be
true on a restore. Run a bit level to make sure the restored
data matches what is on the tape.
The only time I had probelms with any backup program was
a version of Ctar which was disabled after running a year.
I called Ctar and talked with (probably) Steve, and he said that
was done because the dealer who installed that was suspected of
bootlegging material. Now THAT was true, but about the only piece
that was not bootlegged was the CTAR. At that point the owner
decided the competitive upgrade to BackupEdge was the best way to
go. That was on a Xenix system back in 1990. They have been
upgrading it through changes from Xenix thru a couple of SCO
versions to their current Suse platform - and also have a support
contract in case they can't get in touch with me to fix a problem.
That's 16 years from a very happy customer. They just keep getting
bigger, and have now outgrown their second main building.
With data you can't be too sure if you business depends upon it.
Bill
--
Bill Vermillion - bv @ wjv . com
Enrique Arredondo
I liked your product with DAT tapes but now in my case it didn't worked.
[snip]
> pent two weeks working to help you, even though the Dell web site
> CLEARLY STATES...
>
> "NOTE: The PERC 4/Di/Si and 4e/Di/Si RAID controllers support
> hard disk drives only; they do not support CD-ROMs, tape drives,
> tape libraries, or scanners."
>
> Dell Reference:
> http://support.dell.com/support/edocs/storage/RAID/perc4e/en/ug/chap1.htm?c=us&l=en&cs=04&s=bsd
>
Lonetar worked out of the box even that DELL denies the posibility of that
task.
> So even though Dell says DON'T DO THIS (the REV has a CD-ROM-type BIOS)
> you still thought it was a good thing to do. We tried to help.
>
> Lone-Tar is MUCH less sophisticated in its REV error handling than
> BackupEDGE,
> and I eventually made a decision to stop spending engineering time trying
> to
> support a host adapter that that the manufacture says a REV should never
> be
> plugged into.
>
>
>> Get LoneTar instead. It's flawless with REV drives.
>
> Let's examine that statement. I'll have to, in order to justify what I
> said in my last paragraph, won't I?
>
[ snip ]
The bottom line is that I didn't spend more than 3 minutes of my time after
I downloaded Lonetar (versus 2 weeks of frustating time with backupedge ,
which it never worked out anyways). Since using Lonetar ,my REV BACKUP has
been working flawlessly every single day for almost a year. And I'm not
using the most recent version from Lonetar. It's version 4.05. The new
release has more features than the one I currently use.
For me , the product worked the first time I tried and I'm very happy with
it. When I needed help, I want to talk to a tech rep that has my level of
knowledge and not a waste my time or your time talking to a low level Tech
support rep for 2 weeks so then the escalate the call to a "higher" level.
Thanks for your analisys.
SCO + LONETAR + REV drives + DELL PERC4 = The best choice for me.
Mr. Arredondo
D. Thomas Podnar
: >checksumming, not just header checksumming like Lone-Tar. This is
: >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.
:
: Or did you mean something else when you said "full-file error
: checksumming" ? If so, my apologies.
That's a bit-level detection. Once the file actually changes on the
hard drive, i.e. its time stamp changes, you'll ignore difference because
the file is assumed to have realy changed.
Archives consist of:
- File Header (pathname, length, permissions bits, etc.)
- Data (actual contents of the file)
- File Header
- Data
etc.
Lone-Tar calculates and adds a checksum (bit/byte) only on the 512 byte file
header. It does this whether or not a Bit-Level-Verify is also selected.
BackupEDGE also checksums the actual DATA, This gives us the ability to:
- Verify an archive's integrity at other times, not just the bit
level verify at the time of the backup.
- Verify the read integrity of a file that is ignored during bit
level verify because its contents have changed between backup
and verify.
- Report during if a restore (perhaps years later) if an error
causes the stored checksum not to match the checksum calculated
during the restore.
: And even with devices that have built-in error checking I'd still
: always go for a bit-level. I can envision some starnge happening
: where the date becomes courrupt from the time it is read from the
: disk and before it hits the tape drive. Then the tape-drive
: will perform error checking against the corrupt data. This
: could/should be extrememly rare. And the reverse should also be
: true on a restore. Run a bit level to make sure the restored
: data matches what is on the tape.
We are BIG fans of full bit level verify and it continues to be the default in
our products (along with the checksum verify). But when you are restoring from
newer devices (or from a nework) and don't have the advantage of the ECC
correction built into tape drives, you need to put something else into the
software that, if not able to correct bad bits, can at least detect them if
the media has degraded.
This is why we added the extra level of protection to the BackupEDGE
format three years ago.
: The only time I had probelms with any backup program was
: a version of Ctar which was disabled after running a year.
:
: I called Ctar and talked with (probably) Steve, and he said that
: was done because the dealer who installed that was suspected of
: bootlegging material. Now THAT was true, but about the only piece
: that was not bootlegged was the CTAR. At that point the owner
: decided the competitive upgrade to BackupEdge was the best way to
: go. That was on a Xenix system back in 1990. They have been
: upgrading it through changes from Xenix thru a couple of SCO
: versions to their current Suse platform - and also have a support
: contract in case they can't get in touch with me to fix a problem.
:
: That's 16 years from a very happy customer. They just keep getting
: bigger, and have now outgrown their second main building.
:
: With data you can't be too sure if you business depends upon it.
:
: Bill
: --
: Bill Vermillion - bv @ wjv . com
Thanks for your continued support, Bill.
Tom Podnar
Microlite
Jeff Hyman
| >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.
# 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.
--------------------------- 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
-------------------------- \( -- | | --------------------------------------
| |
Boyd Lynn Gerber
> 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 use both products. For new customers I have them download both and use
them in their real world enviroment. I insist that all my customers use
some form of backup with bit-level verification. Each customer decides
which is best for their needs. I have been very happy using both of these
products for many years. the competition between them benefits us all. I
think it makes them refine their products.
--
Boyd Gerber <ger...@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
D. Thomas Podnar
: | >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 -;)
Jeff Hyman
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
D. Thomas Podnar
:
: I'm glad I'm here to defend myself.
As am I.
: I would hope you do not do these
: type of tactics on other newsgroups... or anywhere for that matter.
I am on record as saying how much I did NOT enjoy this.
: It's not
: good business... at least for Microlite.
It's not good for anyone. We can agree on that.
: 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.
It seems that some people still think that "BackupEDGE and Lone-Tar
are virtually identical, and the first one that "seems" to work, does.
I felt it necessary to point out that, although they are both storage products,
they are in fact very different. My comments were limited to REV and to
where our exclusive REV technologies absolutely relate to other storage types.
: 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 agree on a lot, most especially the part about when neither product is
being used.
I just don't trust the PERC 4 in this instance. We're issuing all standard
pass-through commands that other host adapters use, and that the PERC 4
shouldn't choke on them. I don't think it is in his best long term interest to
continue to use the REV on that HA, no matter which software product he chooses.
: We all need to work a little
: more "together" as a team weither competition or not.
: Everyone will benefit.
I'm in.
: PS: You owe me a (double) CC and Ginger at SCOforum! :-)
Uh. I'm guessing that is a reference to drink. I don't drink, so I'm lost
there, but whatever it is, I'll buy you a triple!!!
:
: See ya,
: Jeff H
Tom
Bob Rasmussen
> ...
>
> 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: r...@anzio.com
company e-mail: r...@anzio.com
voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
fax: (US) 503-624-0760
web: http://www.anzio.com
Bill Vermillion
One reason I use both is that between them they cover all the
platforms I support [and used to support]. I 'lent' a machine
to Steve on the 'net so he could compile a version for SGI's Irix,
and Lone-Tar also supports FreeBSD. Between the two programs
you can cover almost all Unix machine extant, and at one time
BRU covered those the other two didn't. I don't know muhc about
BRU since it changed hands a few years ago, but I see they
also have Mac OS/X backup programs.
Brian K. White
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 -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
Bela Lubkin
> 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<
Nachman Yaakov Ziskind
> 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 aw...@ziskind.us
Attorney and Counselor-at-Law http://ziskind.us
Economic Group Pension Services http://egps.com
Actuaries and Employee Benefit Consultants
D . Thomas Podnar
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,
--
Joe Chasan
> ...
>
> 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,
> 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.
j...@magnatechonline.com Hicksville, NY - USA
http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
Bill Vermillion
D . Thomas Podnar <t...@microlite.com> 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.
Brian K. White
----- Original Message -----
From: "Bela Lubkin" <fi...@armory.com>
Newsgroups: comp.unix.sco.misc
To: <dis...@jpr.com>
Sent: Friday, July 14, 2006 11:54 AM
Subject: Re: IOMEGA Rev intermittent failures
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.
--
D . Thomas Podnar
>
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 -- br...@aljex.com -- http://www.aljex.com/bkw/
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
>
--
D . Thomas Podnar
> 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.
> j...@magnatechonline.com Hicksville, NY - USA
> http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
Thanks for the feedback. It is appreciated.
D . Thomas Podnar
> [ snip ]
>
>
> The bottom line is that I didn't spend more than 3 minutes of my time after
> I downloaded Lonetar (versus 2 weeks of frustating time with backupedge ,
> which it never worked out anyways). Since using Lonetar ,my REV BACKUP has
> been working flawlessly every single day for almost a year. And I'm not
> using the most recent version from Lonetar. It's version 4.05. The new
> release has more features than the one I currently use.
> For me , the product worked the first time I tried and I'm very happy with
> it.
> When I needed help, I want to talk to a tech rep that has my level of
> knowledge and not a waste my time or your time talking to a low level Tech
> support rep for 2 weeks so then the escalate the call to a "higher" level.
Well we all want that. Fortunately, we have Arnie, who handled your emails.
Arnie has 10 1/2 YEARS in support here at Microlite, and came to us from a
UNIX background where his SCO experience started, as best as he can recall,
in 1989. It is safe to say his SCO expertise, after 17 years, is pretty good.
Also fortunately, we have a pretty good email support tracking system.
According to it, your first email came in late in the day on August 25, 2005
and was escalated to engineering on August 26, 2005 at about noon, where we
spent a few weeks analyzing your problem, compiling and sending different
versions of our REV writer, and moving into direct conversations with
engineering.
Perhaps your last paragraph was rhetorical.
> Thanks for your analisys.
> SCO + LONETAR + REV drives + DELL PERC4 = The best choice for me.
> Mr. Arredondo
I'm very glad it is working for you. I only take exception when blog-style
generalizations instead of facts are used to paint scenarios.
For those of you who have been saved by Arnie many times, you have a chance
to meet him. He'll be joining us on the floor at Forum next month.
Please come by and say hello.
---
Dave Dickerson
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
Enrique Arredondo
"D . Thomas Podnar" <t...@microlite.com> wrote in message
news:2006071418...@mlite.microlite.com...
The worst part was when Arnie told me over the phone.... "You have to go buy
a new SCSI CARD" and I said " Why in the world ? Don't you see it works with
lonetar! you want me to go and spend $1000 on a new card just because you
are sticking with Dell's argument about perc4 (or whatever reason) and just
because of that you are too lazy to try to fix the problem and he just say
yes.". That's what make me leave BE for ever!. Great support ,,, Oh yeah!.
Sure...... Do you keep also track of the phone calls ? Can you listen to it
?
Unbelivable!! 17 years of experience to tell me go buy a card.....
arrrgggggg.
Bob Rasmussen
> The worst part was when Arnie told me over the phone.... "You have to go buy
> a new SCSI CARD" and I said " Why in the world ? Don't you see it works with
> lonetar! you want me to go and spend $1000 on a new card just because you
> are sticking with Dell's argument about perc4 (or whatever reason) and just
> because of that you are too lazy to try to fix the problem and he just say
> yes.". That's what make me leave BE for ever!. Great support ,,, Oh yeah!.
> Sure...... Do you keep also track of the phone calls ? Can you listen to it
> ?
>
> Unbelivable!! 17 years of experience to tell me go buy a card.....
> arrrgggggg.
The way I see it: 17 years of experience to tell you that it is not smart
to trust your backup to a hardware combination that the hardware vendor
doesn't recommend or support. Sounds like good advice.
Enrique Arredondo
"Bob Rasmussen" <r...@anzio.com> wrote in message
news:mailman.5.1153161...@lists.celestial.com...
> On Mon, 17 Jul 2006, Enrique Arredondo wrote:
>
>> The worst part was when Arnie told me over the phone.... "You have to go
>> buy
>> a new SCSI CARD" and I said " Why in the world ? Don't you see it works
>> with
>> lonetar! you want me to go and spend $1000 on a new card just because you
>> are sticking with Dell's argument about perc4 (or whatever reason) and
>> just
>> because of that you are too lazy to try to fix the problem and he just
>> say
>> yes.". That's what make me leave BE for ever!. Great support ,,, Oh
>> yeah!.
>> Sure...... Do you keep also track of the phone calls ? Can you listen to
>> it
>> ?
>>
>> Unbelivable!! 17 years of experience to tell me go buy a card.....
>> arrrgggggg.
>
> The way I see it: 17 years of experience to tell you that it is not smart
> to trust your backup to a hardware combination that the hardware vendor
> doesn't recommend or support. Sounds like good advice.
>
> Regards,
> ....Bob Rasmussen, President, Rasmussen Software, Inc.
>
Hey but, come on.. we're not talking about a 1980's SCSI card
technology..it's a 2005-06 Brand spanking new server with DUAL XEON yada
yada yada with state of the art technology scsi card. And Lonetar is still
working great on it! I was just trying to keep using BE and helping these
guys out to come back with the FIX but who cares now! with that attitude
B.I.H.
Pat Welch
A 1,000 bucks for a PCI SCSI card to drive just a tape drive? Come on.
And even if it were that price. Dell, you know, the MANUFACTURER tells
you NOT to use CD like drives on the PERC channel and you insist on
doing it anyway??
Whats wrong with this picture? Wait - I know - you are counting on the
consulting revenue when a major crash happens. Smart.
--
----------------------------------------------------
Pat Welch, UBB Computer Services, a WCS Affiliate
SCO Authorized Partner
Unix/Linux/Windows/Hardware Sales/Support
(209) 745-1401 Cell: (209) 251-9120
E-mail: pat...@inreach.com
----------------------------------------------------
Brian K. White
----- Original Message -----
From: "Pat Welch" <pat...@comcast.net>
Newsgroups: comp.unix.sco.misc
To: <dis...@jpr.com>
Sent: Tuesday, July 18, 2006 11:28 PM
Subject: Re: IOMEGA Rev intermittent failures
I was going to say something like Bob Rasmussen said.
17 years of experience should have showed him that just because something
seems to work doesn't mean squat.
17 days of experience told me that much.
Let's say it in Seussese:
It does not mean it will work near Duluth.
It does not even mean it works here in truth.
It doesn't mean it will work for me or he or she.
It does not even mean it works for thee.
It does not mean you have found a solution.
It mostly means luck has made an intrusion.
billa
Having followed this thread with interest in all it's convolutions, I
have to inject:
Dell does not have the only SCSI RAID controller system that does not
work correctly under SCO UNIX and even WINDOWS SERVER for some devices.
I bought an IBM Server and the IBM SCSI Tape drive would not work
correctly when attached to the add-in RAID controller, using IBM's
drivers. It also did not work correctly when attached to the single
channel built-in tape controller as long as the add-in RAID controller
card was present. Worked well when I took the add-in RAID controller
card out and attached the tape drive and one hard drive to the built-in
single channel SCSI controller. I put the add-in RAID controller back
in, put in a single channel adaptec SCSI controller that was not in use
at the time, attached the tape drive to the Adaptec controller, and the
tape drive worked properly. Everything has been fine since. I found out
through IBM's support site that several people using the same server for
a WINDOWS server also experienced similar problems, with a similar
solution. The symptom I had with the tape drive was consistent loss of
data during a backup and the backup would stop and hang up sometimes.
Of course, I found out about the loss of data by restoring the backup.
This happened with the tar and cpio backup utilities. Habitually, I
always test with the built-in utilities. Thankfully the problem showed
up early in testing so I never felt that it was working properly.
Of course I complained loudly, but sometimes you just have to bite the
bullet and move on because time's a'wasting.
>
--
William P. Akers E-Mail: bi...@mgmindustries.com
MGM Industries, Inc. Web Site: http://www.mgmindustries.com
Hendersonville TN