<?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 to smb share</title>
	<atom:link href="http://www.thelinuxblog.com/rsync-to-smb-share/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.thelinuxblog.com/rsync-to-smb-share/</link>
	<description>The Linux Blog, General Linux, Shell Scripts</description>
	<lastBuildDate>Fri, 03 Feb 2012 06:36:29 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Schedule</title>
		<link>http://www.thelinuxblog.com/rsync-to-smb-share/comment-page-1/#comment-3750</link>
		<dc:creator>Schedule</dc:creator>
		<pubDate>Sat, 30 Oct 2010 04:14:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.thelinuxblog.com/rsync-to-smb-share/#comment-3750</guid>
		<description>Maybe you should make changes to the webpage subject The Linux Blog &#187; rsync to smb share  to  more generic for your subject you create. I loved the the writing all the same.</description>
		<content:encoded><![CDATA[<p>Maybe you should make changes to the webpage subject The Linux Blog &raquo; rsync to smb share  to  more generic for your subject you create. I loved the the writing all the same.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Noah</title>
		<link>http://www.thelinuxblog.com/rsync-to-smb-share/comment-page-1/#comment-2799</link>
		<dc:creator>Noah</dc:creator>
		<pubDate>Wed, 11 Nov 2009 22:21:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.thelinuxblog.com/rsync-to-smb-share/#comment-2799</guid>
		<description>You might, depending on your distribution, need to add &quot;wins&quot; after &quot;dns&quot; in /etc/nsswitch.conf so that the name of the Samba server is resolved.</description>
		<content:encoded><![CDATA[<p>You might, depending on your distribution, need to add &#8220;wins&#8221; after &#8220;dns&#8221; in /etc/nsswitch.conf so that the name of the Samba server is resolved.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Owen</title>
		<link>http://www.thelinuxblog.com/rsync-to-smb-share/comment-page-1/#comment-2540</link>
		<dc:creator>Owen</dc:creator>
		<pubDate>Tue, 21 Jul 2009 15:21:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.thelinuxblog.com/rsync-to-smb-share/#comment-2540</guid>
		<description>@XKY I have never ran into this issue before, have you checked the source and destination files for these files and folders beforehand? I&#039;d assume you have.</description>
		<content:encoded><![CDATA[<p>@XKY I have never ran into this issue before, have you checked the source and destination files for these files and folders beforehand? I&#8217;d assume you have.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: xky</title>
		<link>http://www.thelinuxblog.com/rsync-to-smb-share/comment-page-1/#comment-2523</link>
		<dc:creator>xky</dc:creator>
		<pubDate>Thu, 09 Jul 2009 22:42:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.thelinuxblog.com/rsync-to-smb-share/#comment-2523</guid>
		<description>Hello!
When i do rsync -avz /source/ /dest it kept appearing a lot of hidden files like .abc.pdf.167RAI.

I delete them using the rsync option: --delete-after
And when i rsync again the damn files appears in my drive!

Is this normal?

Thx a lot</description>
		<content:encoded><![CDATA[<p>Hello!<br />
When i do rsync -avz /source/ /dest it kept appearing a lot of hidden files like .abc.pdf.167RAI.</p>
<p>I delete them using the rsync option: &#8211;delete-after<br />
And when i rsync again the damn files appears in my drive!</p>
<p>Is this normal?</p>
<p>Thx a lot</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bubba</title>
		<link>http://www.thelinuxblog.com/rsync-to-smb-share/comment-page-1/#comment-2408</link>
		<dc:creator>Bubba</dc:creator>
		<pubDate>Wed, 10 Jun 2009 16:28:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.thelinuxblog.com/rsync-to-smb-share/#comment-2408</guid>
		<description>I just wanted to drop an update.

This approach has been successful.  We made a couple tweeks.

The target shares were mounted with the &quot;noperm&quot; option.  Initially, CentOS was trying to enforce permissions in a seemly inconsistent way.  By adding noperm, the Windows permissions were inherited properly from those defined for the directory tree by the NAS.

We used SSH as the rsync transport.  We used the High Performance Networking version with encryption disabled.  We use an encrypted VPN, so that&#039;s redundant and performance impacting.

Thanks so much for your feedback.  I&#039;m still surprised I could find a documented solution out there.  This situation can&#039;t be the unique can it?</description>
		<content:encoded><![CDATA[<p>I just wanted to drop an update.</p>
<p>This approach has been successful.  We made a couple tweeks.</p>
<p>The target shares were mounted with the &#8220;noperm&#8221; option.  Initially, CentOS was trying to enforce permissions in a seemly inconsistent way.  By adding noperm, the Windows permissions were inherited properly from those defined for the directory tree by the NAS.</p>
<p>We used SSH as the rsync transport.  We used the High Performance Networking version with encryption disabled.  We use an encrypted VPN, so that&#8217;s redundant and performance impacting.</p>
<p>Thanks so much for your feedback.  I&#8217;m still surprised I could find a documented solution out there.  This situation can&#8217;t be the unique can it?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TheLinuxBlog.com</title>
		<link>http://www.thelinuxblog.com/rsync-to-smb-share/comment-page-1/#comment-2376</link>
		<dc:creator>TheLinuxBlog.com</dc:creator>
		<pubDate>Wed, 27 May 2009 18:08:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.thelinuxblog.com/rsync-to-smb-share/#comment-2376</guid>
		<description>Sounds like a plan, just be sure to check your mail for any rsync failures as you go along. I&#039;ve found it can fail with many small files, especially with SMB.</description>
		<content:encoded><![CDATA[<p>Sounds like a plan, just be sure to check your mail for any rsync failures as you go along. I&#8217;ve found it can fail with many small files, especially with SMB.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bubba</title>
		<link>http://www.thelinuxblog.com/rsync-to-smb-share/comment-page-1/#comment-2375</link>
		<dc:creator>Bubba</dc:creator>
		<pubDate>Wed, 27 May 2009 18:01:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.thelinuxblog.com/rsync-to-smb-share/#comment-2375</guid>
		<description>I left out one important item, there&#039;s a decent amount of latency between the NASes.  Hence, the client/server approach.  Make rsync/rsyncd deal with the latency (and take advantage of compression) not the export/mounted filesystems.  Only do that local to the NAS, so the relatively high overhead of the CIFS/SMB protocal isn&#039;t exacerbated by the latency.

I&#039;ve got two distinct file types in the shares.  One is a relatively large set of small files (a couple K each) in a deep directory tree.  None of these files ever gets deleted (at least not yet).  The other set is fewer larger files (a few MB to a couple hundred MB)that get modified frequently.

I&#039;ll probably run multiple clients, so that I can get more parallelism to overcome the latency, but also to attack the different file sets and different and to run them at offset intervals.</description>
		<content:encoded><![CDATA[<p>I left out one important item, there&#8217;s a decent amount of latency between the NASes.  Hence, the client/server approach.  Make rsync/rsyncd deal with the latency (and take advantage of compression) not the export/mounted filesystems.  Only do that local to the NAS, so the relatively high overhead of the CIFS/SMB protocal isn&#8217;t exacerbated by the latency.</p>
<p>I&#8217;ve got two distinct file types in the shares.  One is a relatively large set of small files (a couple K each) in a deep directory tree.  None of these files ever gets deleted (at least not yet).  The other set is fewer larger files (a few MB to a couple hundred MB)that get modified frequently.</p>
<p>I&#8217;ll probably run multiple clients, so that I can get more parallelism to overcome the latency, but also to attack the different file sets and different and to run them at offset intervals.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Owen</title>
		<link>http://www.thelinuxblog.com/rsync-to-smb-share/comment-page-1/#comment-2374</link>
		<dc:creator>Owen</dc:creator>
		<pubDate>Wed, 27 May 2009 17:18:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.thelinuxblog.com/rsync-to-smb-share/#comment-2374</guid>
		<description>@Bubba

So, you&#039;re trying to mirror two NAS devices.

You probably could do it each way. Mounting both shares on one machine via cifs and then rsyncing them would probably be the easiest. 
If you&#039;re trying to do it for backup purposes you could use the second way by making a local copy from the first NAS then rsync to the second NAS.

Guess you&#039;d have to do it both ways and see which way is quickest and most reliable. I think the second way would probably be quicker since the data would go Server 1 &gt; Local Copy &gt; Server 2 without the traffic of transferring it to Server 2 whilst grabbing it from one. Effectively slowing down the whole process. Full Speed Download Sync &gt; Local &gt; Full Speed Upload Sync seems like it would be faster initially but the remote CIFS mounts might do better once its synced up. Try it with some smaller directories and see if my theory is correct.</description>
		<content:encoded><![CDATA[<p>@Bubba</p>
<p>So, you&#8217;re trying to mirror two NAS devices.</p>
<p>You probably could do it each way. Mounting both shares on one machine via cifs and then rsyncing them would probably be the easiest.<br />
If you&#8217;re trying to do it for backup purposes you could use the second way by making a local copy from the first NAS then rsync to the second NAS.</p>
<p>Guess you&#8217;d have to do it both ways and see which way is quickest and most reliable. I think the second way would probably be quicker since the data would go Server 1 &gt; Local Copy &gt; Server 2 without the traffic of transferring it to Server 2 whilst grabbing it from one. Effectively slowing down the whole process. Full Speed Download Sync &gt; Local &gt; Full Speed Upload Sync seems like it would be faster initially but the remote CIFS mounts might do better once its synced up. Try it with some smaller directories and see if my theory is correct.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bubba</title>
		<link>http://www.thelinuxblog.com/rsync-to-smb-share/comment-page-1/#comment-2373</link>
		<dc:creator>Bubba</dc:creator>
		<pubDate>Wed, 27 May 2009 15:11:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.thelinuxblog.com/rsync-to-smb-share/#comment-2373</guid>
		<description>Any recommendations on mirroring CIFS NAS shares?

I was thinking about mounting both shares via mount.cifs and rsync&#039;ing between them.  Or alternatively client/server rsync&#039;ing between systems each with one of the two volumes mounted.

Am I crazy?

I&#039;ve had trouble with commercial packages that can&#039;t handle lots of files completing syncs in a short period of time.  My NASes are from different vendors, so using vendor specific software is out of the question.</description>
		<content:encoded><![CDATA[<p>Any recommendations on mirroring CIFS NAS shares?</p>
<p>I was thinking about mounting both shares via mount.cifs and rsync&#8217;ing between them.  Or alternatively client/server rsync&#8217;ing between systems each with one of the two volumes mounted.</p>
<p>Am I crazy?</p>
<p>I&#8217;ve had trouble with commercial packages that can&#8217;t handle lots of files completing syncs in a short period of time.  My NASes are from different vendors, so using vendor specific software is out of the question.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: nic</title>
		<link>http://www.thelinuxblog.com/rsync-to-smb-share/comment-page-1/#comment-2208</link>
		<dc:creator>nic</dc:creator>
		<pubDate>Tue, 07 Apr 2009 01:26:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.thelinuxblog.com/rsync-to-smb-share/#comment-2208</guid>
		<description>backuppc seems interesting as it is not tape based. I will try it. Thank you for your help.</description>
		<content:encoded><![CDATA[<p>backuppc seems interesting as it is not tape based. I will try it. Thank you for your help.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

