<font color="#330033"><font size="2"><font face="verdana,sans-serif">Scott, <br><br>Remember, if you corrupt data, you now have three copies of corrupt data, if you're relying on block-level replication. Same goes for a delete operation. <br>
<br>Having an abstracted copy of the data (crc verified file based, committed transaction log journal, etc, take your pick) that you can recover from is always smart.<br><br>/wasn't able to make the preso, but been down this path before...<br>
<br>-Angelo<br><br><br></font></font></font><br><div class="gmail_quote">On Thu, Mar 24, 2011 at 9:58 AM, Scott Merrill <span dir="ltr"><<a href="mailto:skippy@skippy.net">skippy@skippy.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Mar 24, 2011 at 9:40 AM, Scott Merrill <<a href="mailto:skippy@skippy.net">skippy@skippy.net</a>> wrote:<br>
> I have a couple of questions this morning. Anyone should feel free to<br>
> answer, not just Tom, if you have any insight.<br>
<br>
</div>One more question: since HDFS redundantly stores data blocks in<br>
triplicate, does it make sense to still use traditional backup methods<br>
on data stored in HDFS? If one puts data into HDFS, can one reasonably<br>
rely on the built-in fault-tolerance of the triplicate copies of that<br>
data, or should one still be putting data to tape?<br>
<div><div></div><div class="h5">_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
</div></div></blockquote></div><br>