Corrupted tape backup. - Redhat

This is a discussion on Corrupted tape backup. - Redhat ; Hi, I had done a "flexbackup" backup on a tape that I can't restore. It's look like corrupted. I launch : [root@linux]# flexbackup -extract -num 1 I've got the error : tar: Skipping to next header tar: Archive contains obsolescent ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: Corrupted tape backup.

  1. Corrupted tape backup.

    Hi,

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

    I launch :
    [root@linux]# flexbackup -extract -num 1

    I've got the error :
    tar: Skipping to next header
    tar: Archive contains obsolescent base-64 headers

    gzip: stdin: invalid compressed data--crc error

    gzip: stdin: invalid compressed data--length error
    23+0 records in
    22+0 records out
    tar: Error exit delayed from previous errors
    |------------------------------------------------------------
    At block 25.
    |------------------------------------------------------------

    I had done some search on internet but I majorly got pages talking about
    wrong ftp transfer mode. ASCII instead of BINARY. That really not my
    case, I had done this backup myself on a DLT-IV 35/70 tape on the same
    computer has I try to restore.

    Thanks in advance.

    Steve

  2. Re: Corrupted tape backup.

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

  3. Re: Corrupted tape backup.

    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

  4. Re: Corrupted tape backup.

    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

  5. Re: Corrupted tape backup.

    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

  6. Re: Corrupted tape backup.

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


  7. Re: Corrupted tape backup.

    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.

  8. Re: Corrupted tape backup.

    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.

  9. Re: Corrupted tape backup.

    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)


  10. Re: Corrupted tape backup.

    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

  11. Re: Corrupted tape backup.

    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)


  12. Re: Corrupted tape backup.

    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

  13. Re: Corrupted tape backup.

    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

  14. Re: Corrupted tape backup.

    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

  15. Re: Corrupted tape backup.

    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

  16. Re: Corrupted tape backup.

    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.

  17. Re: Corrupted tape backup.

    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

  18. Re: Corrupted tape backup.

    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.


+ Reply to Thread