[Borgbackup] performance problem

[Giuseppe Arvati]

Il 31/08/2017 18:59, Thomas Waldmann ha scritto:
>>> Are both backups storing into the same repository? Or at least into a
>>> repository located on the same borg repo server?
>>
>>     yes to network storage via NSF
> 
> You mean to NFS?

yes

> This is likely slower than using ssh: repo url (requires borg on the
> repo server).
> 
> If your network connections are stable, you can reduce the impact a bit
> by using --checkpoint-interval=1800 (or more, default is 300s in borg
> 1.0.x).

usually stable ( 1Gb link )

> 
>>> The data set read by the backups - where does the data come from?
>>    local FS but are two differente samba network share
> 
> OK, if borg is reading source data from physical, local disk, there
> should be no problem with inode numbers.
> 
> What's the filesystem type (see mount output)?
> 
   xfs ( /dev/sdb on /dati type xfs (rw,noatime,nodiratime) )

>>    can be a problem related to lock/timeout for same files served by samba ?
> 
> Not sure about that.

this night I ran the same job through CRON instead of AT
with this stats:
/dati/utenti
Archive name: utenti-2017-08-31-19
Time (start): Thu, 2017-08-31 19:32:51
Time (end):   Fri, 2017-09-01 06:45:47
Duration: 11 hours 12 minutes 55.85 seconds
Number of files: 462.364 ( 194GB )

/dati/gruppi
Archive name: gruppi-2017-08-31-19
Time (start): Fri, 2017-09-01 06:45:56
Time (end):   Fri, 2017-09-01 10:56:12
Duration: 4 hours 10 minutes 16.21 seconds
Number of files: 1.022.702 ( 380GB )

and I had this new messages

Synchronizing chunks cache...
Archives: 3, w/ cached Idx: 0, w/ outdated Idx: 0, w/o cached Idx: 3.
Fetching and building archive index for utenti-2017-08-30-19 ...
Merging into master chunks index ...
Fetching and building archive index for utenti-2017-08-28 ...
Merging into master chunks index ...
Fetching and building archive index for utenti-17-08-29-19 ...
Merging into master chunks index ...

Are these messages ok ?

So I have two archive one is an half of the other and take 3 times to 
complete the backup.

If someone have other suggestions, to try to investigate why the
first archive is slower than second archive, will be very appreciate.

thank you
giuseppe