<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: rsync rocks!</title>
	<atom:link href="http://blog.shwango.com/2005/01/07/rsync-rocks/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.shwango.com/2005/01/07/rsync-rocks/</link>
	<description>life, love and some other stuff...</description>
	<lastBuildDate>Sun, 03 May 2009 17:48:34 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: osterday</title>
		<link>http://blog.shwango.com/2005/01/07/rsync-rocks/comment-page-1/#comment-142</link>
		<dc:creator>osterday</dc:creator>
		<pubDate>Mon, 10 Jan 2005 15:05:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.shwango.com/2005/01/07/rsync-rocks/#comment-142</guid>
		<description>For retension I was just thinking of tarring and gzipping the current backup once a week.  You could then burn it off to CD or DVD or even tape if you wanted and then delete the tgz file.  And for code, developers _should_ be using CVS or Subversion, which would have some of that built in.  (We are planning to use Subversion soon, but aren&#039;t there just yet.)
</description>
		<content:encoded><![CDATA[<p>For retension I was just thinking of tarring and gzipping the current backup once a week.  You could then burn it off to CD or DVD or even tape if you wanted and then delete the tgz file.  And for code, developers _should_ be using CVS or Subversion, which would have some of that built in.  (We are planning to use Subversion soon, but aren&#8217;t there just yet.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Henry</title>
		<link>http://blog.shwango.com/2005/01/07/rsync-rocks/comment-page-1/#comment-141</link>
		<dc:creator>Henry</dc:creator>
		<pubDate>Fri, 07 Jan 2005 20:21:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.shwango.com/2005/01/07/rsync-rocks/#comment-141</guid>
		<description>Thats what I have been telling ya. Rsync does indeed rock. The only issue with using it for backups is retention... If you sync every day, then you only have a retention of one day by definition. One possible solution would be to just have 2 backup sets, one that runs every day and the other that goes once a month or byweekly. Thats still not the best solution because you have to at least double your backup size, and retention varies depending on when in the backup cycle it is when you want to do a restore. Rsync has --backup and --suffix flags that can be set to rename files to be overwritten on teh remote size. By programmatically setting these flags with a perl or bash script when rsync is called, you could achieve unlimited retention and version control all at the same time... I&#039;d like to see a tape system do that!
</description>
		<content:encoded><![CDATA[<p>Thats what I have been telling ya. Rsync does indeed rock. The only issue with using it for backups is retention&#8230; If you sync every day, then you only have a retention of one day by definition. One possible solution would be to just have 2 backup sets, one that runs every day and the other that goes once a month or byweekly. Thats still not the best solution because you have to at least double your backup size, and retention varies depending on when in the backup cycle it is when you want to do a restore. Rsync has &#8211;backup and &#8211;suffix flags that can be set to rename files to be overwritten on teh remote size. By programmatically setting these flags with a perl or bash script when rsync is called, you could achieve unlimited retention and version control all at the same time&#8230; I&#8217;d like to see a tape system do that!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

