|
Type some keywords below and hit "enter": This will search the drupal.org issue queues across the various projects that make up the Aegir system. If there are no relevant results, please submit an issue there. |
Other support resources: |
Whenever Aegir runs backups of the sites - some of which have a ton of files - sites hosted on the instance become unavailable. Is there any way to improve the performance of site backups?
|
Type some keywords below and hit "enter": This will search the drupal.org issue queues across the various projects that make up the Aegir system. If there are no relevant results, please submit an issue there. |
Other support resources: |
No recent comments found.
The discussion area lets your team communicate by posting updates and discussing issues. It is a great place for sharing progress, discussing challenges, and exploring ideas.
#1
It could become slow if the site is very large, but other sites should not be unavailable.
These two issues might be usefull for your situation:
#2
Thanks for the info. You are right. The site in question is large. It has almost 3G worth of files to tar up. However, I can confirm that all sites become unresponsive during the backup of this one. It is easily reproducible. I like Aegir's backup UI and being able to control scheduling, restore from the UI, etc. However, I have not experienced this slowdown when backing up using a simple tarring script I threw together. Perhaps Aegir can control background, OS-level backups through some module? Or, if there was some way to hook into Aegir's ability to restore using my own scripted backup...Is there any information regarding how this might be accomplished? I imagine I can have a script package the the files in a format that Aegir understands, but where would I put this to allow Aegir to be able to restore from it? Are there any required DB entries?
#3
At Koumbit, we've seen this too, and have ended up having to restart of apache on occasion, and even reboot a server in one instance. I believe it's due to the gzip stage of a backup which can max out CPUs, though one of my colleagues believes it might be an i/o bottleneck. Re-nicing the backup process can usually get things going again.
We've been discussing setting a default 'nice' value on all aegir processes using "limits.conf":http://manpages.debian.net/cgi-bin/man.cgi?query=limits.conf, but we haven't experimented with it yet.
#4
In fact, anarcat recently implemented a 'nice'-based solution from within the hosting-queue-runner. So, you may want to check out the latest release of that project.
#5
Thanks for all the input here. I do see that backups include the temp file dir. Seems that this would not be a requirement, no? It bloats the total backup size by quite a bit as well. I have a large site that is are 700MB. When it is backed up it is over 1.5GB. From what I can tell this is due to it backing up the private/temp directory.
#6
Actually, the Aegir backup is pretty awful. I increased the frequency of cron on a large site (on a remote apache instance) so that I could use ultimate cron on that site to control specific tasks with greater precision. This completely hosed my server. Aegir kept trying to backup up the site every minute. Every minute a 1.5GB backup was compressed and rsynced across my network. This is absolutely terrible. The servers couldn't hang and eventually just puked.
Aegir's backup took two servers offline. This is a major shortcoming.
#7
Now backup is in an endless loop. I can't get ahead of it. I delete the backup task, kill rsync, gzip, mysqldump, only to see that everything has spawned back up! I've rebooted the servers! I don't know what to do. Please advise!
#8
Starting a backup every minute seems like a separate issue. Do you have a module installed to periodically schedule backups?
What you describe in #7 should normally be more then enough to stop a runnning task. But if you keep getting new tasks... you could try to temporarily stop the queue runner or cronjob that triggers hosting-dispatch.