Les,
Both side have a fair bit of ram... 1GB on the BackupPC side, and 2GB on the Backup Client side, neither of whice seem to be "Filling up" so I don't think it would be swapping this out to disk......However the CPU usage on the BackupPC goes through the roof.... The full backups are completeing... and the incrimentals are taking in the order of 1000 mins... :
Backup Summary
Click on the backup number to browse and restore backup files.
|
Backup#
|
Type
|
Filled
|
Start Date
|
Duration/mins
|
Age/days
|
Server Backup Path
|
|
full
|
yes
|
2/2 18:00
|
731.1
|
4.5
| /backup/data/pc/picard.local.univrse.com/0 | |
|
incr
|
no
|
2/3 22:13
|
1792.9
|
3.3
| /backup/data/pc/picard.local.univrse.com/1 | |
|
incr
|
no
|
2/5 05:00
|
1146.6
|
2.0
| /backup/data/pc/picard.local.univrse.com/2 | |
|
incr
|
no
|
2/6 05:00
|
1098.8
|
1.0
| /backup/data/pc/picard.local.univrse.com/3 |
Xfer Error Summary
|
Backup#
|
Type
|
View
|
#Xfer errs
|
#bad files
|
#bad share
|
#tar errs
|
|
full
|
33
|
0
|
0
|
161
| ||
|
incr
|
192
|
0
|
0
|
0
| ||
|
incr
|
48
|
0
|
0
|
0
| ||
|
incr
|
48
|
0
|
0
|
0 |
File Size/Count Reuse Summary
Existing files are those already in the pool; new files are those added to the pool. Empty files and SMB errors aren't counted in the reuse and new counts.
|
Totals
|
Existing Files
|
New Files
| ||||||
|
Backup#
|
Type
|
#Files
|
Size/MB
|
MB/sec
|
#Files
|
Size/MB
|
#Files
|
Size/MB
|
|
full
|
7245
|
28847.2
|
0.66
|
1550
|
19.4
|
6278
|
28827.9
| |
|
incr
|
152352
|
326829.8
|
3.04
|
84925
|
94029.1
|
79307
|
232805.2
| |
|
incr
|
152503
|
326834.8
|
4.75
|
152228
|
307970.2
|
402
|
18864.8
| |
|
incr
|
152528
|
326977.8
|
4.96
|
152254
|
309093.4
|
422
|
17884.5 | |
Compression Summary
Compression performance for files already in the pool and newly compressed files.
|
Existing Files
|
New Files
| |||||||
|
Backup#
|
Type
|
Comp Level
|
Size/MB
|
Comp/MB
|
Comp
|
Size/MB
|
Comp/MB
|
Comp
|
|
full
|
3
|
19.4
|
6.5
|
66.6%
|
28827.9
|
24070.3
|
16.5%
| |
|
incr
|
3
|
94029.1
|
73014.1
|
22.3%
|
232805.2
|
207809.9
|
10.7%
| |
|
incr
|
3
|
307970.2
|
264250.4
|
14.2%
|
18864.8
|
16427.6
|
12.9%
| |
|
incr
|
3
|
309093.4
|
264895.2
|
14.3%
|
17884.5
|
15886.8
|
11.2% | |
| Les Mikesell <[EMAIL PROTECTED]>
07/02/2006 12:47 AM |
|
On Mon, 2006-02-06 at 05:47, [EMAIL PROTECTED] wrote:
> Guys... I was hoping someone might be able to tell me if this is
> normal....
>
> I am running BackupPC V 2.1.2... I use RSyncD as the backup
> mechanism... My backups take an extrodanary amount of time to
> comeplete..... in once case 28hours... And all this over a gigabit
> link.. Given that the server in question has a 160GB drive and a 200GB
> drive being backed up... but I would think it would not take all day
> to back up... It's basically finishing a backup in time to start the
> next one on that server.......
>
> The CPU on the BackupPC box seems to run at 100% (Being used by
> "BackupPC_dump" at about 80-85%) (It's a 1.7Ghz P4 with 1GB Ram)
>
> Does this seem odd to anyone?
Rsync loads the entire directory structure in memory at both
ends and if either box is short on RAM it may page to disk
and become very slow. The part that seems odd is that it
is doing the same thing every time. Normally full runs with
rsync are slow because both sides read all the files and
compare in a way that doesn't use much bandwidth, but in
an incremental they just check the directory entries for files
that match. Are you sure the full run has ever completed?
It may be failing every time. If you can get a full run to
complete over a weekend you might be able to live with
weekday incrementals. Otherwise you'll have to split the
run up into smaller volumns.
--
Les Mikesell
[EMAIL PROTECTED]
------------------------------------------------------------
Mail was checked for spam by the Freeware Edition of No Spam Today!
The Freeware Edition is free for personal and non-commercial use.
You can remove this notice by purchasing a full license! To order
or to find out more please visit: http://www.no-spam-today.com
