Businesses often discover that they were poorly prepared for data loss only when they can no longer open an important file, start a system or resume production. Saving information in a second location is not enough. It must also be separated from the primary environment, protected from deletion and regularly checked to confirm that it can be restored. See how to build a backup process that works in practice, not just on paper.
Why create backups in the first place?
Backups allow a business to recover data and resume work when it loses access to the files or systems it uses every day. They remove the need to recreate documents, databases, configurations and entire environments from scratch. A backup can shorten downtime and reduce losses, which grow with every hour a system remains unavailable.
Data can be lost for many reasons:
failure of a drive, server or another device,
accidental deletion of files or overwriting the correct version,
an application error,
database corruption,
a failed update,
equipment theft,
a fire or flood in the office,
a cyberattack, including ransomware.
Ransomware is one of the most serious threats because cybercriminals do not limit themselves to encrypting current files. An attack can affect employee computers, servers, connected drives and network folders. In attacks targeting a specific organisation, criminals often look for systems used for data recovery as well. By deleting or encrypting the versions stored there, they try to prevent the business from resuming operations on its own and pressure it into paying a ransom.
A good plan must therefore address both accidental data loss and an attacker deliberately trying to prevent recovery. Creating an additional copy is not enough. It also needs to be current, separated from the primary environment and suitable for fast, reliable recovery.
Where should you start? First identify what the business needs to operate
It is easy to enable automatic copying for one folder and consider the job done. The problem appears after a failure, when the documents have been recovered but the order management software still will not start, email cannot be restored or the company database remains unavailable.
Start by asking what must work for employees to serve customers, issue documents, process payments and manage current projects. Then identify the data and systems required for those tasks. The list may include:
documents and working files,
email and contacts,
customer, order and product databases,
data from accounting or inventory software,
server, application and device configurations,
installers and information needed to restart systems,
logs that may help determine the cause of a failure or reconstruct an attack.
Logs are particularly important after a security incident. Attackers often remove traces of their activity from compromised devices. If the business does not use a separate log collection system, logs should be included in the backup plan.
Some information that is essential for everyday work is easy to overlook. It is worth considering the full environment carefully. Documents alone may not be enough if an entire system must be rebuilt after a failure or attack and no one knows how it was configured.
Additional challenges in manufacturing facilities
Manufacturing facilities need to protect not only documents but also machine software and settings. When a control computer fails, replacing the device alone may not be enough to restart production. Without a saved configuration, the required software, drivers and operating parameters must be installed again from scratch.
As a result, a machine worth hundreds of thousands can remain idle even though it is mechanically sound. The business must wait for the system to be rebuilt, and every additional hour of downtime creates further losses.
It is therefore worth preparing two complementary types of backup. The first should cover current machine settings, production parameters, recipes and other data that changes during operation. The second should be an image of the control computer that can restore the operating system, drivers and required applications. Installers should also be retained, together with instructions for starting the complete environment on replacement hardware. This means that restarting production does not depend entirely on one person’s memory or the availability of the manufacturer’s service team.
The control computer image is a foundation for rebuilding the environment, not a place to store current data. It should not contain active passwords or access keys, as theft of the image could expose those credentials. After a failure, the system and software are restored from the image first, followed by the latest settings from a separate, regularly updated backup.
Before using the image, check that it has not been damaged or replaced. A checksum is used for this purpose. It is a string calculated from the contents of a file. An administrator records it when the image is created and calculates it again before restoring the system. If the two values match, the file has not changed. A mismatch means that the file was damaged or modified and must not be used.
One additional location is not enough: how should secure backups be created?
If the original files and their backups are stored on the same computer, a drive failure can destroy both sets. Similarly, an external drive kept next to the device will not help if the office is affected by theft, fire or flooding.
This is why the 3-2-1 rule is worth following. What does it mean?
Keep at least three copies of the data.
Use at least two different types of storage media or technology.
Store one copy in a different location away from the company’s main premises.
Putting this rule into practice does not have to be complicated. For example, a business works with data stored on a server. A second copy is created automatically on a separate device in the office, allowing files to be recovered quickly after an ordinary failure. A third copy is sent to a properly secured cloud service or another location, so it can survive an incident affecting the entire office.
Backups should be independent of the primary infrastructure
Saving data on a separate server does not guarantee its safety. If that server is managed through the same systems and tools as the company’s other devices, compromising one administrator account can open access to the entire environment. The attacker can then encrypt current data and delete the backups needed for recovery.
This risk occurs, for example, in businesses using Active Directory, a central system for managing accounts and permissions. When the backup server is connected to it, a domain administrator can manage that server just like any other device. If a criminal compromises that administrator’s account, they also gain access to the stored backups.
Virtual machines present a similar problem. If the production servers and backup system run on the same platform, compromising that platform exposes both environments. In an extreme case, the attacker may delete all virtual machines together with the data stored on them.
At least one copy of the data should therefore be managed independently of the primary infrastructure. It may be held by another provider or on a separate server with its own administrator account and multi-factor authentication. The important point is that compromising one account or system must not allow an attacker to destroy current data and prevent recovery at the same time.
How often should backups be created?
Not all information in a business changes at the same rate, so it should not all follow one backup schedule. An online shop receives new orders throughout the day. If its backup runs only in the evening, an afternoon failure can mean losing many hours of work. Archived contracts or documents used only occasionally do not need to be saved as often.
When setting the schedule, answer two questions:
How much information can the business lose without serious consequences?
How long can the business wait for a particular system to be restored?
If losing an entire day of orders would be a serious problem, backups must be created more often than once a day. If a sales or production system is essential for daily operations, the business must also be able to restore it quickly. Less urgent materials can be recovered later.
Frequently changing databases, working documents and system settings require regular, current backups. System images, installers, archived legal documents and other less frequently changed materials can be saved at longer intervals and stored in a more isolated location, including offline. The schedule should reflect how quickly each resource changes and how urgently it will be needed after a failure or attack.
How can a backup survive a compromised company network? The 3-2-1-1-1 rule
The 3-2-1 rule reduces the risk of losing data after hardware failure or an incident affecting the company’s entire premises. However, not every backup created under this rule will withstand a deliberate attack. If stored data remains accessible from the company network, an attacker may try to delete or encrypt it together with the primary systems.
This is why the extended 3-2-1-1-1 rule is also used. In addition to three copies of the data, two storage methods and one off-site location, it requires:
one copy that cannot be changed or deleted,
one copy kept offline without a permanent network connection.
The first is stored in a form described as immutable or WORM (Write Once Read Many). Once files are written, they cannot be overwritten or deleted. Some storage systems provide this protection. It can also be achieved with LTO WORM tapes or, on a smaller scale, optical media such as Blu-ray discs.
Immutable storage does not solve every problem. If it resides on a server or storage array that an attacker can destroy, the data stored there will also be lost. The second copy should therefore remain offline. It may be held on a disconnected device or on a server that connects to the network only long enough to collect new data.
How can a backup server be isolated further?
A business with a larger number of systems can prepare an additional server dedicated to collecting and storing recovery data. It should not operate in exactly the same way as the primary environment. For example, if most of the infrastructure runs on Windows, the additional machine could run Linux. Using a different operating system does not provide security by itself, but it makes it harder to compromise everything with one set of tools and permissions.
Only the services required to create backups and manage the device should run on that server. Administrator access should use a separate account, multi-factor authentication or a cryptographic key. Traffic used to collect data should also be separated from administrative traffic, with both restricted by network rules.
A safer approach is for the backup server to connect to the source and collect shared data in read-only mode. The source computer does not know the credentials used to manage the destination and cannot initiate a connection to it.
Once the job is complete, the network connection used for the transfer should be disabled and the server should return to offline mode. It can continue to verify integrity, compress data and organise older versions without remaining accessible to other devices.
This architecture demonstrates an important principle: a system that protects data should place as little trust as possible in the environment from which it collects that data.
A completed backup does not guarantee successful recovery: why regular testing matters
Confirmation that a backup was completed does not guarantee that it will help during a failure. Some files may have been skipped or damaged, and the recovery instructions may be incomplete. Without prior testing, the business will discover these problems only when it urgently needs its data.
How can you confirm that recovery will actually work? Two things need to be checked. First, verify that the backup contains all required data and that it can be read. Then perform a test restore by recovering selected files or starting a system from the prepared backup.
A test restore shows:
whether all required data and settings were saved,
whether the recovery instructions are complete and current,
how long restoring the system takes,
whether the system and applications work correctly after recovery.
Do not wait for a real failure. A test gives the business time to add missing data and correct the procedure before its continued operations depend on the recovery process.
This approach is sometimes described as the 3-2-1-1-0 rule. The zero means that no errors were found during backup verification and a test restore. It is not a promise that failures will never happen. It confirms that the stored data is complete and can be recovered successfully.
Backups at a glance: what should you remember?
The most common problem is not a complete lack of backups. More often, backups cover only part of the required data, are stored in the same environment as the originals or have never been tested to confirm that anything can be recovered from them. Before considering the job complete, make sure that:
backups cover not only documents but also databases, settings, applications and other components required to resume work,
data is stored on different media and one copy is held in another location,
at least one copy is disconnected from the network or protected against modification and deletion,
access to backups does not depend on the same accounts and systems as the rest of the infrastructure,
the schedule reflects how often each type of data changes,
the business has completed a test restore and knows how long data recovery should take.
Well-prepared backups will not prevent a failure, but they allow the business to return to work efficiently according to an established plan.
At ZanReal, we help businesses protect their data, servers and systems. We can review the current storage setup, identify missing safeguards and prepare a recovery procedure suited to the actual environment. If you have doubts about the way backups are created in your business, contact us. We will be happy to help.
