On-Site or Cloud Backup for a Growing Company

Monday morning, billing does not start. The database on the server is corrupted, and last night's backup is on the same storage as the live system. The team knows the data is somewhere, but they don't know when and in what condition it will be usable again. In such cases, the question of on-site or cloud backup is no longer an IT detail but an operational risk: can the goods be delivered, can the invoice be issued, are customer data accessible, and how long will work be halted?

In many companies, the backup strategy has evolved historically. There was a server, then a network storage was added, later an external hard drive or a cloud storage. These are not necessarily bad solutions on their own. The problem starts when no one knows for sure which systems are backed up, where they are located, how long they are kept, and whether they can actually be restored.

The purpose of backup is not to copy files

A business's backup needs do not start from how many terabytes of data it stores. It starts from which business processes need to be reactivated after an error.

There are different consequences if an archived contract is unavailable for a few hours, and different ones if the webshop inventory data, the manufacturing system, order management, or financial database goes down. The first can be an inconvenience. The second can cause direct revenue loss, faulty performance, loss of customer trust, and significant overtime.

Therefore, two questions must be handled separately. One is the recovery time: how long should it take for a system to be operational again? The other is the acceptable data loss: how much fresh data can disappear at most? If a warehouse system can only be restored to the previous day's state, then the goods movements submitted, received, or transferred in the meantime need to be manually reconstructed. This is often a bigger problem than the IT outage itself.

A good backup solution is not good because it runs automatically. It is good because the company can continue working with verified data within an acceptable time frame in a known incident situation.

On-site or cloud backup: not a mutually exclusive choice

On-site backup is typically made to storage operating at the company's premises or its own server room. Its advantage is fast local recovery and direct control. If a large database, multiple virtual servers, or a significant file set needs to be restored, the local network connection can be significantly faster than an internet download.

This can be particularly relevant in production, logistics, or office environments where multiple systems are closely interdependent. A local backup infrastructure is also valuable if the internet connection is temporarily unavailable or if a quick restoration of a complete system image is necessary.

However, on-site backup has a fundamental limitation: it bears the same physical risks as the live environment. Fire, flooding, electrical failure, theft, ransomware, or a faulty administrative operation can simultaneously affect both the server and the backup. If the backup storage is continuously writable and accessible with the same permissions, an attack may not necessarily stop at the live system.

In contrast, cloud backup physically separates the backed-up data from the site. A properly designed service can provide version control, encryption, geographical redundancy, and longer retention times. This is especially useful if the company operates at multiple locations, supports remote work, or does not have its own adequately protected infrastructure.

Cloud backup is not magic either. Its recovery time is influenced by the internet connection, the amount of data, the selected service level, and whether a single file or an entire server environment needs to be restored. A multi-terabyte system backup in the cloud can be secure, but an urgent full restoration may still take hours or days if the connection or plan is not sized for this.

In practice, for most growing companies, neither the exclusively on-site nor the exclusively cloud model is the best. The two approaches together provide meaningful protection: fast local recovery for frequent errors and a separate copy for more severe incidents.

First, map the process and dependencies

A backup project often starts as a technical question: what storage to buy, which cloud provider to choose, how much capacity is needed? These are valid questions, but they come up too early.

First, it is necessary to understand how information flows within the company. An order from a webshop can enter the webshop engine, then into an ERP, then into invoicing, warehouse system, and courier integration. If only one system can be restored to an earlier state while the other systems have more recent data, discrepancies can easily arise. The order may appear fulfilled in one place but missing in another. In such cases, after restoration, business reconciliation can be as much of a task as the technical recovery itself.

The same is true for manufacturing. It may happen that the production plan, machine data, quality assurance documentation, and inventory records live in separate systems. Not all data needs to have the same recovery goal. But it is necessary to know which outage stops production, which data can be reconstructed, and which has legal or contractual retention obligations.

Thus, the backup strategy is actually a business continuity decision. Systems, data, responsibilities, and recovery order need to be designated. It is not enough to say that "everything is backed up."

What should a working backup plan answer?

A usable plan should clearly state which servers, databases, user files, and cloud business applications are backed up. A common misconception is that using a SaaS system automatically means comprehensive data protection. The availability of the service and the long-term, detailed recoverability of the company's own data are not always the same.

The plan should also specify who gets alerted in case of a failed backup, who is authorized to initiate a restoration, and who decides from which backup point the recovery should occur. These responsibilities are especially important when a key person is on vacation, or the incident occurs outside working hours.

The retention time should be adjusted to business needs. A daily backup may be insufficient if many orders and financial transactions occur during the day. A few days' retention does not protect against an error that is only noticed weeks later. The number of versions, retention time, and restoration frequency together shape the risk and cost.

Special attention should be paid to the protection of backups. Encryption, multi-factor access, separate administrative accounts, and modification-protected backup copies are not excessive precautions. In a ransomware incident, these can determine whether a clean, usable state is available.

The recovery test is the only real proof

Most backup shortcomings are not revealed during the backup process but during recovery. The task may have a green status daily. Yet, there may be a faulty database backup, missing encryption key, undocumented dependency, or too slow restoration.

It is advisable to regularly conduct tests, not just restoring a single file. The complete restoration of a business-critical system should also be checked in an isolated environment. During the test, it becomes measurable how much time is needed to start the system, whether the necessary accesses are available, and what post-processing is required to check data consistency.

This test is not about blaming IT. The goal is that a real incident is not the first time the organization tries to perform the recovery.

The right balance aligns with the company's operations

A smaller business with few critical systems may suffice with a simpler but regularly checked local and cloud copy. A multi-site commercial or manufacturing company may need a more detailed recovery order, fast local backup, separate remote copy, and documented incident management.

The most storage capacity or the longest feature list does not mean security. A good decision starts from understanding exactly what work is halted by a system outage, who is affected, how much data is generated, and how quickly normal operations need to resume.

It is worth considering during a calm period: if the most important system does not start tomorrow morning, who could say from which backup, in what order, and how long it will take to restore work? If there is no clear answer to this, then a clearer operational plan is needed rather than new technology.