This is the second part of three adressing general topics of environmental architecture for backup systems.

In the last part, we examined considerations for the placement of individual backup components, hardware configuration, and fault tolerance (Point 1 and 2 of the following list of major threats).

In this part, we address the aspects of locations and site redundancy. These are points 3 through 5 on the list of major threats to backup environments that we identified in the last part.

What are the main threats to backup data?

• Wrong placement of backup environment components
• Hardware damage to backup systems
• Power outages or disasters at one location
• Power outages or disasters at multiple locations
• External locations for backup data
• Ransomware attacks
• Theft of access data and unauthorized access
• Intentional or unintentional damage by insiders

In the next part, we will delve deeper into the remaining points on the list. These are points that are more likely to be caused by criminal activity or human error.

As with the topics in the last part, these topics do not apply only to the backup environment. Everything interacts and influences each other. There are specific requirements for backup, but most of the considerations in this text also apply to the production environment. However, I will still refer to the backup environment in this text.

1. Power Outages or disasters with one location

You have fulfilled all requirements described in the last chapters and now disaster strikes your data center.
This could be a power outage – the best case for disasters, because there is a good chance that your data is widely undamaged when power is restored. But during the outage your data is inaccessible.

More severe disasters are flooding, earthquake, plane crash, you name it – in case a such a disaster your data is in acute danger. Chances are great that your data in the affected data center is lost und unrecoverable.

What are you doing now? You have invested in redundant infrastructure, have build secure hardware servers and everything is still lost? What have you done wrong?

You have forgotten that you still have put all eggs in one basket. What? Yes, you have put all your systems and data at one location… So, unfortunately your efforts were in vain, and all your data is lost.

2. Power outages or disasters at multiple locations

We have seen in the last chapter that it is a bad idea to rely your infrastructure and/or data on one location. It can be easily destroyed by disaster.

You can avoid much of this risk when you use a dual or stretched data center. Clusters and services are stretched over both data centers and data, hardware and logic are stored in both locations.

So, when disaster strikes in one of the locations your data and infrastructure is save. You may have to do some adjustments to continue operations but it possible to go in without a long outage.

Your data is safe now? You think so?

Let me tell you a little (unfortunately true) story:

A few years ago, there was a major flood in a river valley in Germany (in several river valleys, to be honest). This river is normally about 30 cm high. In a very short time, the water level rose to about 10 meters. With all the catastrophic consequences for the villages and infrastructure throughout the valley.

There were warnings from the authorities and the weather service, but no one wanted to believe the warnings. It was simply unimaginable that this small, peaceful river could transform into such a raging beast (despite historical accounts of similar events in this valley).

As a result, pretty much everything in this valley was destroyed.

What does this have to do with our considerations?

Well, there was an automotive supplier in this valley. This company did a lot of things right in planning its IT infrastructure – it had redundant systems, two data centers about 10 km apart, duplicate data storage, etc. Basically, everything we've listed so far.

Why was this company wiped out anyway? They hadn't considered the surrounding areas when planning their locations. Both data centers were located in two different villages in the same river valley... When the flood came, it unfortunately destroyed both data centers.

What can we learn from this? Choose your locations wisely and consider external factors such as topography, proximity to rivers, lakes, oceans, power plants, forests, and so on.

3. External locations for your (backup) data

Is it not possible, for financial or organizational reasons, to select locations so that simultaneous destruction is unlikely, or do you want to further increase the availability and/or security of the data?

Data does not have to be constantly accessible; it can be stored or copied to external media and/or locations.

Let's look at two possibilities as examples.

Data can be stored or copied to object storage repositories in any cloud. In this case, it is significantly more protected from the risk of location (let's ignore the risk of a nuclear strike that destroys half the world. In that case, we have other problems than our company data anyway...).

Additional data protection is provided by activating Object Lock (Immutability), which ensures that data cannot be deleted before the configured retention period expires. We will discuss immutability in the next part of the series.

When using object storage in the cloud, it is important that administrative access to object storage is well protected. Otherwise, there's a risk that an attacker could gain access to the administration interface and simply delete the storage account. This is similar to the situation with physical servers in your own data center; there, an attacker can circumvent all security measures as soon as they access the server's administration interface (iDRAC, ILO, etc.).

The second option for using external locations for data, which we want to consider here, is tape.

With tape storage, the individual tapes on which the data is stored are ideally automatically moved from a tape library to the tape drives when the data needs to be accessed. Most data is therefore not directly accessible in such a scenario.

However, once an attacker gains access to the application using the tape storage or the tape library's management interface, they can delete all tapes in the library. Therefore, it makes sense to remove fully written tapes, or all tapes written within a certain period of time from the library and move them to an external "vault."

This vault can be a safe at your own site. In this case, the scenario only increases data security and does not solve the problem of site destruction. Or the vault can be at any other location to which the tapes are transported. For example, some companies have a Tape Vault located in a nuclear-proof tunnel more than 100 km away from the data center.

Ideally, this vault is operated by a trusted external service provider. In this case, it will be significantly more difficult for an attacker to access the data.

In the next part of this series I will discuss environment security and malware resilience.