From: John R. <rou...@re...> - 2008-03-26 18:45:16
|
Hi all: I am noticing an issue in our backuppc installation. Every Monday we have 20-30 hosts (of 84) that were not backed up in the prior 24 hours. It seems the /var/log filesystem takes much longer on the sunday/monday backups than it takes during the rest of the week. I am using the rsync backup method across a WAN and run 4 backups at a time rate limited to 1Mb/s to stay under our bandwidth allocation. The backup time runs from 23:00->12:00 (13 hour window). I have been able to see only 2 of the 4 slots in use during the backup window. To try to keep all 4 slots full I changed the wakeup schedule to: $Conf{WakeupSchedule} = [22, 22.5, 23, 23.5, 0, 0.5, 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5, 5.5, 6, 6.5, 7, 7.5, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21]; and this seems to have helped somewhat. The nightly run takes about 30-40 minutes, so I started the WakeupSchedle at 22:00 so it would complete before the backup window starts at 23:00. I think the problem is that log files are rotated on Sunday AM, so the Sunday night/Monday morning backup run has to transfer the entire contents of these log files because the names change during the log rotation. Even though I have almost all of /var/log/messages in the backuppc cpool, on the client machine the file is renamed to /var/log/messages.1 during the rotation while backupc's copy of that same file is named /var/log/messages so rsync copies the entire contents onto a new messages.1. This continues for messages.2 and so on. I think I have tuned backuppc as far as I can to try to eliminate dead time in the backup window. Does anybody have any ideas on getting rsync to be able to use the contents of the prior files? I am not using filled backups, but one thought is to use filled backups and (via a hook) duplicate the rotation of log file in the backuppc tree before the rsync operation is done. So the backuppc's /var/log/messages would move to /var/log/messages.1 and thus match the file layout (and contents) of the client machine. Thanks for any ideas. -- -- rouilj John Rouillard System Administrator Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111 |
From: Craig B. <cba...@us...> - 2008-04-01 20:46:59
|
John writes: > I am noticing an issue in our backuppc installation. > > Every Monday we have 20-30 hosts (of 84) that were not backed up in > the prior 24 hours. It seems the /var/log filesystem takes much longer > on the sunday/monday backups than it takes during the rest of the > week. > > [snip] > > I think the problem is that log files are rotated on Sunday AM, so the > Sunday night/Monday morning backup run has to transfer the entire > contents of these log files because the names change during the log > rotation. Yes, that makes sense. Unfortunately a renamed file cannot be easily matched, so it has to be transferred and then matched against the pool. (A better approach with log files is to append the date stamp to the name, rather than an incrementing number.) Any chance you have sparse files in /var/log? They can be very large, and none of the Xfer methods detect sparse files. Craig |
From: Les M. <les...@gm...> - 2008-04-01 21:33:42
|
Craig Barratt wrote: > John writes: > >> I am noticing an issue in our backuppc installation. >> >> Every Monday we have 20-30 hosts (of 84) that were not backed up in >> the prior 24 hours. It seems the /var/log filesystem takes much longer >> on the sunday/monday backups than it takes during the rest of the >> week. >> >> [snip] >> >> I think the problem is that log files are rotated on Sunday AM, so the >> Sunday night/Monday morning backup run has to transfer the entire >> contents of these log files because the names change during the log >> rotation. > > Yes, that makes sense. Unfortunately a renamed file cannot be easily > matched, so it has to be transferred and then matched against the pool. > > (A better approach with log files is to append the date stamp to the > name, rather than an incrementing number.) > > Any chance you have sparse files in /var/log? They can be very large, > and none of the Xfer methods detect sparse files. Some versions of 64-bit linux will have a sparse /var/log/lastlog that will be 1.2 terabytes if you transfer it the hard way: http://en.wikipedia.org/wiki/Lastlog It might be a good thing to exclude on general principles. -- Les Mikesell les...@gm... |
From: John R. <rou...@re...> - 2008-04-02 00:23:29
|
On Tue, Apr 01, 2008 at 01:46:46PM -0700, Craig Barratt wrote: > John writes: > > I am noticing an issue in our backuppc installation. > > > > Every Monday we have 20-30 hosts (of 84) that were not backed up in > > the prior 24 hours. It seems the /var/log filesystem takes much longer > > on the sunday/monday backups than it takes during the rest of the > > week. > > > > [snip] > > > > I think the problem is that log files are rotated on Sunday AM, so the > > Sunday night/Monday morning backup run has to transfer the entire > > contents of these log files because the names change during the log > > rotation. > > Yes, that makes sense. Unfortunately a renamed file cannot be easily > matched, so it has to be transferred and then matched against the pool. > > (A better approach with log files is to append the date stamp to the > name, rather than an incrementing number.) Yup, but most syslog's don't support that nor does logrotate support date stamping during rotation. That would definitely reduce it to just 1 file having to be totally re-copied though. > Any chance you have sparse files in /var/log? They can be very large, Nope, well none except for lastlog and that doesn't get rotated weekly and isn't very large. > and npone of the Xfer methods detect sparse files. Doesn't rsync support sparse files, or do you mean the rsync perl module doesn't support them. -- -- rouilj John Rouillard System Administrator Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111 |