A customer needed to migrate projects from a server with a severely damaged disk. The source server was still partially accessible, but the storage had already lost part of the data and could no longer be treated as a reliable source for a standard migration. There were also no usable recent backups for one of the affected WordPress websites. The priority was therefore not simply to move the server. The Unihost support team had to recover as much information as possible from the damaged storage, preserve the latest available versions of the customer’s data and code, and rebuild the components that could no longer be recovered.<\/span><\/p>\n A normal server migration assumes that the source environment is internally consistent. Application files, databases, configuration files, and system data can usually be copied to the destination and then validated. A migration from damaged storage is different. Some files may still be readable, while others may be incomplete or permanently lost.<\/span><\/p>\n This creates several risks:<\/span><\/p>\n <\/p>\n In this case, the WordPress installation had suffered significant file loss. Because no suitable backup was available, simply copying the remaining data to a new server was not enough to restore the website.<\/span><\/p>\n 1. Recovered as much data as possible from the damaged server<\/b><\/p>\n The first objective was to preserve everything that could still be read from the source disk. Rather than immediately rebuilding the project from scratch, the team copied the available project data from the damaged server. This was important for two reasons. First, it reduced the amount of manual reconstruction required later. Second, it helped preserve the most recent available versions of customer files, configuration, and application data instead of replacing the entire project with older or generic copies.<\/span><\/p>\n 2. Identified missing and damaged application components<\/b><\/p>\n After transferring the recoverable files, the migrated applications were tested. Some applications failed to start because parts of their original data or configuration had been lost. For the affected WordPress website, significant portions of the WordPress application files were no longer available from the damaged disk. The website could therefore not be restored by migration alone.<\/span><\/p>\n 3. Rebuilt the WordPress core<\/b><\/p>\n The support team reconstructed the missing WordPress core files using the official WordPress installation archive. The objective was to restore the standard application components without overwriting customer-specific content that had survived the disk failure. This allowed the team to rebuild the application framework around the data that could still be recovered.<\/span><\/p>\n 4. Restored the required plugins<\/b><\/p>\n Some plugin files had also been lost. Where possible, the missing plugins were restored from their official distribution sources. The recovered website was then checked to ensure that the application could load the required components and that the remaining customer data was still usable.<\/span><\/p>\n 5. Corrected configuration issues after migration<\/b><\/p>\n Because the recovered environment was assembled from both surviving data and restored application components, configuration inconsistencies had to be identified and corrected manually. The team reviewed the application configuration and adjusted the affected components until the WordPress site could start and operate normally again.<\/span><\/p>\n 6. Tested the recovered website<\/b><\/p>\n After the WordPress core, plugins, and configuration had been restored, the website was tested on the new environment. The validation focused on confirming that the application started correctly and that the recoverable customer data remained available.<\/span><\/p>\n When the source storage is healthy, migration is mainly a transfer and validation task. With a failing disk, migration becomes a recovery operation.<\/span><\/p>\n The main objective changes from copying everything to determining:<\/span><\/p>\n Reinstalling the entire WordPress site from scratch would have been faster technically, but it would also have increased the risk of losing the latest customer-specific state. Recovering the usable parts first helped preserve as much of the original environment as possible.<\/span><\/p>\n The incident also highlighted the importance of maintaining backups outside the production server. A backup stored only on the same physical server does not provide sufficient protection against disk failure. After the website had been restored, the Unihost team configured an additional backup process using remote storage. This ensured that future recovery would not depend solely on the condition of the production disks. The backup environment was separated from the source server so that a hardware failure affecting production storage would not also destroy the recovery copy.<\/span><\/p>\n The work included damaged-disk migration assistance, recovery of readable project data, application troubleshooting after migration, manual WordPress recovery, WordPress core restoration from official sources, plugin restoration, configuration correction, website validation, and remote backup configuration.<\/span><\/p>\n The WordPress website was successfully restored despite significant data loss on the original server and the absence of a usable backup. The team preserved as much information as possible from the damaged disk, manually rebuilt the missing WordPress components, corrected the application configuration, and returned the website to working condition. A remote backup was also configured to reduce the risk of a similar incident becoming a manual recovery project in the future.<\/span><\/p>\n <\/p>\n Results at a glance<\/b>: recoverable data preserved, WordPress core rebuilt, missing plugins restored, application configuration corrected, website returned to operation, remote backup added after recovery.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" Initial situation A customer needed to migrate projects from a server with a severely damaged disk. The source server was still partially accessible, but the storage had already lost part of the data and could no longer be treated as a reliable source for a standard migration. There were also no usable recent backups for […]<\/p>\n","protected":false},"author":7,"featured_media":9213,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49],"tags":[],"class_list":["post-9207","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-case-study","has-post-title","has-post-date","has-post-category","has-post-tag","has-post-comment","has-post-author",""],"yoast_head":"\nTechnical Challenge<\/b><\/h2>\n
\n
What the Unihost Team Did<\/b><\/h2>\n
Why Recovery Was More Complex Than a Normal Migration<\/b><\/h2>\n
\n
Preventing the Same Problem<\/b><\/h2>\n
Unihost Support Work<\/b><\/h2>\n
Result<\/b><\/h2>\n