Why do you need to implement full Magento backup?
Did you know that there are two types of shop owners? Those who backup their stores and those who already backup their stores. It may sound funny at first, but you actually realize the value of the lost data only when you lose it forever.
When it comes to a Magento store, there are numerous possible reasons of data loss:
- Staff mistake;
- Equipment failure;
- System breach;
- Natural disasters;
- and more.
Grieving over the lost data is painful and helpless at the same time, that’s why I suggest you start making backup copies or recovering one of them right now. In the long run Magento backups must be saved and checked regularly if you want your data to be 100% safe.
If you’re still not sure it’s an absolute must, just imagine there was a fire in the data center, and your website including the database with orders, client base and catalog is gone. Or a server was damaged and you’ve lost the information on the new orders for the past week. That’s why backups are a question of avoiding threats to your business and reputation.
1. (not only) Magento Backup Basics
When developing a backup strategy for you website, you need to be aware of two important terms:
- RPO (Return Point Objective)
- RTO (Return Time Objective)
RPO is a time point where you can go to if you recover your backup copy successfully. Say, you backup your Magento store daily at 4 AM. In that case you will always turn to 4 AM regardless of the time data loss happened. Also, if you are in need to restore the backup file at 3:58 PM, you’ll face almost 24 hours data loss.
RTO is the time you need to successfully restore the data from your backup file. If the database consists of tens of gigabytes, you’ll need up to several hours for a complete recover.
Thus, when you choose backup methods pay attention to RPO and RTO parameters so that your strategy fits your business needs.
To give an example, that’s how we organized full backup on one of our websites:
The size of a single backup file is 6Gb, the site is backed up once in 24 hours at 7 AM (RPO). The time needed for a complete recovery is 25 minutes (RTO). In case there’s a need to recover the backup copy at 11.30 AM, we’ll lose 4,5 hours data, and the website will be down for 25 minutes.
Before backing up your Magento website, make sure you have enough place in /tmp directory.
2. Backing up your Magento website
WHERE TO STORE BACKUP FILES?
The safest variant is to save and store the full backup copy on a server that is physically situated in other data center/city/country/on some other continent. It is called offsite backup. This variant dramatically lowers the chances of losing the backup file if to compare with the case when the original website and the backup copy are stored ‘next door’. It is absolutely not an option to have your backup files on the same server with your original website, as in case of the server failure both copies will be gone, and your hair will become grey.
MAGENTO BACKUP SCRIPT
To make the task easier for those who haven’t done this before we’ve prepared a ready-made script.
[sociallocker id=”6155″]Download simple-offsite-backup.sh free [/sociallocker]
Replace FTP_HOST, FTP_USER, FTP_PASSWORD, MYSQL_HOST, MYSQL_USER, MYSQL_PASSWORD, MYSQL_DBNAME, SITE_NAME and SITE_DOCROOT with your own data.
This script creates a backup file of all the Magento source code and database and uploads it to the FTP server specified.
3. Automating backup process
You definitely don’t want to get up every day at 7 AM and run the script manually, instead go and set up cron so that it runs the backup script regularly and on schedule. To run the script every day at 4 AM you need to add this line to the crontab:
0 4 * * * /path/to/simple-offsite-backup.sh
Important note: this script does not perform backup copies rotation, and you need to remove the old files from the FTP server manually.
4. Recovering Magento from backup files
To recover your site from the backup copy saved using the script, upload the example.com-backup-YYYY-MM-DD_HH-MM.tar.gz and example.com-backup-YYYY-MM-DD_HH-MM.sql.gz files to your server.
Restore the Magento shop source code (the current source code condition is saved into example.com-BAK):
cd /var/www/vhosts test -d example.com && mv example.com example.com-BAK tar -xzf /path/to/example.com-backup-YYYY-MM-DD_HH-MM.tar.gz
Restore the website’s database (the current database condition is saved into example.com.sql-BAK)
mysqldump --quick --add-drop-table example_db > example.com.sql-BAK mysql -h localhost -u example -p -e 'DROP DATABASE `example_db`; CREATE DATABASE `example_db` DEFAULT CHARSET utf8 COLLATE utf8_general_ci;' gzip -dc /path/to/example.com-backup-YYYY-MM-DD_HH-MM.sql.gz | mysql example_db
5. Checking your backup files
To make sure your Magento backup files are correct and suitable for further recover it is good to restore your shop from backup copies to a sandbox (a test site) from time to time.
Make sure that you recover to the separate website and the database and that you fixed the settings in app/etc/local.xml, core_config_data table of the database and cleared the cache. If you forget to do that the sandbox may change the data on the main website, which is not welcome at all.
Regular checkups tell you if the backup copies are solid and also let you evaluate the time needed for data recover.
Do you have any questions regarding the how-to? Welcome to the comments section. Meanwhile, don’t forget to subscribe to Amasty blog updates.