Hi @jbilliau93,
See this answer from StackExchange:
The Magento backup system in 1.6 and later has an unfortunate feature where it will change certain file/folder permissions which then can fall afoul of security measures like SuExec, SuPHP or cPanel WHM settings.
The root error that causes a 500 error page will show in the server log. The server error log should be available in your cPanel or in a log folder in your account folder. If not, you can contact your hosting provider to tell you what the errors for the 500 error are being recorded.
Often, clearing the 500 error is as simple as using WinSCP to change permissions. The vile and stupid change often is that index.php in your Magento root folder is given permissions of 666 (readable and writable by everyone) instead of the 644 or 664 permissions that don't violate system security checks. Also check for a file in your magento root called maintenance.flag and delete it.
In worst-case scenarios, the backup can change all file/folder permissions and you then have to run a script to change folder permissions to 755 and file permissions to 644.
Magentocommerce help page for setting file permissions
Given that Magento An e-Bay Inc. Company has allowed some pages to cease existence on their website, transferring the meat of the subject here to link-rot proof. For Magento 1.5+ as follows:
Here’s how to reset your file and directory permissions if PHP is running through FastCGI, suPHP, or LSAPI:
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 550 mage
YMMV depending on hosting provider, files 664 and directories 775 MAY be needed
If PHP is running as a module (DSO), you will need to do this:
sudo find . -type f -exec chmod 644 {} \;
sudo find . -type d -exec chmod 755 {} \;
sudo chmod o+w var app/etc
sudo chmod 550 mage
sudo chmod -R o+w media
On that page is mentioned the Magento Cleanup Tool (as long as it's still available) which is run as a php script. Several people recommend running it after every Magento Admin panel system backup.
Of course, the way around it is to dispense with the Magento system backup till they fix it and use a combined tarball/mysqldump backup as a manual scripted operation or to set up another system and use rsync and do a cron scripted gzipped mysql dump that is pulled over when the rsync backup is run.
Link to post: http://magento.stackexchange.com/questions/7460/attempted-magento-backup-now-throws-500-internal-ser...
Rebecca
