Do you have the right knowledge to restore company backups?

Restoring backups isn’t always as simple as just retrieving the latest one. When things are really critical, the recovery needs to be done correctly to avoid causing even more damage. Read more about how you can prepare your organization.

The technical ability to restore the latest backup usually exists within the organization, and in most technical solutions, it's relatively straightforward. What’s often less clear, however, are the answers to the following questions:

• Does the restore cause consequential problems due to system dependencies?
• How do we deal with information created since the last backup, which is therefore lost?
• Who is responsible for verifying the functionality after the restore, and how should this be done?

These questions are relevant whether you have an internal IT department or you have outsourced IT to one or more suppliers.

System dependencies

In the more distributed model used for systems, it often takes a combination of many different functions to deliver the overall functionality required for the business to operate effectively.

One example is the management of customers and their orders. It is not uncommon for one system function to be responsible for customers' master data, while another handles their orders - for the sake of simplicity, we ignore other common dependencies here.

If backups are done once a day, this means that up to 24 hours of data can be lost. Suppose the master data system suffers a serious failure 18 hours after the last backup.

During these 18 hours, 20 new customers have registered and placed orders. When restoring from the backup, these customers are no longer in the master data for customers. However, the order management system is not affected and orders continue to be processed and sent to customers.

When an order is sent to a customer, information is passed on to the billing system, which retrieves customer data from the master data to create invoices. As the 20 new customers are no longer in the master data, the necessary information is missing from the invoicing.

What happens at this stage depends on the logic of the billing system. In the worst case, the error goes undetected and no invoices are created, resulting in a direct loss of revenue. In the best case, the problem is detected by the right people in the organization, who can manually fix it and ensure that the invoices are sent out.

How is lost information handled?

The example of customer master data is an area where information can be lost between the time the backup takes place and the restoration needs to be carried out. In an organization, there are many functions that continuously create a lot of information, both manually and systematically.

It is important to ensure that there is a plan for handling this before a backup needs to be used, otherwise there is a great risk that this will not be handled at all or inadequately in the event of an incident.

It should be considered that the organization may need to carry out some manual activities to restore the information for this period, which leads to loss of revenue and risks inadequate information quality.

It also needs to be taken into account that some information will not be possible to recreate. It is important that this is clearly stated and included in the business’s accepted risk profile. An audit may lead to the need to improve backups to reduce the time from backup to possible need for recovery (RPO).

Do you verify the restore?

When restoring backups, there is always a risk that the restore did not work completely, or that the backup did not include all the information required for functionality.

It is therefore important that a restore is followed by testing and verification. This includes both checking the technical functions and that the system functions work in practice, based on how the business actually uses them. Only once this is confirmed can the recovery be considered complete and normal operations resumed.

What and how tests are to be carried out is entirely governed by the system functionality and should be defined before a recovery needs to be carried out. It is also important to ensure that the responsibility for who performs the tests is clearly documented.

It’s reasonable to use functional tests from regular testing routines, such as those IT and the business perform during standard system changes, assuming these tests are defined.

Plan, verify and test!

It is important that your plans not only include backup but also recovery. These plans need to be verified by review but above all tested so that they really work when they are needed. Just as exercises are done for physical security such as evacuation exercises, exercises are also needed for security functions in IT.

Cegal and backups

Cegal can support you in developing plans for backup and recovery, verify existing plans and also lead the work of testing the plans. In addition to backup and recovery plans, we are also happy to help you with the entire continuity management process.