Mailinglist Archive: opensuse (1702 mails)
|< Previous||Next >|
Re: [opensuse] Backup Question
- From: "Brian K. White" <brian@xxxxxxxxx>
- Date: Mon, 14 Sep 2009 11:36:09 -0400
- Message-id: <4AAE62E9.9030505@xxxxxxxxx>
Per Jessen wrote:
Carlos E. R. wrote:
On Friday, 2009-09-11 at 07:43 +0200, Per Jessen wrote:
Carlos E. R. wrote:
It can fail silently, so that the user doesn't notice unless he triesWhich means that if the compression/decompression fails, it mayI think the way to look at that is:
corrupt the entire backup. I don't trust compressed tars for
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.
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.
Actually that last point is valid. You should never ever actually trust
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.)
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
|< Previous||Next >|