If a server in Ukraine is unavailable, first establish which data and access you still have. An accessible source, a usable backup and no recoverable copy lead to different recovery plans. Provisioning another server can restore infrastructure capacity, but it cannot recreate missing application data.
This guide helps you prepare a recovery decision when the original environment cannot be relied on. It does not establish the current condition of a particular Kyiv facility or promise a restoration time. Obtain incident and access information directly from your affected provider, and keep the time and source of each update with your recovery record.
Keep three questions separate
- What is unavailable? Identify whether you have lost the application, network access, control panel, storage or the whole environment. An unreachable website alone does not establish physical damage.
- What can be recovered? Locate source access, independent backups, database exports, application files and credentials needed to decrypt or restore them.
- What must run first? List the business functions that need recovery, their dependencies and the data loss the responsible owner can accept.
Nominate one person to coordinate changes and preserve the original copies. Avoid multiple people restoring different versions into the same destination or independently changing public traffic.
Choose the branch supported by your evidence
The source is accessible
Arrange an authorized export or transfer while access is available. Record application versions, configuration, scheduled jobs and external dependencies alongside the data. If the application is still accepting writes, agree how those changes will be synchronized or paused; a copy taken earlier may omit later transactions.
The source is unavailable, but you have a backup
Check the backup's creation time, contents, encryption keys and restoration requirements. Preserve the original and work from a copy. Restore into an isolated destination and validate the application before treating the backup as usable.
Database recovery depends on the backup method. For example, PostgreSQL documents distinct SQL dump, file-system and continuous-archiving approaches. An ordinary copy of live database files is not automatically a consistent backup; its file-system backup documentation explains the shutdown or consistent-snapshot conditions. Follow the instructions for your own database and version rather than substituting a generic file-copy procedure.
Neither source nor usable backup is available
You can prepare an empty replacement environment and recover configuration from records, but do not describe that as recovered customer data. Ask the affected provider what access or recovery options actually exist. Document missing data and communicate the limitation to the business owner before reopening a service that could appear complete.
Prepare a compatible destination
Record the operating system, application and database versions, storage capacity, licences, access requirements and network dependencies. Match the workload rather than insisting on the same processor model. Confirm current availability and the scope of installation or restoration assistance before committing to a replacement.
Changing country also changes the service location. Check contractual and data-handling requirements before transferring sensitive information. No location label establishes privacy, regulatory compliance or immunity from complaints.
Validate recovery before changing traffic
Check representative reads and writes, authentication, scheduled jobs, mail or other integrations, and the completeness of important records. Disable or isolate actions that would send real messages, charge customers or duplicate background work during testing.
Record the point in time represented by the recovered data. Agree how gaps will be handled and who accepts them. Plan the public traffic change and what to do if validation fails. Keep the old environment and recovery evidence where available; do not erase the only remaining copy as part of cleanup.
Send a recovery brief, not just a hardware request
Your brief should state the unavailable service, accessible sources, backup age and format, essential dependencies, required destination resources and unresolved risks. The migration requirements checklist helps organize access and dependency information. For WebCare360 assistance, use the current contact options to confirm service scope and availability; agree the recovery steps and schedule from the evidence available.
