Hello again Craig,
On Thu, 4 May 2017, Craig Barratt wrote:
> ...I just pushed a fix (maybe not the final one) to git.
>
> Could you please test that change? ...
Confirmed the infinite loop problem here is fixed:
http://www.jubileegroup.co.uk/JOS/misc/week14.png
Thanks for trying to get some debug log files. I was able to reproduce the
problem, and I just pushed a fix (maybe not the final one) to git.
Could you please test that change? You can either apply the diff (see below),
manually replace
Jens & Matt,
Thanks for trying to get some debug log files. I was able to reproduce the
problem, and I just pushed a fix (maybe not the final one) to git.
Could you please test that change? You can either apply the diff (see
below), manually replace BackupPC_tarExtract
Matt,
Thanks. Yes, please re-run with XferLogLevel set to 6 and send me the
interesting parts (or all) of the log file.
Craig
On Fri, Apr 21, 2017 at 6:56 AM, Bedynek, Matthew J.
wrote:
> Craig,
>
> It was very short so I’ll probably redo it today with more debugging.
Craig,
It was very short so I’ll probably redo it today with more debugging. The high
point being that I saw similar behavior.
tarExtract: copyInodes: finished getAll()
tarExtract: copyInodes: finished getAll()
tarExtract: copyInodes: finished getAll()
tarExtract: copyInodes: finished getAll()
Matt,
I somehow missed that. Can you re-send to me please?
Craig
On Thu, Apr 20, 2017 at 8:10 PM, Bedynek, Matthew J.
wrote:
>
> On Apr 20, 2017, at 10:35 PM, Craig Barratt net> wrote:
>
> Jens,
>
> Thanks for including interesting parts of
On Apr 20, 2017, at 10:35 PM, Craig Barratt
> wrote:
Jens,
Thanks for including interesting parts of the XferLOG file. Could you re-run
with XferLogLevel set to 6? Feel free to send the log file (or
interesting parts) to
Jens,
Thanks for including interesting parts of the XferLOG file. Could you
re-run with XferLogLevel set to 6? Feel free to send the log file (or
interesting parts) to me directly, rather than posting to the list.
Craig
On Wed, Apr 19, 2017 at 7:04 AM, Jens Potthast <
Hello,
After upgrading from 3.x to 4.1 and 4.1.1 and converting all backups to
4.x format, I apparently have the same problem: BackupPC_tarExtract is
using 100% CPU and the backup seems to be halted. To stop the backup, I
need to stop it exactly twice in the Web-Frontend. Don't know why it has
I'm not sure where to start. First, I updated the documentation and pushed
a change to update the mtime on the backup directories to match the backup
ending time.
Second, I'm ignoring a few comments since they seem like gratuitous
complaining. Feel free to submit a pull request on git if you
Hello again,
On Wed, 5 Apr 2017, G.W. Haywood wrote:
> ... later I added the 'N$' share to the BackupPC
> configuration. That was about a week ago. Last night's backup
> started at 21:00. After more than 14, hours one process is still
> using 100% of a CPU:
>
> PID USER PR NIVIRT
Hi there,
Briefly I have Windows server with hosting more than one share, my
first backup attempt was to back up only the 'C$' share (about 6GB of
user data) and day or so later I added the 'N$' share to the BackupPC
configuration. That was about a week ago. Last night's backup
started at
Hi there,
Like many others I've been happily using 3.x for a good few years. I
absolutely love it. Most of the time I'm backing up a mixture of
Linux and Windoze boxes, a few dozen machines in total. Backup stores
are distributed, each is of the order of 2TBytes with backups aged up
to a few
13 matches
Mail list logo