BackupPC-users

Re: [BackupPC-users] Remote backups of a win2003 server keeps failing after a certain amount of time.

2009-01-07 08:05:31
Subject: Re: [BackupPC-users] Remote backups of a win2003 server keeps failing after a certain amount of time.
From: "Koen Linders" <koen.linders AT koca DOT be>
To: <BackupPC-users AT lists.sourceforge DOT net>
Date: Wed, 7 Jan 2009 14:05:56 -0000
Thanks for the reply.

I changed the value to 144000 for this client and will wait another day (or
two). 

Maybe it hangs on a specific file? I hope changing the value worked.

Anyway, thx :)
Koen Linders

-----Oorspronkelijk bericht-----
Van: Holger Parplies [mailto:wbppc AT parplies DOT de] 
Verzonden: 07 January 2009 12:35
Aan: Koen Linders
CC: BackupPC-users AT lists.sourceforge DOT net
Onderwerp: Re: [BackupPC-users] Remote backups of a win2003 server keeps
failing after a certain amount of time.

Hi,

Koen Linders wrote on 2009-01-07 10:17:20 -0000 [[BackupPC-users] Remote
backups of a win2003 server keeps failing after a certain amount of time.]:
> Remote backups of a win2003 server keeps failing after a certain amount of
> time (almost every time about 20h later / data 11 GB already done).
> 
> Backup method: Rsyncd
> [...]
> Contents of file /var/lib/backuppc/pc/80.201.242.118/LOG.012009, modified
> 2009-01-07 09:44:29 
> 2009-01-01 20:00:00 full backup started for directory dDRIVE
> 2009-01-02 16:23:54 Aborting backup up after signal ALRM
> 2009-01-02 16:23:55 Got fatal error during xfer (aborted by signal=ALRM)
> 2009-01-02 16:23:55 Saved partial dump 0

signal ALRM is always caused by BackupPC aborting the backup after
$Conf{ClientTimeout} has passed without BackupPC detecting any progress. In
the case of rsync(d), this needs to account for the complete backup due to
the
way it is implemented (for tar type backups, I believe it is only the
duration
of the longest file transfer). The default value is 72000 seconds == 20
hours.

Raise $Conf{ClientTimeout} to a value that will allow your backup to
complete.
A too high value has the drawback of not detecting stuck backups for that
amount of time. This is nothing to worry about for your first backup.
Perhaps
just add a '0' and change the value back after the first backup has
successfully completed. Future rsync(d) backups should hopefully complete
significantly faster.

> 2009-01-02 20:00:00 full backup started for directory dDRIVE
> 2009-01-03 16:24:01 Aborting backup up after signal ALRM
> 2009-01-03 16:24:02 Got fatal error during xfer (aborted by signal=ALRM)
> 2009-01-03 16:24:04 Saved partial dump 0

I'm not sure why you repeatedly get a partial dump 0 though instead of the
transfer restarting from the point it was originally interrupted (using the
previous partial as reference). That would allow the backup to eventually
complete even without increasing ClientTimeout, but it does not seem to be
happening in your case.

Regards,
Holger


------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
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/

<Prev in Thread] Current Thread [Next in Thread>