<div class="gmail_quote">On Mon, Jun 14, 2010 at 9:06 PM, L. V. Lammert <span dir="ltr"><<a href="mailto:lvl@omnitec.net">lvl@omnitec.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Trying to get compression working on one of our backup jobs, .. but it<br>
seems to be choking as soon as I add the --compress:<br>
<br>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> The backup DOES work<br>
without compression, but it ran a week [plain DSL] without completing the<br>
bacukp (it DID get about 40GB), so the only way to get a snapshot is to<br>
get compression working.<br></blockquote><div><br><br>Some people have already replied to say to increase verbosity. For the record, rsync takes the -v option to add verbose output, -vv is more verbose and -vvv is more yet. Not sure if more than three v's changes anything. <br>
</div></div><br>For creating the initial snapshot I'd personally NOT recommend rsync. It uses more resources than other systems if you just want to transfer a big chunk of data. (it's meant to do more complex things)<br>
<br>As a matter of fact, I've not found anything that can transfer many files faster than one large file. Therefore if you've got disk space to spare I'd tar + bzip the initial sync, copy it with sftp and then use rsync on subsequent copies.<br>
<br>Also, don't underestimate the bandwidth of fedex. You can ship a 1 TB drive over night for $10. The latency is high but no DSL line is going to give you that kind of throughput.<br clear="all"><br>-- <br>Matthew Nuzum<br>
newz2000 on freenode, skype, linkedin, <a href="http://identi.ca">identi.ca</a> and twitter<br><br>"Do not seek to follow in the footsteps of the wise. Seek what they sought." –Matsuo Bashō<br>