preserving Mac OS X metadata in rsync backups and restores

Moritz Heckscher moritz.heckscher at
Sat Jan 19 03:39:59 GMT 2008

Am 2008-01-19 um 03:11 schrieb Matt McCutchen:
> On Fri, 2008-01-18 at 17:14 +0100, Moritz Heckscher wrote:
>> Another problem I'm thinking about is that rsnapshot should be run on
>> the server to "pull" the backups over the network. One cannot run it
>> on the clients and "push" the data to the server over the network --
>> which is what I'd prefer because I plan to not leave the server on
>> all day but rather have it woken up by the (laptop) clients when
>> needed who'll take care of the scheduling of the backups (using
>> anachron or launchd etc.) One could, however, run rsnapshot on the
>> clients to backup onto a locally attached storage device.
> I would like to dispel once and for all the myth that rsnapshot cannot
> be used with a push.  While it is /designed/ to pull backups, with  
> a few
> extra steps one can push a backup to an rsnapshot installation on
> another machine.  I outlined the setup here:

Good news indeed (for me at least)! Having read this FAQ on the  
rsnapshot page in an early stage, without having much background info  
about rsync and rsnapshot myself, I thought it was best to abandon  
the idea of pushed backups with rsnapshot altogether:

Q: Can I set the snapshot_root to a remote SSH path? I want to push  
my backups to a remote server, rather than pull them from a remote  

A: Currently this is not possible. This would be a nice feature, but  
several questions remain unanswered:
* How can the integrity of the snapshot root be guaranteed if one or  
more remote servers have write access to it?
* When snapshots are rotated, which of the potentially several remote  
servers connecting is responsible for performing this task?
* One possibility is to have a "staging" area for files to be  
transferred to, then have rsnapshot sync from this staging area into  
the snapshot root. Can this be accomplished without taking up double  
the disk space?

Your suggestion does indeed take care of the "doubled disk space"  
issue nicely. It's only really possible with your very recent patch  
regarding the --no-tweak-hlinked option, so maybe now this FAQ entry  
could be update with the above link to your description! (By the way,  
would this always remain a patch or eventually go into the normal  

Regarding the other two points: If I have several clients, I guess I  
should have several independent deamons, each with "max connections"  
set to 1, and several independent "incoming" and "snapshots"  
directories, to avoid conflicts:


Could there be any problems if laptop0 and laptop1 are both pushing  
at the same time? Configurations are independent, and in that case  
there should simply be two instances of rsnapshot running, right?

> How are the clients going to wake the server?  Does the server wake up
> on any incoming network connection (I hope)?

Yes, that's the plan. I intent to have the clients send a wake-on-lan  
magic packet to wake the server, wait a little and then try to push  
the backup.

By they way, for the client to see if the backup operation succeeded,  
this could be easily tested by looking at the return code from the  
communication with the daemon, right?

>> 2) If I mount the server as a network drive on the clients using AFP,
>> SMB/CIFS, NFS, ..., and then backup to this 'locally attached' drive
>> with rsync (using rsnapshot), will I lose the metadata because of the
>> transfer via the SMB/... layer?
> I would strongly discourage you from pushing the backup via a network
> drive.  In addition to potential metadata mangling, you lose the  
> benefit
> of rsync's delta-transfer algorithm.

Yes, losing the metadata this way is likely to happen. I'll test it  
once my hardware is ready, just to see what would happen.

Just out of curiosity: Why would rsync not use the delta-transfer in  
that case? Is it because this would be the "local disk -> local disk"  
transfer case for which a fast connection is assumed, so no resources  
are wasted on trying to find differences?

> Matt

Well, thank you so very much. That post you've referred to was really  
one of the most helpful texts for me! Thank you also for the nice  
patch and all the hard work. I very much appreciate it!


More information about the rsync mailing list