From: Bill A. <waa...@re...> - 2015-06-25 23:46:59
|
On 06/25/2015 07:46 AM, SPQR wrote: > Hi Alan, > > Wow, this was really fast :-) Thanks for your answer. > > of course I know, that this is a io-consuming-process, but the load is really too high. Other tasks that are done by the system (log rotation, ...) are not working correctly and once the server crashed bc. of this high load. > > Wouldn't it be better to use ionice -c2 -n7, even if the backup-task works longer? > > In this case the system would only read/write, if there are no other processes which need the io. I wonder if the "MaximumBandwidth =" setting in your Job resource might help you to reduce disk i/o load. If the File Daemon is self-limiting on what it can send over the network, surely what it is reading from the disk will be less. Just a thought, not something I would typically implement - fast backups seems to be the normal requirement. And usually the faster, the better. :) Either way, if you are reducing the resources (disk i/o or network bandwidth) your backups will take more time - A fact which you have already conceded to. :) You might also look into Virtual Full backups. This way you only have to suffer the high i/o once*, then do incremental jobs each day. Then, instead of running a full when the time comes (once/month or whatever your cycle is) you run a Virtual Full and the storage daemon creates a new full from the current full and the subsequent incremental/differential jobs - and the client FD is not even contacted while "full" backup is running. * It is probably a smart idea to run a real full job every once in a while: "Just In Case"(TM) Hope this helps! Bill -- Bill Arlofski http://www.revpol.com/bacula -- Not responsible for anything below this line -- |