Backups are an insurance policy for your ecommerce store that you hope never to use. Unfortunately, many backups aren’t adequate.
The purpose of a backup is to recover the code and data to your store. It could be a partial loss, such as accidentally deleting a popular product. Or it could be the loss of your entire store, such as when a server is hacked and the contents deleted.
Backups should get your store online and functional.
But the type of backup you use, and the speed of recovering it, depends on your hosting provider or platform. The host’s disaster recovery process should at least get the servers back. Your own backups should provide the code and data.
Who Is Responsible?
Most hosts offer some level of backups automatically. They usually keep at least two copies of your data, typically through multiple disks called RAIDs — redundant array of independent disks.
Also, hosts often take full copies of a server and store them on separate devices in the data center. These can be add-on services to your hosting plan. They are usually inexpensive and easy to set up, sometimes with just a few clicks.
Ecommerce platforms sometimes have additional backup options. For example, Shopify and BigCommerce allow the exporting of some data for backups, but it’s a manual (and incomplete) process.
Thus every store could use its own backup system to ensure all data is captured.
What to Back Up
For a backup to be usable, it should include everything your store needs to function from scratch. This will depend on how your store is hosted. It can include:
- Code (if you’re not on a hosted platform).
- Databases.
- Asset files, such as images, videos, PDFs.
- Configurations and settings.
- Themes or design layout if they are not included in the code.
A common mistake with backups is to save only part of the data, such backing up the database and theme but not the product images, or not backing up the configuration files so that development staff has to scramble to recreate them. Often, inadequate backups are discovered only during emergencies.
Even if your hosting company conducts backups, it is helpful to have your own versions. Sometimes backups fail. Sometimes there’s a missing file or two. Or sometimes you need an item from long ago and the backups have recycled.
When to Back Up
Almost all types of backups strain your server, slowing down performance. Many companies execute backups during off-hours when the store isn’t as busy. This can work fine, but there are caveats.
- If the backup process is too aggressive, it can cause the store to become unresponsive. This could impact shoppers (and also wake up development staff in the middle of the night).
- If your store sells globally, it might not have off hours.
- Scheduling backups at night implies once per day. That might be acceptable if losing a full day of data is an acceptable risk.
An alternative is to continuously back up your store as long as it doesn’t slow your store down too much. Also, save a few historic copies of your data so that a backup of bad data doesn’t mistakenly override the good version.
Testing
Testing your backups is important. A backup is not a success until you’ve restored it and confirmed all of the data is there. This process can be slow and error-prone if done manually. An automated restoration is much better.
The ability to partially restore from a backup is helpful. Many types of backups require a complete restoration — the backup overrides everything, losing changes since the backup was performed.
A partial or incremental restore allows for selecting of what gets restored, sometimes to the individual file. This can be helpful for simple mistakes, such as deleting a landing page.
Documenting
Once you have created a backup system, document it. Even a single page explaining how the backups are done and where they are stored will save time when you’re rushing to restore it all.
And don’t save the page on the same server as your store! Put it where it is accessible when your store goes offline. My favorite is a combination of a Google Doc and a downloaded copy of it.