<p>Maybe it's just me but using existing well understood tools for each part of a process chain seems far less kludgy to me.<br>
So step one generates the backed up data on maneagable chunks for the proposed output process. Step two prepares that set for storage. Step writes to media.</p>
<p>I HIGHLY recommend looking at a complete backup solution like bacula. The backup is only 1% of the problem. The restore is the only part that matters.</p>
<p>Using power controls on a series of raid10 drives as primary backup storage can greatly extend the drive life. Then using DVD-RW as off-site archival rotation and bare metal recovery of the backup server makes sense to me.</p>
<p>Did I mention bacula has the best documentation of any open source project I have ever seen? And it can send notification emails of status and now has a web gui dashboard for non tech management use.</p>
<p><blockquote type="cite">On Feb 13, 2010 12:52 AM, "Michael B. Trausch" <<a href="mailto:mike@trausch.us">mike@trausch.us</a>> wrote:<br><br><p><font color="#500050">On 02/12/2010 11:58 PM, Brian Pitts wrote:<br>
> I don't object to this feature on any principle. Quite ...</font></p>Actually, my client would prefer to just be told how to run the backup<br>
and have it work every time.<br>
<br>
I prefer not to support kludgey things if I can help it. Hence why I am<br>
trying to figure out how to do this in some neat and easily-supportable<br>
fashion. I don't want to build anything that would make me think of<br>
Rube Goldberg---at least, not for a long term solution. :-P<br>
<br>
If I have to make something kludgey that I have to support for a little<br>
while, I will do that. However, I would like to replace it later with<br>
something more proper. I would be implementing it because I want to,<br>
not necessarily because the client wants it. It would ultimately be to<br>
reduce the crud that I have running on the client's system and to<br>
scratch an itch that I haven't reached in a few years.<br>
<p><font color="#500050"><br> --- Mike<br><br>-- <br>Michael B. Trausch Blog: <a href="http://mike.trausch.us/blog/">http://mike.trausch.us/blog/</a><br>Tel: (404) ...</font></p><p><font color="#500050">Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br><a href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a><br>See JOBS, ANNOUNCE and SCHOOLS...</font></p></blockquote></p>