Best practices for backup and restore strategies

Best practices for backup and restore strategies

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

The points below apply to both servers and workstations

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
MethodAdvantageInconvenienceComment
CompleteThe whole thing is saved at each execution
Only backup is needed to restore
Takes up a lot of spaceUsed in principle as a first backup
IncrementalSmaller save files on each launchIf a file is corrupted in the middle, the restore will not workUsed if there is a lot of modification between backup cycles
DifferentialOnly need the latest complete and differential to restoreCan become heavy and long if many modifications are madeUsed if relatively few changes occur between backup cycles
There is no single strategy that is good and can be applied everywhere; it is important to think and adapt according to the situation.

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)
Never place the backup on the backup host unless there is a very good reason

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.

We must never forget that zero risk does not exist, but we can get close to it.

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.

Of course, the ideal is to have other machines to test the restoration, you are not going to destroy your infrastructure for these tests, especially if the backups do not work

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.