How to Migrate Legacy Nginx Sites and MySQL Databases to the Cloud: A Real‑World Walkthrough

Background and Motivation

The author seized a data‑center relocation to consolidate dozens of web and app projects that had been sharing a single Nginx configuration (over 40 include statements) and a common NFS directory plus a single physical MySQL server with multiple databases. Growing traffic exposed security and performance concerns.

Security and Performance Issues

All sites share the same NFS directory; a vulnerability in any one site could compromise the entire rack.

Scanning each site with security tools takes roughly a day, making regular audits impractical.

Database contention (locks, table freezes) caused all dependent services to stall when any single database experienced trouble.

Nginx Configuration Overview

user  www  www;
worker_processes    6;
worker_rlimit_nofile 51200;

events {
    use epoll;
    worker_connections 51200;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    client_max_body_size 500m;
    ...
    include vhosts/faxian.quanzhen.com.conf;
    include vhosts/www.quanzhen.com.conf;
    include vhosts/news.quanzhen.com.conf;
    ...
    include vhosts/default.conf;
}

Migration Plan

The plan was to move part of the workload to a public cloud, decommission old hardware, and virtualize the remaining high‑spec servers to reduce rack space and maintenance cost.

First Backup Attempt

Using Percona’s innobackupex tool, the author attempted a full backup of two databases:

[root@db-209 ~]# innobackupex --user=root --passwor='i%=KGb76' \
    --defaults-file=/etc/my.cnf \
    --databases="quanzhen_mobile7lockscreen quanzhen_equipment" /data/bakmysql/

The command started, created a backup directory, but the process took many hours and was halted before completion, forcing a split‑into‑two migration.

Second Attempt and Issues

After cleaning unused data, a second backup was run for a single database:

[root@db-209 ~]# innobackupex --user=root --passwor='i%=KGb76' \
    --defaults-file=/etc/my.cnf --databases="quanzhen_equipment" /data/bakmysql/

Log application succeeded quickly, but copying the backup to the target server was slowed by a 30 Mbps outbound link. The target server required an empty data directory before import.

Third Attempt and Workarounds

When the target already contained ib_logfile0 and ibdata1, the restore failed with errors such as:

innobackupex: Can't create/write to file '/data/mysql_db/ib_logfile0' (Errcode: 17 - File exists)
[01] error: cannot open the destination stream for ib_logfile0
[01] Error: copy_file() failed.

The author moved the existing files aside, then tried a direct copy of the exported files, adjusted permissions with chown, and finally started MySQL successfully.

Lessons Learned

The migration highlighted the need for dedicated test servers, proper bandwidth planning, and a clear, repeatable backup‑restore procedure. Despite multiple failed attempts and ad‑hoc fixes, the data was eventually verified as complete and the services restored.