Discussion:
[bareos-users] Backup to disk slow
'Martin Schmid' via bareos-users
2018-08-24 17:31:17 UTC
Permalink
Hi everybody

I guess that this question has been asked several times but I cannot find the reason for my problem:


I'm running bareos 17.2 on linux with several storage daemons on the network. All of them write reasonably fast with about 10MB/s to disks.

Most of the disks are configured as RAID1, some RAID0 and one is a single disks.

Only the single disk has a slow backup speed of never more than 1MB/s, sometimes even much lower.

If I replace the disk by an SSD, the backup speed rises to some 17MB/s. So it must be the disk.

But a cp of a large file runs with 75MB/s, sometimes more. So, it should not be the disk.

I've then enabled spooling with the spool directory being on a SSD.

The spool file writes with about 25MB/s but the despooling doesn't rise above 1MB/s.

Since this shouldn't be anything other than a data copy, why doesn't it reach the write speed of a file copy?

All compression work is done by the file daemon and should not affect despooling.

And database speed is not the reason, eider. There's no CPU load and the same data sent to another device runs much faster.

So, what's the explanation for this? And is there something effective to tune at sd level? Block size or so..


Regards,

Martin
--
You received this message because you are subscribed to the Google Groups "bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users+***@googlegroups.com.
To post to this group, send email to bareos-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
r***@gmail.com
2018-08-27 05:25:39 UTC
Permalink
Hi.
I had the similar problem.
Can you show you show configuration?
Post by 'Martin Schmid' via bareos-users
Hi everybody
I guess that this question has been asked several times but I cannot
I'm running bareos 17.2 on linux with several storage daemons on the
network. All of them write reasonably fast with about 10MB/s to disks.
Most of the disks are configured as RAID1, some RAID0 and one is a single disks.
Only the single disk has a slow backup speed of never more than 1MB/s,
sometimes even much lower.
If I replace the disk by an SSD, the backup speed rises to some
17MB/s. So it must be the disk.
But a cp of a large file runs with 75MB/s, sometimes more. So, it should not be the disk.
I've then enabled spooling with the spool directory being on a SSD.
The spool file writes with about 25MB/s but the despooling doesn't rise above 1MB/s.
Since this shouldn't be anything other than a data copy, why doesn't
it reach the write speed of a file copy?
All compression work is done by the file daemon and should not affect despooling.
And database speed is not the reason, eider. There's no CPU load and
the same data sent to another device runs much faster.
So, what's the explanation for this? And is there something effective
to tune at sd level? Block size or so..
Regards,
Martin
--
You received this message because you are subscribed to the Google Groups "bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users+***@googlegroups.com.
To post to this group, send email to bareos-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
'Martin Schmid' via bareos-users
2018-08-27 09:32:23 UTC
Permalink
Hi

I'm now able to answer this question myself:

The absolute 'must' is to increase the 'Maximum block size'.
I've set it to 4M and the throughput rose by a factor of 10!

I'm using xfs again as file system after btrfs didn't perform better.
With the default block size of 64k, my test backup of 4.82GB now
finishes after 5 mins 36 secs

I'm now retesting with even bigger blocks and without spooling.

Regards,

Martin
Post by r***@gmail.com
Hi.
I had the similar problem.
Can you show you show configuration?
Post by 'Martin Schmid' via bareos-users
Hi everybody
I guess that this question has been asked several times but I cannot
I'm running bareos 17.2 on linux with several storage daemons on the
network. All of them write reasonably fast with about 10MB/s to disks.
Most of the disks are configured as RAID1, some RAID0 and one is a single disks.
Only the single disk has a slow backup speed of never more than
1MB/s, sometimes even much lower.
If I replace the disk by an SSD, the backup speed rises to some
17MB/s. So it must be the disk.
But a cp of a large file runs with 75MB/s, sometimes more. So, it should not be the disk.
I've then enabled spooling with the spool directory being on a SSD.
The spool file writes with about 25MB/s but the despooling doesn't rise above 1MB/s.
Since this shouldn't be anything other than a data copy, why doesn't
it reach the write speed of a file copy?
All compression work is done by the file daemon and should not affect despooling.
And database speed is not the reason, eider. There's no CPU load and
the same data sent to another device runs much faster.
So, what's the explanation for this? And is there something effective
to tune at sd level? Block size or so..
Regards,
Martin
--
Martin Schmid
APS systems AG, Neumatt 4, CH-4626 Niederbuchsiten
Tel direkt: +41 62 389 8891, Fax: +41 62 389 8880, Tel: +41 62 389 8888
www.aps-systems.ch
--
You received this message because you are subscribed to the Google Groups "bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users+***@googlegroups.com.
To post to this group, send email to bareos-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Dakota Pilot
2018-08-27 18:17:43 UTC
Permalink
Where did you increase the maximum block size - is this a setting withing Bareos?
--
You received this message because you are subscribed to the Google Groups "bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users+***@googlegroups.com.
To post to this group, send email to bareos-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...