In article <42e22077$0$3269$4d4eb98e@read.news.fr.uu.net>,
Steve Houle wrote:

> I had done a "flexbackup" backup on a tape that I can't
>restore. It's look like corrupted.

You trusted *tape* backups?

HAHAHAHAHA!!!

Lawrence D'Oliveiro wrote:
> In article <42e22077$0$3269$4d4eb98e@read.news.fr.uu.net>,
> Steve Houle wrote:
>
>
>> I had done a "flexbackup" backup on a tape that I can't
>>restore. It's look like corrupted.
>
>
> You trusted *tape* backups?
>
> HAHAHAHAHA!!!

Now that is not fair.

With a good tape drive and using good tapes, they are extremely reliable.
And if you use good backup software, you should be pretty much guaranteed
you have a good backup.

I use Exabyte VXA tape drives that are inherently more reliable than many
other types. They are helical scan with four heads. Every other one writes
and the others read, so they read each block immediately after writing to
make sure it is there.

I use BRU for backup, and after it has written a backup tape, it rewinds it
and reads it to make sure it is good (it has written a checksum into each
block, and verifies this on playback). I have never been unable to restore
from one of these tapes. If I use a tape too long (BRU counts the number of
writes), I once in a while get a tape that will not write, but I never got
one I could not read.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 06:45:00 up 43 days, 38 min, 3 users, load average: 4.30, 4.20, 4.01

Lawrence D'Oliveiro wrote:
: In article <42e22077$0$3269$4d4eb98e@read.news.fr.uu.net>,
: Steve Houle wrote:

:> I had done a "flexbackup" backup on a tape that I can't
:>restore. It's look like corrupted.

: You trusted *tape* backups?

You obviously haven't been around long. There's no more reliable
archival media in existence than a good tape.

Stan

--
Stan Bischof ("stan" at the below domain)
www.worldbadminton.com

essteeaenn@worldbadminton.com wrote:
> Lawrence D'Oliveiro wrote: : In
> article <42e22077$0$3269$4d4eb98e@read.news.fr.uu.net>, : Steve Houle
> wrote:
>
> :> I had done a "flexbackup" backup on a tape that I can't
> :>restore. It's look like corrupted.
>
> : You trusted *tape* backups?
>
> You obviously haven't been around long. There's no more reliable archival
> media in existence than a good tape.
>
Not only that, even if you have hot-swappable hard drives, how many hard
drives can you keep in a safe deposit box at the bank? I can put a lot of
Exabyte tapes in the space one hot-swappable hard drive would take.

And if the hard drive to which you back up is not hot swappable, what
happens when lightning strikes or the power supply does a booboo and zaps
both drives, or if the OS goes bezerk and does the same thing?

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 10:00:00 up 43 days, 3:53, 3 users, load average: 4.15, 4.09, 4.08

essteeaenn@worldbadminton.com :


> You obviously haven't been around long. There's no more reliable
> archival media in existence than a good tape.

Wrong. Stones are more reliable. They also hold longer. Example:
You can still read what's been carved in stones thousands of years
ago. But can you still - as easily - read a 20 year old tape?

Alexander Skwar
--
Is it 1974? What's for SUPPER? Can I spend my COLLEGE FUND in one
wild afternoon??

In <11ehe2cqg0rikc5@corp.supernews.com> Jean-David Beyer:

[Snip...]

> Now that is not fair.

That's not the half of it--taking delight in somebody's else troubles and
especially on a tech group is sadistic, IMO. I plonk those sickos.

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
Kids jumping ship? Looking to hire an old-school type? Email me.

Jean-David Beyer wrote:
>
> I use BRU for backup, and after it has written a backup tape, it rewinds it
> and reads it to make sure it is good (it has written a checksum into each
> block, and verifies this on playback).

I, too, use BRU (with VXA tapes) for backup and I think the fact that it
writes a checksum to the tape is a more important feature than many
people realize.

It's fairly easy for any system to verify a tape by rewinding and
comparing the contents of the tape to the content on disk immediately
after the backup completes. But that method assumes that nothing
on-disk changed during the backup and means that the verification can be
done only immediately after the backup. Any system that writes a
checksum to the tape can verify that the contents of the tape are still
good *at any time*. You can come back a month or a year later and still
be able to verify that the tape has your data on it, unchanged from the
way it was written.

On Thu, 28 Jul 2005 06:49:47 -0400, Jean-David Beyer wrote:

> Lawrence D'Oliveiro wrote:
>> In article <42e22077$0$3269$4d4eb98e@read.news.fr.uu.net>,
>> Steve Houle wrote:
>>
>>
>>> I had done a "flexbackup" backup on a tape that I can't
>>>restore. It's look like corrupted.
>>
>>
>> You trusted *tape* backups?
>>
>> HAHAHAHAHA!!!
>
> Now that is not fair.

Not only is it not fair... it's stupid.

Always get tape.

