<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.6212" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#d4d0c8>
<DIV><FONT face=Arial size=2>If your running on ZFS another alternative is
snapshots with send and recv which should be even more efficient than rsync as
it doesn't need to calculate the changes it just "knows".</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> Regards</FONT></DIV>
<DIV><FONT face=Arial size=2> Steve</FONT></DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=kubicaryan@yahoo.com href="mailto:kubicaryan@yahoo.com">Ryan
Kubica</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=linux@thehobsons.co.uk
href="mailto:linux@thehobsons.co.uk">Simon Hobson</A> ; <A
title=rrd-users@lists.oetiker.ch
href="mailto:rrd-users@lists.oetiker.ch">rrd-users@lists.oetiker.ch</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, July 17, 2012 5:05
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [rrd-users] Incremental
backup rrd file</DIV>
<DIV><BR></DIV>
<DIV
style="FONT-SIZE: 10pt; COLOR: #000; FONT-FAMILY: arial, helvetica, sans-serif; BACKGROUND-COLOR: #fff">
<DIV><SPAN><BR></SPAN></DIV>
<DIV>I'll second all of this about rsync: it's very efficient and 'safe' for
rrd data copies.</DIV>
<DIV><BR></DIV>
<DIV>I don't have backups per-se, I run active mirrored rrd servers with
millions of rrd datafiles per server and if one crashes where I need to
rebuild one or install a new one for hardware upgrade like I'm doing today,
then I use rsync to get a copy from another mirror ... actively. The
replacement-mirror writes behind in the rrd update queue so it's updating
older intervals than the rest of the cluster and then I copy from another
mirror. I'm currently copying 1TB (one terabyte) and it works
beautifully.</DIV>
<DIV><BR></DIV>
<DIV>rsync would take a long time to do backups nightly of that many files
(which is why it's not done); but on a few thousand'ish it can(should!) be
used.</DIV>
<DIV><BR></DIV>
<DIV>If you use rsync over ssh, at least do something like this: rsync -ave
'ssh -c blowfish' src dst</DIV>
<DIV><BR></DIV>
<DIV>I've yet to bother with rsync daemon with no ssh, though that'd be more
efficient as well.</DIV>
<DIV><BR></DIV>
<DIV>-Ryan</DIV>
<DIV><BR></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: arial, helvetica, sans-serif">
<DIV
style="FONT-SIZE: 12pt; FONT-FAMILY: 'times new roman', 'new york', times, serif">
<DIV dir=ltr><FONT face=Arial size=2>
<HR SIZE=1>
<B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Simon Hobson
<linux@thehobsons.co.uk><BR><B><SPAN
style="FONT-WEIGHT: bold">To:</SPAN></B> rrd-users@lists.oetiker.ch
<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, July 17, 2012
4:47 AM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re:
[rrd-users] Incremental backup rrd file<BR></FONT></DIV><BR>Darren Murphy
wrote:<BR>>Just to add a little to this, the --stats & --human-readable
options<BR>>provide useful insight as to the efficiency of
rsync<BR><snip><BR>>So 3121 files totaling 4.3GB in size, and at
least 90% of those files<BR>>would change between successive sync runs, yet
only a very small<BR>>amount of data needs to be transferred.<BR><BR>That
tallies with my experience. Obviously it varies considerably <BR>with the type
of data, but I've yet to find something where it <BR>doesn't show a reduction
in data transferred.<BR>In general, RRD files should 'compress' quite well
(unless you use <BR>very small consolidations).<BR><BR>>I'd also add that
in my experience rsync is incredibly robust and reliable.<BR>>I've been
running an hourly rsync from my main MRTG server to 3<BR>>separate "slaves"
for almost 2 years now, and never once had a problem<BR>>with data
integrity.<BR><BR>I'll second that. And of course, even if the process dies
part way <BR>through, you can just run it again and it will catch
up.<BR><BR>-- <BR>Simon Hobson<BR><BR>Visit
http://www.magpiesnestpublishing.co.uk/ for books by acclaimed<BR>author
Gladys Hobson. Novels - poetry - short stories - ideal as<BR>Christmas
stocking fillers. Some available as
e-books.<BR><BR>_______________________________________________<BR>rrd-users
mailing list<BR><A href="mailto:rrd-users@lists.oetiker.ch"
ymailto="mailto:rrd-users@lists.oetiker.ch">rrd-users@lists.oetiker.ch</A><BR><A
href="https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users"
target=_blank>https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users</A><BR><BR><BR></DIV></DIV></DIV>
<P>
<HR>
<P></P>_______________________________________________<BR>rrd-users mailing
list<BR>rrd-users@lists.oetiker.ch<BR>https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users<BR></BLOCKQUOTE><br>================================================<br>
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. <br>
<br>
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337<br>
or return the E.mail to postmaster@multiplay.co.uk.</BODY></HTML>