<br><br><div class="gmail_quote">On Sat, Feb 13, 2010 at 1:50 PM, Michael B. Trausch <span dir="ltr"><<a href="mailto:mike@trausch.us">mike@trausch.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 02/13/2010 09:47 AM, Jim Kinney wrote:<br>
> Maybe it's just me but using existing well understood tools for each<br>
> part of a process chain seems far less kludgy to me.<br>
<br>
</div>Which is why I'd like to use tar---it's well-known, well-understood,<br>
portable (enough), and media that houses direct tar archives (be that<br>
floppy, tape, or optical disc) is readable on every UNIX and UNIX-like<br>
system that I know of. In theory optical media without a filesystem and<br>
with a tar on it should be readable on any UNIX unless it does something<br>
stupid like do filesystem interpretation on the device node itself,<br>
which I should think is against the UNIX philosophy anyway. But for the<br>
systems that matter in every practical situation I've encountered in the<br>
last five years, direct tar on optical disc works perfectly fine---and<br>
then restoration doesn't even require root privilege on the server if<br>
users can "tar xf /dev/sr0 some-important-file.txt" or so.<br>
<div class="im"><br>
> So step one generates the backed up data on maneagable chunks for the<br>
> proposed output process. Step two prepares that set for storage. Step<br>
> writes to media.<br>
><br>
> I HIGHLY recommend looking at a complete backup solution like bacula.<br>
> The backup is only 1% of the problem. The restore is the only part that<br>
</div>> matters.R<br>
<br>
I agree with you 100%. That's why I find it insanely easy to be able to<br>
treat an optical disc like a tape. Then, knowledge of tapes transfers<br>
over, and if $CLIENT decides that they'll actually wind up using tapes<br>
at some point, the same tools can be used without modification---the<br>
only difference then is that you're swapping tapes, not discs.<br>
<div class="im"><br>
> Using power controls on a series of raid10 drives as primary backup<br>
> storage can greatly extend the drive life. Then using DVD-RW as off-site<br>
> archival rotation and bare metal recovery of the backup server makes<br>
> sense to me.<br>
<br>
</div>I can't say that I'd ever consider using RAID anything as a means of<br>
backup---just as a means to know when to drop a new drive into the<br>
system. Maybe I'm nuts, but I don't consider a backup to be a backup if<br>
it's still in the same system. I of course also do not consider any<br>
backup plan to be complete without off-site backups being part of the<br>
deal, but I'd never call RAID a backup of any means. It's just a means<br>
to prevent immediate loss due to drive failure(s).<br></blockquote><div><br>The raid 10 is an intermediate storage medium for processing the tarballs into iso images. In enterprise terms it's called "nearline backup" as it must be somewhat processed to regain access (i.e. un-tar, un-bzip2). It _is_possible to burn optical media on the fly from a data stream but the failure rate is pretty high. <br>
<br>Comment # 2: never underestimate the ability of the office staff to screw up the back up process. Any time the media requires a change, the opportunity for failure increases close to exponentially. A pair 1TB eSATA drives that get rotated is WAY better than a set of DVD-RW's that must be changed out. My most recent "IT MUST RUN" system has 2 drives internally + one external eSATA - 2 internal in hardware RAID1 and a software RAID1 with the external. The entire drive system is resynced nightly over compressed ssh up a 512kbps T1 to a remote system with it's own external eSATA drive. The main system can boot from the eSATA. The one ugly part is the obnoxious 8-port serial card of which there is a spare. If the entire main box fails, the remote backup system can be brought in and used to replace the main in under an hour as both systems support booting from the eSATA. <br>
<br>Yes this did require some file blocks on rsync to not mess up the remote systems /etc/fstab settings to use the remote eSATA drive UUID, etc.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> Did I mention bacula has the best documentation of any open source<br>
> project I have ever seen? And it can send notification emails of status<br>
> and now has a web gui dashboard for non tech management use.<br>
<br>
</div>I'll take a look at it. But still, for somewhat simple setups, I think<br>
that a "backup management system" might be overkill. It's like saying,<br>
"Hey, let's use Nagios to monitor this single system on a network of<br>
five nodes," when all you really need to do is know, "It's down," and<br>
have a plan for being back up in 10 minutes or less.<br>
<div class="im"><br>
--- Mike<br>
<br>
--<br>
Michael B. Trausch Blog: <a href="http://mike.trausch.us/blog/" target="_blank">http://mike.trausch.us/blog/</a><br>
</div><div class="im">Tel: (404) 592-5746 x1 Email: <a href="mailto:mike@trausch.us">mike@trausch.us</a><br>
_______________________________________________<br>
</div><div class="im">Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
</div>See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<div><div></div><div class="h5"><a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III<br>Actively in pursuit of Life, Liberty and Happiness <br><br>