--
"Blessed is he who expects nothing, for he shall never be disappointed."
Benjamin Franklin (I didn't know he was a Buddhist)

Ivan Marsh wrote:
> On Thu, 28 Jul 2005 06:49:47 -0400, Jean-David Beyer wrote:
>
>
>>Lawrence D'Oliveiro wrote:
>>
>>>In article <42e22077$0$3269$4d4eb98e@read.news.fr.uu.net>,
>>> Steve Houle wrote:
>>>
>>>
>>>
>>>> I had done a "flexbackup" backup on a tape that I can't
>>>>restore. It's look like corrupted.
>>>
>>>
>>>You trusted *tape* backups?
>>>
>>>HAHAHAHAHA!!!
>>
>>Now that is not fair.
>
>
> Not only is it not fair... it's stupid.

Possibly the scoffer has suffered from bad experiences with floppy tapes,
DDS-2 tapes, and similar infernal devices masquerading as tape drives. A
pity, since some tape drives are well designed, well manufactured, and work
very well indeed.
>
> Always get tape.
>


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 12:40:00 up 43 days, 6:33, 3 users, load average: 4.27, 4.26, 4.20

On Thu, 28 Jul 2005 12:41:53 -0400, Jean-David Beyer wrote:

> Ivan Marsh wrote:
>> On Thu, 28 Jul 2005 06:49:47 -0400, Jean-David Beyer wrote:
>>>Lawrence D'Oliveiro wrote:
>>>>In article <42e22077$0$3269$4d4eb98e@read.news.fr.uu.net>,
>>>> Steve Houle wrote:
>>>>
>>>>> I had done a "flexbackup" backup on a tape that I can't
>>>>>restore. It's look like corrupted.
>>>>
>>>>You trusted *tape* backups?
>>>>
>>>>HAHAHAHAHA!!!
>>>
>>>Now that is not fair.
>>
>> Not only is it not fair... it's stupid.
>>
>> Always get tape.
>>
> Possibly the scoffer has suffered from bad experiences with floppy
> tapes, DDS-2 tapes, and similar infernal devices masquerading as tape
> drives. A pity, since some tape drives are well designed, well
> manufactured, and work very well indeed.

That may very well be... but I'll take even a slightly useful tape backup
on the worst of drives over a complete loss of data any time.

An example from my experience:

We had an HP LF server with a RAID5 array in it. A lot of people, these
days, seem to think if you have RAID you don't need tape backups.

The server had been running for months without issue... then one of the
drives began to fail. No problem, pop in a new drive, let it sync up and
you're good to go right?

Except that the RAID controller in this particular server had a bug in
it's firmware... when the new drive was installed it started striping the
data from the new, blank drive across the entire array.

If we had no tape we would have had no data.

Never trust any hardware and always get tape.

--
"Blessed is he who expects nothing, for he shall never be disappointed."
Benjamin Franklin (I didn't know he was a Buddhist)

John-Paul Stewart writes:
> It's fairly easy for any system to verify a tape by rewinding and
> comparing the contents of the tape to the content on disk immediately
> after the backup completes. But that method assumes that nothing on-disk
> changed during the backup and means that the verification can be done
> only immediately after the backup.

That seems silly. Just compute a checksum as you write the tape, save it,
read back the tape, compute another checksum, and compare the two for
verification.

> Any system that writes a checksum to the tape can verify that the
> contents of the tape are still good *at any time*.

Having done the above, it seems even sillier not to write the verified
checksum to the tape.
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

John Hasler wrote:
> John-Paul Stewart writes:
>
>>It's fairly easy for any system to verify a tape by rewinding and
>>comparing the contents of the tape to the content on disk immediately
>>after the backup completes. But that method assumes that nothing on-disk
>>changed during the backup and means that the verification can be done
>>only immediately after the backup.
>
>
> That seems silly. Just compute a checksum as you write the tape, save it,
> read back the tape, compute another checksum, and compare the two for
> verification.
>
If you write a file to tape with its checksum, and the checksum does not
compare when you want to restore, you lose the file. What the VXA drives do
is write a checksum (actually, lateral, longitudinal, and diagonal
checksums) on every block written to tape. Mine is configured to write
65536-byte blocks, and since it does a read after write check of each block
immediately when writing, if that fails, it can re-write the block later on
the tape and overcome the error that way. And BRU checksums every file and
it checks those checksums when it goes through the automatic verify after
writing a backup, anytime you ask it to, and when you try to read the tapes.
>
>>Any system that writes a checksum to the tape can verify that the
>>contents of the tape are still good *at any time*.
>
>
> Having done the above, it seems even sillier not to write the verified
> checksum to the tape.


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 14:15:00 up 43 days, 8:08, 3 users, load average: 4.23, 4.31, 4.24

In article ,
jpstewart@binaryfoundry.ca says...
> I, too, use BRU (with VXA tapes) for backup and I think the fact that it
> writes a checksum to the tape is a more important feature than many
> people realize.

Actually, any tape works as long as the backup supports a full verify
mode and generates a report that shows the failed items.

And I agree with most of the others, tape is the best method for a real
backup.

We do our servers using a backup of the OS and User drives to another
large drive and then backup the backup drive to tape - this means we get
a quicker back of OS/Data, have one on disk that we can restore from
quickly, and also have a tape backup that can run during the day without
impacting system performance.

--

spam999free@rrohio.com
remove 999 in order to email me

In article <11ei2mi1juoq349@corp.supernews.com>, jdbeyer@exit109.com
says...
> Possibly the scoffer has suffered from bad experiences with floppy tapes,
> DDS-2 tapes, and similar infernal devices masquerading as tape drives. A
> pity, since some tape drives are well designed, well manufactured, and work
> very well indeed.

Funny, I have DDS2,3,4 and LTO and AIT tape drives in servers. My oldest
DDS2 drive is more than 10 years old and still does nightly backups that
still work and restore fine.

--

spam999free@rrohio.com
remove 999 in order to email me

John Hasler wrote:
> John-Paul Stewart writes:
>
>>It's fairly easy for any system to verify a tape by rewinding and
>>comparing the contents of the tape to the content on disk immediately
>>after the backup completes. But that method assumes that nothing on-disk
>>changed during the backup and means that the verification can be done
>>only immediately after the backup.
>
>
> That seems silly. Just compute a checksum as you write the tape, save it,
> read back the tape, compute another checksum, and compare the two for
> verification.

Agreed. But there is (or at least was) lots of low-end backup software
that does the comparison to the original on-disk file. The verification
is done by reading the tape and comparing to the original on-disk file.
(They may use checksums or they may not, but they're comparing tape
data to the file on disk.) After all, many tape drives can't read data
after writing it without rewinding the tape so verification is performed
after the whole thing is written. So if no source checksum was stored,
the only way to compare the tape to anything is to go back to the
on-disk original.

>>Any system that writes a checksum to the tape can verify that the
>>contents of the tape are still good *at any time*.
>
>
> Having done the above, it seems even sillier not to write the verified
> checksum to the tape.

Again, I agree that it would be silly not to write out the checksum.
But some software simply doesn't bother with that.

Leythos wrote:
> In article <11ei2mi1juoq349@corp.supernews.com>, jdbeyer@exit109.com
> says...
>
>>Possibly the scoffer has suffered from bad experiences with floppy tapes,
>>DDS-2 tapes, and similar infernal devices masquerading as tape drives. A
>>pity, since some tape drives are well designed, well manufactured, and work
>>very well indeed.
>
>
> Funny, I have DDS2,3,4 and LTO and AIT tape drives in servers. My oldest
> DDS2 drive is more than 10 years old and still does nightly backups that
> still work and restore fine.
>
I had two H.P. C1599A DDS-2 drives (SCSI) tape drives and they did not work
worth a d@mn. The first one came with the machine and after a few months,
the V.A.Linux Systems replaced it under warranty. A month or so after that,
I sent that one back, too, and they said they were sick and tired of the
H.P. tape drives and would I accept a VXA-1 from Ecrix (now Exabyte) at no
charge instead of getting a third C1599A, and after reading about the
technology, I decided to accept it. It worked so well that when I built my
present main machine, I put a VXA-2 in it.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 15:25:00 up 43 days, 9:18, 3 users, load average: 4.25, 4.22, 4.12

Hi all,

Tape backup systems are quite reliable but can be tricky. I work for a
software engineering company that specializes in backup & disaster
recovery of large information systems. We support government agencies,
universities, and high performance computing centers. As such, I see
failures of all sorts. Some suggestions to the users of tape backup
systems . . . Mirroring tapes is very prudent. The verification step
is important but can not assure you that you won't experience
degradation of the media over time. Also, flaky drives have been known
to damage media and that may be hard to immediately detect/confirm.

Some software packages will be able to work around bad spots on the
media and give you an accurate assessment of what files have not been
restored. Depending upon the package you may be able to recover those
files from previous incrementals on other tapes. My firm has developed
a technology that will take just the daily or differential changes from
a client system after the initial full backup. It reuses data already
in the backup system to produce lower level backups (i.e. weekly's
monthly's semi-annual, and even full backups entirely on the server.
The advantage to this approach is that a failed tape can generally be
reconstructed with other data in the system.

Keeping tapes for a set period of time (you can set your own tape
retension policies and rotate them back into service at a given point)
is also very useful for point in time restores. Periodic full backups
have historically been used to shorten restore times and reduce the
number of tape reads. However, if you experience a bit flip in a given
data set and it goes undetected, then your new full backup will
checksum the corrupted file and assume that all is well. When you
recycle your other tapes you will be essentially throwing out your
valid copy of that file in favor of the corrupted new matrix. A point
in time restore could actually prove more useful than a current
corrupted file.

Mirror some of your tapes, retain some of the mirrors for extended
periods, and consider synthetic backup consolidation technology to
maintain and reuse original file images. Please feel free to visit our
site or contact me with questions. My time monitoring this bbs is
limited and infrequent but I am happy to help.