BackupPC-users

Re: [BackupPC-users] backuppc_dump hangs server

2009-06-22 13:32:33
Subject: Re: [BackupPC-users] backuppc_dump hangs server
From: Holger Parplies <wbppc AT parplies DOT de>
To: error403 <backuppc-forum AT backupcentral DOT com>, krunchyfrog AT videotron DOT ca
Date: Mon, 22 Jun 2009 19:26:07 +0200
Hi,

error403 wrote on 2009-06-22 07:40:25 -0400 [[BackupPC-users]  backuppc_dump 
hangs server]:
> Before I start dismantling my power supply, what is the highest log level
> for backuppc and rsync?

a quick glance at the code says 9, but 1000 would work just as well, because
it's just as much ">= 9" as 9 is.

> I will try to see what's the last thing that made it crash

Firstly, as we've said multiple times, it's almost certainly a hardware issue,
not a BackupPC (or other software) issue. Consequentially, there is no "one
thing that makes it crash". It's a sum of load applied in a non-deterministic
way, meaning it will crash at different (if perhaps similar) points. Ok, if
you've got a 10GB backup containing one 9.9GB file and 100000 small files, it
is rather likely to always crash within the big file ;-), though not at the
same point.

Secondly, even if it *were* one single cause, you wouldn't see it, that much I
believe I can guarantee. The XferLOG files are compressed. The compression
routine buffers its I/O - it needs to. Furthermore, file system writes are not
synchronous (that would absolutely kill performance), so a hard crash as you
are experiencing would lose you an arbitrary amount of log file output anyway.
For reference, watching the XferLOG output with

        tail -f -n +1 XferLOG.z | /usr/share/backuppc/bin/BackupPC_zcat

will usually show you many lines (perhaps some hundred or more), wait for a
possibly *long* time (read: expect tens of minutes; depends on file sizes and
transfer speed, though), then show you the next bunch of lines and so on. A
"bunch" will usually end mid-line. The only thing you can tell from that is
which parts of your backup you have definitely passed.

While a high log level will probably drown you in enough output to cut a
"bunch" down to a fraction of a few hundred files, I still doubt that will
tell you what you want to know. It just *might* slow down backups enough to
prevent your machine from crashing at all, then again it could just as well
make it crash faster.


Finally, what use is it to you to know at which point BackupPC crashes? Are
you going to make your backups shorter than 15 minutes? The only case where
excluding one specific file (which you would be almost certain not to see in
the log file) would help would be if your crashes are due to file system
corruption on the BackupPC server side - but you would see that as a kernel
panic on the console, and it would almost certainly not completely lock up
your machine (i.e. 'top' would not hang and the ssh would not time out). And
you wouldn't fix it by excluding a specific file anyway ...

> if I can replicate it over many crashes.

I don't think repeatedly crashing your machine is going to do you much good.
If anything, it might permanently damage your hardware. At least check your
CPU temperature and voltage levels. That much really isn't hard to do.

Regards,
Holger

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
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/