We all know (at least I hope so) that backups are important, especially in these cases:
- Data loss due to hardware failure
- Disk encryption
- BitLocker Key Loss
- Accidental deletion of data
On the other hand, what should not be neglected is the backup strategy and the restoration strategy.
What is a backup strategy?
The backup strategy allows you to define several points, including:
- Data retention (retention period)
- Backup frequency (hourly, daily)
- Backup type (full, delta, differential)
- Backup Locations
Let's explore the different points together, and develop them
Define data retention
Data retention means the maximum date we can restore a backup (deletion of backups after a certain period of time)
This saves space on our storage, and avoids having to buy huge amounts of space to store the same duplicate data over time.
This parameter will depend a lot on needs, but we can reasonably plan on 6 months of retention.
How often should you back up your data?
By asking this question, we can ask ourselves for a second at the same time: how much working time can I afford to lose?
It is indeed technically necessary to do a backup every second (file replications, even if it is not really a backup), but this slows down the machine considerably.
In most cases, one day is sufficient, and so we back up at night, or between 12 p.m. and 1 p.m. for workstations.
On the other hand, in environments where it is crucial not to lose data, or only the bare minimum, it is possible to set a backup to 10 minutes (as long as the backup infrastructure can handle the load).
What type of backup? And for when?
There are 3 types of backups, namely:
- Full Backup: Backs up everything defined on every backup
- Incremental backup: Backs up only changes since the last backup
- Differential backup: Backs up only changes since the first full backup
Method | Advantage | Inconvenience | Comment |
---|---|---|---|
Complete | The whole thing is saved at each execution Only backup is needed to restore | Takes up a lot of space | Used in principle as a first backup |
Incremental | Smaller save files on each launch | If a file is corrupted in the middle, the restore will not work | Used if there is a lot of modification between backup cycles |
Differential | Only need the latest complete and differential to restore | Can become heavy and long if many modifications are made | Used if relatively few changes occur between backup cycles |
Backup Locations
Now that we've defined how to save, we can define the location. And at this point, we have several choices available to us:
- Backup to an external USB hard drive
- Backup to a NAS network server
- Online backup
- Backup to a remote site (off-site)
Backup to an external USB hard drive is mostly used for workstations. There's no real reason to back up an infrastructure to this type of media, except for offline backups.
Backing up to a NAS is a good compromise between expanding storage (to back up more) and protecting data. However, it is necessary to ensure that access credentials are protected and not encrypted in plain text (usually managed by backup software).
Online backup can be a good idea if you don't have the budget to invest in NAS storage servers. However, you need to make sure that backups are encrypted to prevent malicious individuals from accessing the stored data.
And finally, if you have a remote site, or multiple locations, you can send your backups there. This prevents data loss in the event of a fire.
But so which location should you choose?
We use a mix of the above solutions, namely the 3-2-1 rule:
- 3 copies of the data
- 2 different types of storage
- 1 off-site backup
This way, we are prepared for several eventualities, and we reduce the risk of data loss.
And now for the restoration?
It's all well and good to back up your data, but it's not when everything is crashed that you should think about how to restore it 🙂
The goal is to prevent this problem by scheduling a regular file and service restoration test. The idea is to simulate a complete crash (server loss, fire, cryptolocker, etc.), and to see if it is possible to restore the infrastructure and workstations, in how much time, and especially if the data is intact.
Conclusion
We can make the best possible backup and restore strategy, but changes can be made after the backups are set up, such as adding servers, changing passwords, or changing the backup policy.
This is why it is important to regularly review your backups, perform restoration tests, and constantly question the configuration in place.
Just when you've lost your data, don't realize your backups haven't been working for months.