Re: [BackupPC-users] suffering from the backups have stopped syndrome

Hi,

Terri Kelley wrote on 2008-10-07 12:28:45 -0500 [Re: [BackupPC-users] suffering 
from the backups have stopped syndrome]:
> I doubt it is a time out issue as all of mine is on gig ethernet.
> 
> On Oct 7, 2008, at 12:22 PM, Nick Smith wrote:
> 
> > Im running into the same thing on ubuntu, from what ive read it could
> > be a timeout issue, ive set my time out extremely high to see if i can
> > get it to work,

simple: timeout is "(aborted by signal=ALRM)". Timeout means something is
aborted because it is taking unreasonably long. If your backup is aborted
because the definition of "unreasonably long" is incorrect (i.e. it simply
takes that long and everything is ok), then you need to adjust the definition
(i.e. increase $Conf{ClientTimeout}). If your backup is aborted because it
is, in fact, taking unreasonably long (i.e. nothing is happening and it would
never complete, even if it were left to run forever), then you need to fix the
problem, because BackupPC's automatic fix (killing the backup) won't get your
backups done.

You need to find out which of these is the case. Network speed is not always
the only possible limiting factor. Of course, with an ISDN link it's easy to
calculate that a 30GB backup will take at least, hmm, 48.54 days, so you'd
need to set $Conf{ClientTimeout} to at least 4200000, probably significantly
larger. With GBit ethernet you can't expect the same backup to finish in 240
seconds, obviously. If it takes longer than you expect, you will need to find
out

- is anything happening, i.e. is data transferred between client and BackupPC
  server?
- If so: why is it slow? Can you live with that speed? Can you do anything to
  increase it?
- If not: why not? What is going wrong and how can you fix it?

My point is: you don't need to wait for 48.54 days to find out how long your
backup will take. Waiting won't tell you why it is slow. You can do some
calculating and investigate what is currently going on. Of course, it can be
perfectly reasonable for rsync to take hours to build a file list, and you
will see no network traffic during this time. But you'll see CPU usage and
disk I/O.

The word combination "timeout issue" is meaningless. A timeout is not an
issue. A timeout happens because of an issue - because BackupPC cannot find
out what the issue is, only that there is one. The issue may be that the
operator set ClientTimeout unreasonably low, or just about anything else.

Regards,
Holger

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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/