On Thu, 13 May 1999, Francisco Jose Montilla wrote:
>
> Hi,
>
> First, I apologize for the "little" offtopic. But I, like most of
> you (if not you weren't on this list :) care for the redundancy of my
> important data.
>
> Raids protects against disk failure, UPS against power failure, and
> backups (scsi-data-corrupters controllers apart) against whatever Murphy
> decides to try on you/your data. Backups are important an essential to me,
> and guess that also for you...
>
> I've been trying (commercial and not-commercial) different backup
> systems for a while, and came across this conclusions, please let me know
> if you disagree:
>
> - Backup software must be simple, efficient and reliable.
But complex,slow and undependable means that you will have more work
supporting the product. "The key to job security is product obscurity" It
works for microsoft;)
> - GUIs use to introduce at least 80% of the bugs software has.
A GUI is usefull. It should only be an adjunct to the real program though.
The Idea of a GUI sould be to make what you do 90% of the time easy.
> - The simpler the software, the lesser chances to have problems,
> eg. that f*!?ing lib that make trouble among others you're suffering
> right now, (you're restoring, arent you?) now that i _have_ to restore
> "nooow!" -helps your boss "aaaargh!" -histerize your users...
Simple reliable modular design is allways better but sometimes not
achieveable.
>
> So I assume:
>
> - Data (that minds) storage is centralized. No need to work
> cross-platform on backup; the other platforms have worked already with the
> server to store data on it. So let the server to backup its data without
> introducing the complexity and chances to problems that streaming data
> across networks may introduce.
This will not allways work. If you have several servers to backup you may
want to a central backup server.
> - If not, better use wide open, extensively tested
> software/protocols (eg. samba) to work with other platforms.
>
> In fact, keep at least backup schemes simple.
>
> That guides me to use simple software: tar, find, cpio, afio,
> mt, dump... etc.
tar,find,cpio... are often not up to the job of backing up large systems.
I have written a package to provide incremental bakup for a 100TByte
application. It was not easy and I think I would approach the problem
differently if I were to do it again. But it can be done.
> My question is: what combination of their use do you think is
> better? more reliable? simpler?
>
> If using only tar, chances are that if a spot makes a tape segment
> unusable, you've losed that volume, so better mix it with a block archiver
> (bzip2?) or use cpio, afio, etc.
>
Tar if I remember correctly will do block compression now so that you will
not lose a whole tape if you have a bad block.
> so, which are your experiences?
There are a number of OpenSource and commercial backup packages availble.
I have had only bad luck with the packages that were written for Novell/NT
and then ported to unix. A number of the OpenSource solutions are ok for
backups of moderate size and simplicity. Now I have not tried all the
backup software out there and would not claim to write the last word on
the quality of backup packages. But having said that I found a package
called Arkeia that seems to be robust and fast for backing up a cluster of
systems. It has a feature that really turns my crank and I have never seen
in another backup package. This feature allows you to take the
standard-out from a program and back that up. This means that you can
write a simple program that will dump your database in any format you
want and have that directly placed on tape. This saves having to create
temp files and backing up them. This can be extreemly usefull where the
database is much bigger than the temporary file space.
These are only my opinions though.
Alvin Starr || voice: (416)585-9971
Interlink Connectivity || fax: (416)585-9974
[EMAIL PROTECTED] ||
