Re: [opensuse] Backup Question



Per Jessen wrote:
Carlos E. R. wrote:


On Friday, 2009-09-11 at 07:43 +0200, Per Jessen wrote:


Carlos E. R. wrote:


Which means that if the compression/decompression fails, it may
corrupt the entire backup. I don't trust compressed tars for
backups.

I think the way to look at that is:

a) if the compression fails, the tar'ing will fail, therefore your
backup will fail.
b) if the compression fails, you've got other things to worry about
than a missing backup.

It can fail silently, so that the user doesn't notice unless he tries
a test recover as part of the backup procedure.


That is only a variation of (b) above - if you can't trust your backup
procedure, a missing backup not your primary problem.


Or, the backup media can fail (read error) several months later when
you need to do a recovery. Even if that error only affects a few
bytes, you can loose the entire tar.


It's really just another variation of (b) - the backup media or the
physical storage location is not safe/trustworthy.


/Per


Actually that last point is valid. You should never ever actually trust
a tape.
Buy good tapes, buy good tape drives, keep the tape drive cleaned and
don't mistreat the tapes, use bit-level verification** during backus,
And despite all that _still_ never actually depend on any single tape.
Because the fact is there is no such thing as any mechanical magnetic
media that is really dependable, and tape is among the worst, even
though there is nothing better.
You have to make many tapes and constantly monitor the backup/verify
summary reports, and cycle out old tapes before they start failing, and
still you need to just be prepared that when you need to restore, maybe
the most recent tape won't be good and you'll be restoring from a day or
more earlier. And if you have incrimental tapes and the most recent
master is bad, maybe you'll be restoing from weeks in the past.
That's just the way it is.

Given that, if your backup/restore program can't skip over errors in
media where the data is compressed, then it's exceedingly valid to avoid
using compression, because it could be the difference between a 2 week
old restore, or a 1 hour old restore with a single random file somewhere
on the system that is either missing or has a few bytes of corruption
that can probably be dealt with easily and even save that whole file
minus one database record or something.

However, good backups software _can_ skip over media errors even with
compression. You lose a little more data since you lose the whole block
that had the error, which may contain several small files or a good size
chunk of a single larger file, and you may lose that entire larger file
instead of a piece of it.

Also, tape drives have compression in hardware that's turned on by
default anyways, so you don't gain much by doing your own software
compression. If you've got the cpu to burn it can do a better job by
being smarter about only bothering to compress stuff that will compress
and not bothering to try to compress zip tgz bz2 png jpg etc etc etc files.

All that said, I use compression. It would be wildly impractical not to.
Use raid, to reduce your chances of even needing to ever restore from a
backup in the first place, use multiple backups like another copy
maintained by rsync on some remote server to again reduce your chances
of ever needing to restore from a tape, use good hardware & software to
reduce your chances of having a problem the day you do have to restore
from tape. And go ahead and use compression so that you can actually do
full backups every night and so that you can even _affford_ a tape drive
and data channel subsystem that handle the job in a reasonable amount of
time each night.

I think it's silly and causes you more pain and loss and risk than what
you are attempting to avoid by not using compression, but, the point
about media errors IS valid even with the best technology available, and
the point about the special anti-synergy of media errors in concert with
compression, IS valid.

**(means the backup program actually reads the entire tape back after
writing and compares it to the disk, because you physically can't know
that the tape media accepted the write until you actually read it back.)

--
bkw

--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

Relevant Pages

  • Re: Adaptec 1542C with NT4
    ... Today I restored NTBackup from WinNT 3.1 and WinNT 3.5 installations. ... Backup made backups. ... Is it possible that the tape drive has been changed or had hardware ... hardware compression.) ...
    (comp.periphs.scsi)
  • Re: SBS backupwizard & hardware compression
    ... compression feature that one is not automatically being set. ... It's a Dell server and the tape drive is ... with manual jobs just not the wizard. ... > if your tape backup device has hardware compression, ...
    (microsoft.public.windows.server.sbs)
  • Re: SBS Backup failures
    ... and your tape manufacturer lies about the capacity of tape. ... MAXIMUM compression ratio to be achieved by the technology. ... Backup device is internal SCSI HP 36/72 DAT ... Will enumerate on 3 media libraries found. ...
    (microsoft.public.windows.server.sbs)
  • Re: SBS2003 Backup Probs - Still
    ... Compression should be done by the hardware, ... Les Connor [SBS Community Member] ... try a small manual backup on each>> tape first. ...
    (microsoft.public.windows.server.sbs)
  • Re: HP USB 2.0 Tape Drive
    ... I like the LTO tape system. ... It is missing a fast file search ability, ... A backup not readable is NOT a backup. ... your hard disks will fail. ...
    (freebsd-questions)