version 1.2.8 calls fsync ridiculously often. I found that on NetBSD
with a journaling filesystem, fsync caused a flush of the log followed
by a cache flush (which is reasonable, since fsync is supposed to
guarantee that the bits are reliably on disk). This slowed it down so
far as to be totally
you can also do an lsof | grep -i somePath (where somePath is some
part of the source path that you're backing up) to look to see if some
related python processes are touching different files
> 12091403
> /media/b080d187-ad00-4b4a-9721-fcbe5e839827/Fedora15Backup/rdiff-backup-data/backup.log
>
This is what I get when I do lsof | grep -i rdiff. I don't know how to
interpret this, tho. I notice the bottom file listed as open in the
Windows vdi. I don't think that has even changed since the last time I
did the backup. I haven't used it.
=
[root@localhost eric]# lsof | grep -i rdiff
lso
There's also a logfile that it generates some in the rdiff dir under
the backup destination isn't there?
On Wed, Feb 29, 2012 at 12:38 PM, Sabuj Pattanayek wrote:
> Assuming you don't have access to the system or can't see any hard
> drive lights blinking rapidly, check lsof | grep -i rdiff to se
Assuming you don't have access to the system or can't see any hard
drive lights blinking rapidly, check lsof | grep -i rdiff to see if
the list of files that it's touching is changing . You can also check
dstat -d or iostat -d 1 to see if there's lots of I/O occurring
On Wed, Feb 29, 2012 at 12:26
I've had an rdiff backup running for about 1 1/2 hrs or longer. This is
much longer than it's ever taken in the past. Is there a way I can
check that it's still running right? I hate to just abort it at this point.
Related: what can I safely do on the computer while the rdiff-backup is
runni
