Only other OSX clients with rsync (not backuppc's perl implementation of rsync) and an HFS filesystem will be able to handle the -E stuff.  I think the consensus is to use xtar for mac clients, as it creates a standard tar archive that can be extracted on regular filesystems (putting meta-stuff in  a folder called .rsrc).   Upon extraction, xtar should recombine the meta-stuff from .rsrc to the appropriate file on-the-fly.  Tiger's native tar should do the same thing, but it seems (more) buggy.

brien

James Kyle wrote:
**As I was writing this, I was combing over the client logs and found a common denominator:

Feb  7 03:14:59 Monster cp: error processing extended attributes: Operation not permitted

This error is seen on every client. I then remembered I added the -E (--extended-attributes) switch to my default rsync config since all my clients are OSX machines and are all Tiger or above. 

So, now I know the specific cause. But would anyone have an idea on why the switch to backup extended-attributes is causing an error when backing up extended  attributes?


I will leave the below explanation as a reference for anyone experiencing the same problems:

=========================================================================
=========================================================================


I noted that backups were taking a a pretty long time to complete. In addition, several are exiting out with the error:

Aborting backup up after signal ALRM
My understanding of this error is that it is normally due to a timeout event. 

However, I'm not clear on how to track down exactly what is causing this timeout event. 

Looking at my usage logs, my server cpu's are being maxed out during these backup periods  (dual 2.6ghz xserve), but bandwidth is negligable.

Here are some of the numbers I'm seeing:

client1

Initial full backup: ~60gb in 3.15 hours
Current backup: Start time was last night at 10pm (20:00). Still going as of 8am this morning.
Will probably error out with signal ALRM

client2
Initial full backup: ~41m  20gb
Current backup: incr started at 2am this morning still going at 8:30am

I think the trend is clear. I assume *something* has changed since initial setup that is causing this error, but as I mentioned before I'm not getting anything informative out of my log files that could help point the way.














------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

Reply via email to