On 05/08/16 04:52, martin f krafft wrote:
> also sprach Adam Goryachev [2016-08-04
> 16:04 +0200]:
>> I've used ls -l /proc/pid/fds or strace or lsof etc... all work,
>> some are better on the client rather than the backuppc server.
> In fact, I found none of
On 05/08/16 06:31, martin f krafft wrote:
> also sprach martin f krafft [2016-08-04 22:16 +0200]:
>> Right now, I am staring at the lsof output of the rsync process on
>> a backup client, spawned by BackupPC. It's processing a 3.5G file
>> that has not been touched in 5 years
On 05/08/16 05:33, martin f krafft wrote:
> Hello,
>
> the fact that BackupPC compresses log files using zlib and requires
> /usr/share/backuppc/bin/BackupPC_zcat for their uncompression is
> a bit of a nuisance, not only when log files are being
> sync'd/analysed on a system where there is no
On 05/08/16 04:42, martin f krafft wrote:
> also sprach Adam Goryachev [2016-08-04
> 15:47 +0200]:
>> On 4/08/2016 23:43, martin f krafft wrote:
>
>> It should work as you said, but if you never have enough time to
>> transfer the second file, then you won't
also sprach martin f krafft [2016-08-04 22:16 +0200]:
> Right now, I am staring at the lsof output of the rsync process on
> a backup client, spawned by BackupPC. It's processing a 3.5G file
> that has not been touched in 5 years and has been backed up numerous
> times.
Hello,
the fact that BackupPC compresses log files using zlib and requires
/usr/share/backuppc/bin/BackupPC_zcat for their uncompression is
a bit of a nuisance, not only when log files are being
sync'd/analysed on a system where there is no BackupPC installed.
I also can't find a suitable
also sprach Adam Goryachev [2016-08-04
15:47 +0200]:
> On 4/08/2016 23:43, martin f krafft wrote:
> > 3) Ensure that you can backup any file within the ClientTimeout,
> > Is this necessary? Isn't ClientTimeout about killing the connection
> > after a period
also sprach Adam Goryachev [2016-08-04
16:04 +0200]:
> I've used ls -l /proc/pid/fds or strace or lsof etc... all work,
> some are better on the client rather than the backuppc server.
In fact, I found none of those useful on the server.
> I've also used
On 04/08/2016 14:59, martin f krafft wrote:
> some of the backup processes here run for hours, and there are often
> reasons why I want to check on what's going on.
In the past, I've used things similar to what's mentioned at these
pages:
You can follow XferLog with
/usr/share/BackupPC/bin/BackupPC_zcat /XferLOG.z | tail
but it is buffered, so not completely current
Also on the backup host, you can get the process id of the current dump
processes (there will be two per host during file transfer), and do
(sudo) ls -l
On 04 Aug 2016 14:04, Adam Goryachev wrote:
I can't comment on the rest, but directory entries are always created,
because backuppc needs them for the backup structure (and there is no
disk saving/not possible to hard link them)...
Makes perfect sense! Thanks for the response Adam.
On 4/08/2016 22:59, martin f krafft wrote:
> Hey,
>
> some of the backup processes here run for hours, and there are often
> reasons why I want to check on what's going on.
>
> How do you monitor backups in real-time? XferLOG.z can't be tail'd,
> and attaching strace or lsof to the running
On 4/08/2016 23:56, cardiganimpatience wrote:
> Backups are taking about three hours for a particular fileserver and records
> indicate that over 300k new directories are being created every run.
>
> I opened the XferLOG in a browser and searched for the word "create d" which
> catches every
Backups are taking about three hours for a particular fileserver and records
indicate that over 300k new directories are being created every run.
I opened the XferLOG in a browser and searched for the word "create d" which
catches every newly-created directory. The count was 348k matches. But
On 4/08/2016 23:43, martin f krafft wrote:
> 3) Ensure that you can backup any file within the ClientTimeout,
> Is this necessary? Isn't ClientTimeout about killing the connection
> after a period of time without any traffic?
Almost, but the timer is only updated after each file has been
Hey Adam, thanks for your quick response. I have a few points to
add:
> 1) Ensure you enable SSH keepalives to keep your NAT firewall open
Yes, of course these are enabled.
> 2) You can look to split remote files before the backup, and exclude the
> original large files (sometimes this is
Hello,
the issue I've raised 4 years ago:
https://sourceforge.net/p/backuppc/mailman/message/29727529/
still persists with BackupPC 3.3.0. Basically what happens is that
a combination of large new files and a slow connection between
backup server and client means that a full backup eventually
17 matches
Mail list logo