UA2.IEV: What Happened and How We Recovered

On September 23, 2026, russian forces carried out another attack against Ukrainian cities, including Kyiv. Datacenters and communications infrastructure were among the targets. Multiple facilities and network operators reported damage, and connectivity was disrupted for users across Kyiv and the surrounding region. Further strikes followed, forming what the OSW Centre for Eastern Studies described as attacks on critical digital infrastructure.

Our UA2.IEV location was affected. Most importantly, none of the datacenter staff were injured. The building and technical infrastructure, however, sustained damage. After the site had been inspected and the risks assessed, it became clear that continuing to operate the location in the near future would be neither practical nor safe.

The incident began at 11:10 EEST. At first, the physical condition of the equipment was unknown and emergency services were still working at the site. We published updates as information became available, while our team prepared for the possibility that the equipment would not return online quickly.

This article explains what we did next, why recovery differed between service types, and what the incident demonstrates about backups and disaster recovery.

One damaged location, many recovery options

ITLDC operates infrastructure across many datacenters. That gave us an important advantage: once it became clear that UA2.IEV could not safely resume normal operation, we did not have to wait for the building to be repaired before helping customers. We could move services, restore data, and provide replacement hardware at other locations.

This was not a single migration button. UA2.IEV hosted two fundamentally different kinds of service: virtual servers and bare metal dedicated servers. Even within the VDS platform, current and legacy systems required different recovery procedures.

Recovering current VDS instances

Our current VDS platform uses a multi-level backup system. Fast copies are written to separate buffer servers within the datacenter, while backup copies are also transferred to specialised cold-storage systems. These systems are logically and physically separate from the main infrastructure.

Local copies are useful when a compute node fails but the location remains available. Cold storage exists for the less pleasant scenario in which the location itself cannot be used. Unfortunately, this incident was the second kind.

When restoring a virtual machine at another independent location, more changes are involved than simply starting the same VM elsewhere. The replacement receives infrastructure parameters appropriate to the destination, including a new MAC address and, in some cases, a new IP address. Restoring the data is also a separate operation and takes longer than activating an empty replacement VDS.

We therefore began providing replacement virtual machines on request, either with data recovery or without it when the customer could restore faster from their own backup. In parallel, we started restoring available cold-storage copies to unaffected EU locations.

We withdrew the affected BGP announcements from the unavailable Ukrainian infrastructure and began announcing parts of those networks from other ITLDC datacenters. Where technically possible, this allowed us to preserve existing IPv4 addresses and Ukrainian GeoIP information. In some cases, changing the address was necessary or substantially reduced recovery time.

By September 25, approximately 70% of current NVMe VDS instances had been restored. By the final status update on September 28, all services on the current SSD and NVMe platform had been migrated and were running at other locations. Only a very small number still required an IPv4 change or individual assistance.

Legacy VDS needed a different route

The legacy VDS platform uses a previous-generation hypervisor and a simpler backup scheme. Its backup format is not directly compatible with the current platform, so those virtual machines could not be restored through exactly the same process.

The legacy environment represented less than 5% of the affected virtual servers, but each recovery required additional work. Our engineers restored and converted nearly all available legacy instances to the current management platform. Where conversion or recovery was not possible, we provided a replacement VDS with the same or better resources.

Most legacy services received new IPv4 addresses. This was not as seamless as preserving every network parameter, but it was the practical route to getting services online without waiting for uncertain access to the damaged site.

Older platforms have a habit of making themselves memorable during emergencies. This is one reason infrastructure migrations should happen while the old system is still quietly working, rather than when the building around it has other plans.

Replacing bare metal servers

A virtual machine can be recreated on another compatible cluster. A dedicated server is physical equipment bolted into a rack, which makes geographic migration a rather less virtual exercise.

We provided affected bare metal customers with replacement dedicated servers at our other European datacenters. The replacements had equivalent or better configurations. Where the condition of the original equipment and local safety procedures allowed it, we also arranged access to data from the disk subsystems of the old servers.

Provider recovery is not a customer backup

Our backup layers helped us restore the current VDS platform at another location. They should not be confused with a customer-controlled backup strategy.

Creating backups of important data, transferring them to geographically separate storage, checking their integrity, and periodically testing restoration remain the customer’s responsibility. Provider-side recovery protects against certain infrastructure failures. A customer backup protects the application and its data according to the customer’s own recovery requirements. These mechanisms complement each other; one does not replace the other.

If the only copy of a backup is in the same datacenter as the production server, both may become unavailable in the same incident. That is a second copy, but not much of a disaster-recovery plan.

ITLDC offers HD VDS with large HDD storage in several locations, which can be used as one component of an off-site backup system. Choose a location separate from the production service, encrypt sensitive backups, monitor each backup job, and perform test restores. A green “completed” message is encouraging; a successfully restored application is evidence.

A useful recovery plan should answer a few simple questions before an emergency:

• Where is the latest independent copy of the data?
• How old can that copy be without causing unacceptable loss?
• How long does a full restore take?
• Which credentials, DNS changes, licenses, and external services are required?
• Who can perform the recovery if the usual administrator is unavailable?

These questions are much easier to answer during a normal working day than while an incident page is being refreshed every thirty seconds.

What happens next

We are building a new location for Ukrainian services. During the initial stage, the infrastructure will be physically hosted in the EU. Network capacity toward Ukrainian internet exchange points has already been prepared, providing efficient and secure connectivity and allowing Ukrainian GeoIP to be retained where required.

This arrangement lets us bring the platform online without depending on the damaged UA2.IEV facility. More information about the new location will be announced soon.

The loss of a datacenter is one of the most serious scenarios an infrastructure operator can face. In this case, having multiple locations, independent storage, available hardware, established network relationships, and engineers able to work across several recovery paths made the difference. Current VDS instances were migrated, legacy machines were converted or replaced, and bare metal customers received replacement servers.

We thank the datacenter staff, emergency workers, network partners, engineers, and customers for their help and patience throughout the recovery.