Backing up your data

Some of your data will be updated and used more frequently than others. Some data will be business-critical and can’t be lost. Some data will be annoying to re-create if it is lost. Deciding the different characteristics of your data will affect the decision on how it is backed up.

1. Understand your data

Review all the different data your organisation has and set backup objectives. A good starting point is to identify the different data types. These could be:

customer or staff provided; such as employee or customer personal details, customer account credentials
organisation generated; such as financials, operational data, documentation and manuals
system based; such as configuration, system, and log files.

For each data set you need to know exactly how important that set of data is and what it’s used for. Find out:

where the data is generated
how frequently it’s generated or updated
where it’s stored
who in the organisation is responsible for the data

The data owner can then decide how important the data is, and how difficult it would be to recreate it if it was lost. These decisions help set two time-based objectives around recovery, called recovery point objective and recovery time objective.

Recovery point objective

The recovery point time (RPO) is the time between when the last backup was made and when the incident happened. It’s based on how often the data changes, and how hard it is to recreate it.

The RPO is about how much data you’re willing to risk losing. This objective determines how frequently you perform backups.

Each data set will have a different RPO based on the kind of data it is. For example, the settings in your VOIP system probably don’t change very often. If you needed to remap the phone numbers for each staff member it would be inconvenient but not particularly hard, so you may set a longer RPO. A common default RPO would be one day (24 hours).

If you’re an online sales business, that sales data is very important. Contacting your customers and asking them what they purchased is embarrassing for the organisation. That data will have a much shorter RPO. A common default RPO may be too long and you may need one that is only a few hours.

Recovery time objective

The other objective you need to set is the recovery time objective (RTO). The RTO is the amount of time it takes to get back up and running after restoring data from a backup. It is used to make a lot of different disaster recovery decisions. For backups, the RTO determines where they’re stored and which media they’re stored on. It also influences what backup model is used.

You will have a shorter RTO for datasets:

in business critical systems, or
around the tasks that you urgently need to do to get your business running again.

Keep multiple backups for this data and including a local copy, like in your locked server room. Storing backups offsite, or in the cloud, adds more time to the restoration process.

2. Configure your back ups

Configure your backups based on the data objectives. There are a few settings to consider when configuring your backups:

Frequency – how often your backups run.
Type – how much data is backed up (such as full, incremental, or differential).
Retention – how long you keep the backups. This may be decided by laws or other regulatory requirements.
Media – what the data is stored on (such as tape, optical drives, hard drives, or flash drives). Make sure the media you use is designed to meet your retention requirements.
Location – where the backup media is stored (such as on the network, offline and in a locked room, in cloud storage). Consider environmental dangers for these locations, like earthquakes.

TIP: You probably store different datasets in different places. You will have greater control about backup configurations for datasets that you store yourself. Talk to your vendor for any datasets that they store. They may be responsible for configuring the backups or they may give you the ability to configure it yourself.

We recommend mixing the components up to follow a 3-2-1-1 model. Make three copies of your backup and store them on two different media types (e.g. a magnetic tape and an external hard drive). Store one copy offsite and at least one copy offline.

There are different types of media options for storing backups. Make sure you pick a media type that considers the longevity of the physical media. Make sure that you will have access to hardware that can still access that media, and software that supports the backup format. You will need this for as long as you retain that backup.

TIP: Some backups are big and the bandwidth required to perform them on your network may be quite large. If you have frequent, large backups, the backups may overlap. This is where a second backup triggers before the first one finishes. If this happens, discuss it with the data owner so that you can make different decisions about the configurations.

It’s a balancing act between resources available and allowable data loss. Calculate the time, money, and resources required for each backup configuration. You may have to reassess the objectives and configurations to find the right balance. In that case, make sure you discuss the RPO and RTO with the data owner.

3. Protect and manage your back ups

Some processes and configurations need to be set for backups, regardless of how they’re stored or how often they’re run.

TIP: If you need to save time, money, or resources, reconsider the sections above. A failed backup or a backup in the wrong hands can be much worse than a little more downtime when restoring.

Testing

Test your backups so that you know you can successfully restore your data. Run multiple types of tests regularly. They should mimic scenarios that your organisation might run into. A few common use cases are:

a simple file restore (where an employee accidently deletes a file)
an application restore (where an application was unsuccessfully upgraded, and needs to be rolled back)
a database restore (after a database server failure)
an operating system restore (where an operating system upgrade went wrong)
an identity and access system restore (where changes are accidently made to large groups of users and it needs to be reversed).

Some of these restoration use cases will need to be tested together, such as an application restore that also requires a database rollback. This helps you check the current configurations allow you to meet your objectives.

Protection

Your backups need to be protected from unauthorised access. You can achieve this through a combination of encryption and physical protection.

Encryption

Backups contain copies of your data in several locations, so it’s important to secure them. Backups should be encrypted at rest using a strong encryption algorithm, with a long and unique password. Standard setting bodies, such as NIST External Link , recommend the Advanced Encryption Standard (AES) encryption algorithm and 256 bit keys.

Physical protection

Just like you protect physical files, you need to store backup devices somewhere safe. Keep them protected from environmental dangers or access from unauthorised people. Make sure the devices are in a secure room or cabinet, and are protected from dangers like water or heat damage. Heat can lead to increased media degradation.

Automation

Configure backups to a schedule so they can run automatically. Automate the entire backup process as much as possible to make sure it happens when you need it to. This could include creating and storing the backups, and sending notifications when they start and finish.

Logging and alerts

Backup logs will help you make sure that your backups are running as expected. You can enable an alert when:

an issue happens during the backup process,
when backup configurations change, or
when backup servers are accessed on the network.

These notifications shouldn't happen often. Make sure that an alert initiates an incident response process.