Yes, the reason I went with rsync was due to all of my clients being
osx tiger (and so having HFS+ filesystems). I assumed since the native
rsync was supposed to support extended attributes I could avoid having
to ask all my laptop users to come in so I could install 3rd party
software. I know I could write a .pkg for each of them, but the
management would be a pain since I can't just push necessary updates
out and would have to partially rely on user responsibility (ha!).
On Feb 7, 2007, at 9:10 AM, Brien Dieterle wrote:
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
James A. Kyle
UCLA Brainmapping Center
AIM: krunk337
[EMAIL PROTECTED]
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
