Hi,
On Thu, 13 Oct 2005, Golden Butler wrote:
rdiff-backup -v7 --print-statistics /home/golden/testy
/iomega/bkps/loomis/gtest
/iomega sounds like you're using some iomega device, which usually use
pre-formatted media using FAT32.
However...
I started the first backup to an empty directory on a second server.
I'm wandering about the low speed of ca. 1.6MB/s
Both servers are DL380 with dual PIII 833MHz running debian, python2.3,
librsync 0.9.7-1 and rdiff-backup 1.0.0-0.cvs20050819 (thanks to Dean
Gaudet for the debian package).
They
Dave and Marteen,
The iomega device I'm using is not formatted as FAT32. It's
partitioned and formatted as reiserfs. Is this filesystem type not
recommended? Also, I did upgrade rdiff-backup to version 1.0.1 with
the same results. It seems like something fundamental that I'm
missing but
I'm still relatively a newbie to linux even though I've been using it
for almost two years, so excuse me for the ignorance. What is
"strace", and how would I be able to use to track down this segfault
problem?
Delamatrix
Dave Kempe wrote:
Golden Butler wrote:
Dave and Marteen,
Golden Butler wrote:
I'm still relatively a newbie to linux even though I've been using it
for almost two years, so excuse me for the ignorance. What is strace,
and how would I be able to use to track down this segfault problem?
strace shows a program's syscalls -- roughly, the requests it's
Carsten Lorenz wrote:
rdiff-backup needs 132s to transfer a 140MB file (1.1MB/s).
While rdiff-backup works on the next file scp transfers the same file in 15s
(9.3MB/s)!
What does that mean? scp = 9.3MB/s rdiff-backup = 1.1MB/s
Since we want to backup one tera-byte of data this would last
Steve Clement wrote:
Carsten Lorenz wrote:
rdiff-backup needs 132s to transfer a 140MB file (1.1MB/s).
While rdiff-backup works on the next file scp transfers the same file in 15s
(9.3MB/s)!
What does that mean? scp = 9.3MB/s rdiff-backup = 1.1MB/s
If i understand, what you mean,
Golden Butler wrote:
Okay, I'm almost ready to give up on rdiff-backup!
I hope you get your problem resolved - as others have already said, it
doesn't look like an rdiff-backup problem anyway.
More to the point, if you need help in future, I hope you're able to
pick a less rude subject.
this may be a shot in the dark, but have you tried installing the python
modules for extended attributes and access control lists?
google searches for Unable to import module xattr and Unable to
import module posix1e from pylibacl package both turned up this thread:
On Fri, 14 Oct 2005, Carsten Lorenz wrote:
Since we want to backup one tera-byte of data this would last more than a
week.
i've never looked closely at why the first backup is so slow -- and i've
heard the report from lots of folks... i tend to use rsync for the initial
backup, and then use
On Thu, 13 Oct 2005, Golden Butler wrote:
./test-bkp: line 2: 20700 Segmentation fault rdiff-backup -v7
--print-statistics /home/golden/testy
you know, a segfault is very unlikely to be an rdiff-backup problem.
i'd be more tempted to blame the C compiler (which could be miscompiling
yeah, I've starting to believe also that this is not an rdiff-backup
problem. I don't overclock and I don't have any inexpensive memory.
I'm thinking I should start from scratch. I'm running Suse Linux 9.2.
I didn't compile or optimize any package, cause actually I don't know
how to do so. So
Dave Kempe [EMAIL PROTECTED]
wrote the following on Thu, 29 Sep 2005 09:02:49 +1000
Hi,
I am trying to get rdiff-backup 1.0.1 going on cygwin. I will have a
windows package built shortly, but I would love it if windows- windows
backups worked.
the initial backup works ok, but after the
Ben Escoto wrote:
It would be easy to add a check and then just disable fsyncing if it's
not available, but I don't think this would be entirely safe.
since we are using windows, we have come to accept we don't live in an
ideal world :) I think we are prepared to accept not entirely safe.
hmm that doesn't sound like a questionable config at all...
maybe you could try gdb... especially if you can set up a
local-fs-to-local-fs backup which causes the problem. then try this:
% gdb python
(gdb) run /usr/bin/rdiff-backup [rdiff-backup args here]
assuming the segfault still occurs
Ryan Tarpine [EMAIL PROTECTED]
wrote the following on Sun, 02 Oct 2005 11:19:36 -0400
I just learned about and installed rdiff-backup yesterday. I tried to
run the command:
...
Mac OS X style resource forksOn
Mac OS X Finder information On
...
Wiebe Cazemier [EMAIL PROTECTED]
wrote the following on Wed, 05 Oct 2005 17:17:38 +0200
The other being that rdiff-backup matches UIDs and GIDs against the
/etc/passwd of the current system. So, if you're restoring a backup
by means of a bootable CD, like Knoppix, all your (system) users
Carsten Lorenz [EMAIL PROTECTED]
wrote the following on Fri, 14 Oct 2005 10:03:37 +0200
I started the first backup to an empty directory on a second server.
...
Everything looks fine:
CPU-usage on the source-server is ca.15% for ssh and ca. 6% for rdiff-backup
CPU-usage on the destination is
18 matches
Mail list logo
