Перенос сайта на другой хостинг

Клиент: Интернет-магазин косметики на 1С-Битрикс (Аспро: Максимум).
Проблема: Магазин работал на дешёвом виртуальном хостинге, который не справлялся с нагрузкой. В часы пик сайт открывался по 10–15 секунд, часто выпадала ошибка 503. Клиенты уходили, продажи падали.
Что сделано:

1. Анализ и подготовка: Проанализировал текущую конфигурацию хостинга: версия PHP 7.2, MySQL 5.6, слабый процессор. Порекомендовал клиенту перейти на VPS с характеристиками: 4 vCPU, 8GB RAM, SSD-диски. На новом сервере настроил аналогичное окружение (Linux, Nginx, PHP 8.1, MySQL 8.0).
2. Перенос файлов и базы данных: Сделал полную резервную копию всех файлов сайта и базы данных. Создал дамп базы данных и скачал его локально. Через SSH по rsync перенёс все файлы сайта на новый сервер. Это позволило сохранить права доступа и структуру папок. Импортировал базу данных на новом сервере.
3. Настройка окружения: Настроил Nginx и PHP-FPM под нужды Битрикс (оптимальные параметры памяти, процессов). Настроил версию PHP 8.1 и необходимые расширения (mbstring, gd, curl и др.). Скорректировал конфигурационные файлы сайта (.settings.php, dbconn.php), указав новые параметры подключения к базе данных.
4. Тестирование и запуск: Временно подменил файл hosts на своём компьютере, чтобы проверить работу сайта на новом сервере. Протестировал корзину, оформление заказа, личный кабинет — всё работало отлично, скорость загрузки страниц выросла в 3 раза. После успешного тестирования перенастроил DNS-записи домена на IP-адрес нового сервера (с минимальным TTL, чтобы изменения быстрее вступили в силу). Настроил автоматический редирект со старого сервера на новый (на случай, если кто-то попадёт на старый IP).
5. Результат: Сайт переехал с нулевым простоем. Скорость загрузки страниц увеличилась с 10–15 секунд до 2–3 секунд.

Клиент: Сайт адвокатского бюро на WordPress.
Проблема: Хостинг-провайдер заблокировал аккаунт клиента из-за превышения лимитов по CPU (сайт атаковали ботами). Доступ к панели управления и FTP был закрыт, сайт не работал. Клиент терял заявки.
Что сделано:

1. Анализ и подготовка: Связался с техподдержкой старого хостинга, объяснил ситуацию. Они дали временный доступ к FTP и phpMyAdmin только для скачивания данных. Арендовал новый хостинг с более высокими ресурсами.
2. Перенос файлов и базы данных: Через FTP скачал все файлы сайта (это заняло время из-за медленного канала). Через phpMyAdmin сделал дамп базы данных (она была небольшой). На новом хостинге создал базу данных и загрузил туда дамп. Через FTP залил все файлы.
3. Настройка окружения: На новом хостинге настроил версию PHP 8.0 (совместимую с сайтом), проверил права доступа к папкам.
4. Тестирование и запуск: Временно настроил файл hosts, чтобы проверить сайт. Обнаружил, что плагин кэширования конфликтует с новыми настройками сервера — отключил его, сайт заработал. Перенастроил DNS-записи домена на новый хостинг (попросил клиента это сделать, так как доступ к DNS был у него). После обновления DNS сайт стал доступен всем.
5. Результат: Сайт восстановлен. Клиент избежал длительного простоя и потери репутации. На новом хостинге были установлены защиты от бот-атак (файрвол, ограничение по IP).

Клиент: Сервис по бронированию отелей на Django.
Проблема: Текущий хостинг-провайдер переставал устраивать по качеству техподдержки и цене. Клиент решил переехать на другую площадку, но база данных была большой (50 ГБ) и сайт нельзя было останавливать надолго.
Что сделано:

1. Анализ и подготовка: На новом VPS настроил точную копию окружения: ту же версию Ubuntu, Python, PostgreSQL, Nginx. Проверил совместимость версий.
2. Перенос файлов и базы данных (без длительного простоя): Использовал rsync для синхронизации файлов сайта на новый сервер в фоновом режиме, пока старый работал. Для базы данных настроил репликацию между старым и новым сервером PostgreSQL, чтобы данные синхронизировались в реальном времени. Когда репликация была настроена и работала, остановил старый сервер на 10 минут (режим «только чтение»), дождался окончательной синхронизации, переключил реплику в основной режим.
3. Настройка окружения: Настроил Nginx на новом сервере, прописал конфигурацию для Django (через Gunicorn). Настроил SSL-сертификат.
4. Тестирование и запуск: Проверил работу сайта по временному домену. Протестировал бронирование, личный кабинет. Перенастроил DNS-записи на новый IP (TTL был установлен низким заранее). После переключения DNS мониторил логи и ошибки в течение нескольких часов.
5. Результат: Сайт переехал с общим простоем менее 15 минут. Все данные сохранены, клиент не потерял ни одного бронирования. Экономия на хостинге составила 30% в месяц.