On this day dedicated to data backup, we felt it was important to go back to some basic fundamentals to understand: why it is important to backup your data? And how to do it well?
In this article, we will focus on our expertise as a web hosting platform outsourcer.
On this day dedicated to data backup, we felt it was important to go back to some basic fundamentals to understand: why it is important to backup your data? And how to do it well?
In this article, we will focus on our expertise as a web hosting platform outsourcer.
Why save?
The primary objective of backup is to be covered in case of problems:
- data loss;
- system failures;
- cyber attacks.
For example, we want to be able to go back if a production start-up goes wrong, if we are about to start a risky intervention, or to follow a backup policy because we aspire to comply with the ISO27001 standard.
The primary objective of backup is to be covered in case of problems:
- data loss;
- system failures;
- cyber attacks.
For example, we want to be able to go back if a production start-up goes wrong, if we are about to start a risky intervention, or to follow a backup policy because we aspire to comply with the ISO27001 standard.
What is the difference between backup and redundancy?
Even if your service is multi-redundant and your data is replicated in real time on several storage systems, this does not mean that you should do without backup.
This redundancy ensures that you do not lose your data, for example in case of a server failure. However, it does not protect your data against « voluntary » actions such as :
Even if your service is multi-redundant and your data is replicated in real time on several storage systems, this does not mean that you should do without backup.
This redundancy ensures that you do not lose your data, for example in case of a server failure. However, it does not protect your data against « voluntary » actions such as :
In both of these cases, redundancy is useless because on all the synchronized storage systems, the same data would be deleted. The solution to avoid this is to use a backup.
In both of these cases, redundancy is useless because on all the synchronized storage systems, the same data would be deleted. The solution to avoid this is to use a backup.
What to back up, how often?
The simple answer is « everything » and « often ». More pragmatically, you should back up data that is not easily rebuildable first.
For example, it is easy to reinstall a VM with a working « Apache » configuration, but it is more complicated to deploy an entire Web application based on « Magento » (including the database) with the order history, the catalog, etc. We will therefore start by backing up the essential data for the applications without forgetting the configurations used.
The simple answer is « everything » and « often ». More pragmatically, you should back up data that is not easily rebuildable first.
For example, it is easy to reinstall a VM with a working « Apache » configuration, but it is more complicated to deploy an entire Web application based on « Magento » (including the database) with the order history, the catalog, etc. We will therefore start by backing up the essential data for the applications without forgetting the configurations used.
As for the frequency, it is important to have a backup before each important change, or at least once a day.
A critical application may have more important backup needs. It is therefore important to know the usage to determine the best backup policy.
As for the frequency, it is important to have a backup before each important change, or at least once a day.
A critical application may have more important backup needs. It is therefore important to know the usage to determine the best backup policy.
Independently of each organization, measurement criteria are established in the disaster recovery plan:
Independently of each organization, measurement criteria are established in the disaster recovery plan:
-
The RPO (Recovery Point Objective): which corresponds to the maximum freshness of data that the organization is willing to lose ;
-
The RTO (Recovery Time Objective): which corresponds to the maximum time to restore a service after a failure or a data loss.
How long to keep the backups?
Ideally, everyone would like to be able to keep and track as much data as possible. But in reality, it is often sufficient to keep only one or two months of history, to allow a proper time to notice a problem and have the elements to correct it.
On the other hand, as far as access logs are concerned, for example, the law requires that they be kept for one year. It is therefore important to include them in your backup policies.
Ideally, everyone would like to be able to keep and track as much data as possible. But in reality, it is often sufficient to keep only one or two months of history, to allow a proper time to notice a problem and have the elements to correct it.
On the other hand, as far as access logs are concerned, for example, the law requires that they be kept for one year. It is therefore important to include them in your backup policies.
Example of a backup plan structure
Here's what a generic backup plan might look like:
Here's what a generic backup plan might look like:
Configurations
For each change.
We recommend to version them using « git » for example and to accompany each change with a comment explaining the reason of the change.
For each change.
We recommend to version them using « git » for example and to accompany each change with a comment explaining the reason of the change.
Application files (e.g. source code and media of a website)
They should be backed up at least once a day.
We recommend to use an incremental backup system (like « borg » or « duplicity ») to not limit the storage space requirement.
They should be backed up at least once a day.
We recommend to use an incremental backup system (like « borg » or « duplicity ») to not limit the storage space requirement.
Databaes
These are data stored in database management systems. They must be backed up at least once a day.
We recommend the implementation of a replication system in order to perform the backup outside the production server.
These are data stored in database management systems. They must be backed up at least once a day.
We recommend the implementation of a replication system in order to perform the backup outside the production server.
Recommendations
-
1/ Always store your backups on equipment that is physically separate from production and in sites that are ideally geographically distant. This prevents you from losing production and backups if the main site is destroyed.
-
2/ Always keep a fairly recent backup at home, regardless of your contract with your host. Nobody is safe from an accident, you can never be too careful.
-
3/ Check your backups! Make sure they are done and that you can restore your environment from them.
-
4/ Perform backup restoration tests. A backup is good, but if you never test it, it's useless.
Customer Area
Webmail
