Usual set of issues apply:
1. Check the raw network throughput between your FD and SD using something like iperf to verify the network can handle it.
2. Check storage performance at both ends using an IO benchmark
Once you are sure there are not lower level bottlenecks look at Bareos there are commonly 2 wayhs to address this,
1. compression. Does your fileset have compression turned on? If so what type and is bareos-fd running 100% cpu during the run? The compression features on Bareos is not multi-threaded and thus is single core limited. Switching to lz4 or some other faster than gzip will help.
2. Splitting up the backup.
You can setup multiple jobs and split the fileset across multiple jobs and then run those jobs in parallel. Then the compression single core isn’t as much of an issue because you have a thread for each job each doing their own compression.
This would also let you spread out full’s across schedules so you can complete at least some of your data.
Brock Palen
bro...@mlds-networks.com
www.mlds-networks.com
Websites, Linux, Hosting, Joomla, Consulting
> --
> 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 view this discussion on the web visit
https://groups.google.com/d/msgid/bareos-users/5e2cd162-d59f-48fb-a6e3-240ad058ee35n%40googlegroups.com.