In my experience, segfault in libraries usually caused by installing it
from different source.
For example, when I install BackupPC for CentOS, I use the one in EPEL repo.
I make sure that all the libraries (perl and others), only come from CentOS
base repo, and not from other, as installing them
backu...@kosowsky.org wrote at about 21:08:33 -0400 on Thursday, October 31,
2013:
> From: Rob Sheldon - 2013-11-01 00:13
> > Just ran into the bug described back in 2011 by Jeffrey
> > (http://sourceforge.net/mailarchive/forum.php?thread_name=20017.43110.617411.92113%40consult.pretender
From: Rob Sheldon - 2013-11-01 00:13
> Just ran into the bug described back in 2011 by Jeffrey
> (http://sourceforge.net/mailarchive/forum.php?thread_name=20017.43110.617411.92113%40consult.pretender&forum_name=backuppc-users).
>
> I had to reinstall BackupPC after an OS upgrade broke it (*sigh
Just ran into the bug described back in 2011 by Jeffrey
(http://sourceforge.net/mailarchive/forum.php?thread_name=20017.43110.617411.92113%40consult.pretender&forum_name=backuppc-users).
I had to reinstall BackupPC after an OS upgrade broke it (*sigh*) and my
quick glance at the situation match
On Thu, Oct 31, 2013 at 2:20 PM, Holger Parplies wrote:
>>
> That doesn't explain your situation, but it still might be something to think
> about (and we might be seeing one problem on top of and as result of another).
> I agree with Jeffrey - an "Unable to read ..." error *without* a preceeding
Hi,
I've spent far too long writing an email and trying to make it make sense and
then discarding it again.
Just one thought I want to rescue: the RStmp file was really *large*
(something like 1.5 GB), your backup trees are really *large* (1.4 TB), your
pool FS is really *full* (27.5 GB free). Ru
Sharuzzaman Ahmat Raslan wrote on 10/31/2013
02:38:01 PM:
> Hi Timothy,
>
> I got the number by observing the output of iotop while file
> transfer is running. Also, on BackupPC host summary page, average
> transfer rate for full backup is also around 3MB/s
> It could be a network bottleneck
On Wed, Oct 30, 2013 at 9:06 PM, Sharuzzaman Ahmat Raslan
wrote:
> Hi Holger,
>
> Based on short session of troubleshooting, I believe the machine actually
> suffer from low I/O speed to the disk. Average read is about 3 MB/s, which I
> considered slow for a SATA disk in IDE emulation.
Where are
Les Mikesell wrote at about 10:15:42 -0500 on Thursday, October 31, 2013:
> On Thu, Oct 31, 2013 at 9:47 AM, Craig O'Brien wrote:
> >> What is the underlying storage here - nfs?
> >
> > Local SATA disks in a RAID 5 (5 disks, 3TB each in capacity)
>
> I think I'd force an fsck just on genera
Hi Timothy,
I got the number by observing the output of iotop while file transfer is
running. Also, on BackupPC host summary page, average transfer rate for
full backup is also around 3MB/s
It could be a network bottleneck also, as the customer is using 100Mbps
switch with around 80 PC, not inclu
On Thu, Oct 31, 2013 at 12:51 PM, Sharuzzaman Ahmat Raslan
wrote:
>
> On Fri, Nov 1, 2013 at 1:33 AM, Craig O'Brien wrote:
>>
>> messages-20131006:Sep 30 13:53:24 servername kernel: BackupPC_dump[15365]:
>> segfault at a80 ip 00310f695002 sp 7fff438c9770 error 4 in
>> libperl.so[310f6
Sharuzzaman Ahmat Raslan wrote on 10/30/2013
10:06:18 PM:
> Hi Holger,
> Based on short session of troubleshooting, I believe the machine
> actually suffer from low I/O speed to the disk. Average read is
> about 3 MB/s, which I considered slow for a SATA disk in IDE emulation.
*REAL* slow:
Craig O'Brien wrote at about 08:49:15 -0400 on Thursday, October 31, 2013:
> The du -hs /backup/pool /backup/cpool /backup/pc/* has finished. Basically
> I had 1 host that was taking up 6.9 TB of data with 2.8 TB in the cpool
> directory and most of the other hosts averaging a GB each.
>
> Th
Timothy J Massey wrote at about 12:01:06 -0400 on Thursday, October 31, 2013:
> Holger Parplies wrote on 10/30/2013 10:24:05 PM:
>
> > as I understand it, the backups from before the change from smb to
> rsyncd are
> > linked into the pool. Since the change, some or all are not. Whether the
Timothy J Massey wrote at about 11:52:35 -0400 on Thursday, October 31, 2013:
> "Craig O'Brien" wrote on 10/31/2013 08:49:15 AM:
> Just out of curiosity, why hadn't you already done that?!?
>
> > Unable to read 8388608 bytes from /var/lib/BackupPC//pc/
> > myfileserver/new//ffileshare/RStmp
Les Mikesell wrote on 10/31/2013 01:54:24 PM:
> On Thu, Oct 31, 2013 at 12:33 PM, Craig O'Brien
wrote:
> >
> >> fsck the filesystem.
> >
> > bash-4.1$ fsck /dev/sda1
> > fsck from util-linux-ng 2.17.2
> > e2fsck 1.41.12 (17-May-2010)
> > /dev/sda1: clean, 20074506/2929688576 files, 2775975889/2
"Craig O'Brien" wrote on 10/31/2013 01:33:30 PM:
> > Just out of curiosity, why hadn't you already done that?!?
>
> I didn't know which host was the problem and didn't think of it.
> Although I'll readily admit it seems painfully obvious to me now. :)
Just so you're sufficiently humble... :)
On Thu, Oct 31, 2013 at 12:33 PM, Craig O'Brien wrote:
>
>> fsck the filesystem.
>
> bash-4.1$ fsck /dev/sda1
> fsck from util-linux-ng 2.17.2
> e2fsck 1.41.12 (17-May-2010)
> /dev/sda1: clean, 20074506/2929688576 files, 2775975889/2929686016 blocks
> bash-4.1$
That tells you it was unmounted cle
On Fri, Nov 1, 2013 at 1:33 AM, Craig O'Brien wrote:
> messages-20131006:Sep 30 13:53:24 servername kernel: BackupPC_dump[15365]:
> segfault at a80 ip 00310f695002 sp 7fff438c9770 error 4 in
> libperl.so[310f60+162000]
This error shows BackupPC_dump segfault, and pointing to libperl
> Just out of curiosity, why hadn't you already done that?!?
I didn't know which host was the problem and didn't think of it. Although
I'll readily admit it seems painfully obvious to me now. :)
>The big question is, though, why they aren't linking. I'd really start at
the bottom of the stack (t
On Thu, Oct 31, 2013 at 11:36 AM, Marcel Meckel
wrote:
> Hi,
>
>> Example:
>> ls -l /var/lib
>> lrwxrwxrwx. 1 rootroot 22 Apr 22 2013 BackupPC ->
>> /data/BackupPC/TopDir/
>>
>> mount
>> /dev/sda1 on /data type ext4 (rw)
>
> out of curiosity - why don't you
Hi,
> Example:
> ls -l /var/lib
> lrwxrwxrwx. 1 rootroot 22 Apr 22 2013 BackupPC ->
> /data/BackupPC/TopDir/
>
> mount
> /dev/sda1 on /data type ext4 (rw)
out of curiosity - why don't you just configure /data/BackupPC/TopDir
in config.pl as the TopDir?
Holger Parplies wrote on 10/30/2013 10:24:05 PM:
> as I understand it, the backups from before the change from smb to
rsyncd are
> linked into the pool. Since the change, some or all are not. Whether the
> change of XferMethod has anything to do with the problem or whether it
> coincidentally ha
"Craig O'Brien" wrote on 10/31/2013 08:49:15 AM:
> The du -hs /backup/pool /backup/cpool /backup/pc/* has finished.
> Basically I had 1 host that was taking up 6.9 TB of data with 2.8 TB
> in the cpool directory and most of the other hosts averaging a GB each.
Well, there's your problem.
> The
On Thu, Oct 31, 2013 at 9:47 AM, Craig O'Brien wrote:
>> What is the underlying storage here - nfs?
>
> Local SATA disks in a RAID 5 (5 disks, 3TB each in capacity)
I think I'd force an fsck just on general principles even though it
will take a long time to complete. Google turns up a few hits
> What is the underlying storage here - nfs?
Local SATA disks in a RAID 5 (5 disks, 3TB each in capacity)
Regards,
Craig
On Thu, Oct 31, 2013 at 10:37 AM, Les Mikesell wrote:
> On Thu, Oct 31, 2013 at 7:49 AM, Craig O'Brien
> wrote:
> >
> > Unable to read 8388608 bytes from
> > /var/lib/Backu
On Thu, Oct 31, 2013 at 7:49 AM, Craig O'Brien wrote:
>
> Unable to read 8388608 bytes from
> /var/lib/BackupPC//pc/myfileserver/new//ffileshare/RStmp got=0,
What is the underlying storage here - nfs?
--
Les Mikesell
lesmikes...@gmail.com
---
The du -hs /backup/pool /backup/cpool /backup/pc/* has finished. Basically
I had 1 host that was taking up 6.9 TB of data with 2.8 TB in the cpool
directory and most of the other hosts averaging a GB each.
The 1 host was our file server (which I happen to know has a 2 TB volume
(1.3 TB currently u
Hi,
You could also go from raid1 to raid10.
Met vriendelijke groet,
Micha Kersloot
Blijf op de hoogte en ontvang de laatste tips over Zimbra/KovoKs Contact:
http://twitter.com/kovoks
KovoKs B.V. is ingeschreven onder KvK nummer: 1104
- Oorspronkelijk bericht -
> Van: "Adam Goryach
29 matches
Mail list logo