Because of the backup operation there is contention for disk and cpu also maybe network resources, hence your site is not responsive.
To avoid this you will have to reduce the io and cpu priorities of the backup operations so that your site can function normally.
You can use this before you invoke your backup script.
root@x:~# bash
root@x:~# echo $BASHPID
6576
BASHID variable is PID of current bash session
root@x:~# ionice -c 2 -n 7 -p $BASHPID
This will reduce your current shell's disk io priority
-c = class ( 0 none, 1 real time, 2 best-effort, 3 idle)
-n = priority (0-7 , 0 is highest priority)
root@x:~# renice +10 -p $BASHPID
This will reduce your current shell's cpu scheduling priority (-19 is max priority and 20 is least priority)
root@x:~# ./backup-script
Now from here you can invoke your backup script. Since the child processes inherit cpu and io priorities from parent,
your backup script process(es) will run with lower io,cpu priorities and therefore your server processes have precedence over backup.
In case you are using a cron job you can put all above commands in a file , chmod for x permissions and add that file to cron.
In case network is bottleneck , you may have to use "tc" to classify backup traffic and rate limit it. You can read about rate-limiting here.
http://wiki.openvz.org/Traffic_shaping_with_tc
mysqldump
, it certainly can make everything slow for a while, especially with large MyISAM tables as with MyISAM full table locks are needed.