Hello again,
first, I forgot to mention an important detail: we changed from ext3 to
xfs on the 5TB RAID10 array which holds all BackupPC data during the
re-setup.
Am 05.07.2012 15:04, schrieb Adam Goryachev:
> One thing this sounds like is that you moved the location for the
> backups, therefore instead of linking the files, every backup is
> actually a full copy (because the links fail to the pool/cpool).
> Check
> the backuppc log files and see if anything unusual is being logged.
no, this doesn't seem to be the problem. I didn't find any unexpected
logs. The pc/$HOST directory shrinks a lot during the link-process, so I
consider this as evidence that pooling actually works as expected. I did
recognize though, that the pool directory is empty on all BackupPC
servers. All pooled files seem to be stored in cpool instead. Is this
expected?
> Failing that, consider the things that have changed from the old
> server to the "re-setup server":
> 1) Hardware - hard drives, controller, amount of RAM, etc....
Kept exactly the same. We actually shredded the filesystem and thus had
to re-setup. Hardware didn't change.
> 2) Filesystem or hard drive layout/configuration (ie, RAID level,
> layout, chunk size, ext3 compared to jfs, etc)
As written above: moved from ext3 to xfs as we thought that this might
increase performance.
> 3) Double check (while the system is idle if possible) the
> performance of the server, disk speed, especially random read/write
> performance).
Seems normal to me. BackupPC produces heavy load and IO-wait, but
that's expected for large backup-setups, isn't it? ;)
Here's some value from 'iostat -kx' (/dev/sdb contains all the BackupPC
data):
Linux 2.6.32-5-amd64 (backuphost) 07/05/12 _x86_64_ (8 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
13.42 0.00 1.73 25.96 0.00 58.89
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz
await svctm %util
sdb 42.65 1141.40 336.04 168.85 7006.47 5613.14 49.99 0.27
0.52 0.33 16.42
> 4) Consider that if all clients are configured at the same time,
> then all clients will start doing full backups on the same days,
> which
> will screw with performance. Try to manually run full backups on some
> clients to skew the timelines, so that full backups are spread across
> different days.
Yes, already did this, I even deactivated most of the hosts for several
days to give BackupPC some time to keep up with backlog. Didn't help
either.
Am 05.07.2012 14:22, schrieb Bryan Keadle (.net):
> Initial backups on the new server would take longer than what you're
> seeing with the established server which only needs to do changes
> after having done the initial full. Your new server has already done
> the initial backups of your host and it's the subsequent backups that
> are taking so long?
Yes, all initial full backups are done since more than a week ago.
Still the described issues.
Best Regards,
jonas
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
