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@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org