I have noticed something else after initiating backups without the --
extended-attributes switch.
My cpu usage has gone to near zero and I've already completed a few
backups.
So I'm pretty sure I've found the culprit.
However, why would my servers cpu usage go down with a change in the
rsync flags executed remotely?
Perhaps I'm missing something in the ssh command process, but I
thought rsync was executed on the client side and pretty much all the
server did was pooling and hard linking.
This would seem to indicate that the slowdown may be in the way
backuppc processes the extended-attributes rather then the actual
rsync process itself.
Perhaps someone more knowledgeable of the details of the exchange
could enlighten me. :)
On Feb 7, 2007, at 9:31 AM, Brien Dieterle wrote:
Yeah, I can feel your pain. You might just give native tar (already
installed) a shot; obviously it isn't as good as rsync for
bandwidth, etc.. As long as ACLs are not enabled on your clients
you might not have any problems at all. I have ACLs turned on, on
our server, and backups worked fine but there were a TON of bogus
error logs. Good luck!
brien
James Kyle wrote:
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
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/
-------------------------------------------------------------------------
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/
