Нудачный опты из-за удачного подхода

Доброго времени суток!

Я занимаюсь поддержкой нескольких интернет-проектов, почти все они физически находятся на сервере, который я обслуживаю (проектов примерно 5 штук и около 10 дочерних проектов).

Это маленькая история моей большой ошибки по миграции с одного сервера на другой.

Сервера менялись уже не раз, но всегда это происходило так:

1. Обзваниваем за несколько дней клиентов и сообщаем, что на выходных сайты работать не будут;
2. В админ панелях, на всякий случай, закрываем доступ к редактированию сайта (полностью перекрываем админ панель и закрываем комментарии);
3. В субботу заказываем новый сервер, настраиваем и начинаем переносить клиентов.

Обычно в воскресенье утром уже всё работало.

Эта схема работала на ура, потому что «клиенты», как я их ласково называю, это мои друзья и знакомые и все проекты не коммерческие, а в субботу я этим занимался потому, что именно в этот день недели было мало посетителей.

В этот раз было решено переехать со старенького Core i3 3.4ГГц (2 ядра) / 4Гб RAM / 2x500Гб SATA на более мощный Core i5 3.8GHz (4 cores) / 8Gb RAM / 2x500Gb SATA.

Что особенного было в этой миграции на новый сервер спросите вы? Отвечу: я придумал план как сделать переезд быстрее и при этом не закрывать сайты.

Какая у меня была идея:

1. Переносим БД;
2. В настройках сайта прописываем адрес БД не localhost а IP нового сервера;
3. Повторяем первые 2 пункта для каждого сайта. Что нам это даёт? А это нам убирает необходимость закрывать админ панели и комментарии;
4. Переносим все файлы на новый сервер;
5. Настраиваем bind на старом сервере, чтобы он перебрасывал все запросы на новый (имеются ввиду http запросы, при этом почта и ftp перестают работать, к сожалению). Сразу скажу, что на проектах используется почта Яндекса, Гугла и mail.ru. Почта исключительно для работы и никому она на выходных не нужна. FTP доступ есть только у администратора сайтов, т.е. только у меня;
6. Производим тонкую настройку Bind на новом сервере, чтобы работало так же как на старом или ещё лучше;
7. Меняем IP адреса на старом и на новом сервере местами и все рады, никто и не заметил подмены. Сначала мне казалось, что план гениален, и он не мог провалиться, но всё было не так то просто.

Я сразу написал хостеру про затею с заменой IP на серверах, мне сказали «плати и лети». Сразу скажу, что это была самая большая ошибка.

Все шаги до пункта 7 прошли легко и быстро, за 3-4 часа я всё сделал, после чего написал хостеру про смену IP.

После этого начались танцы с бубном.

Хостер ^[1] сообщил: «для назначения старого IP надо будет сервер в стойке переместить».
Надо – делайте!
Отключили оба сервера, некоторое время они были недоступны. Потом мне хостер ^[1] отписался, что всё сделано, IP поменяли, перезагрузили сервер и теперь всё будет работать. Я написал повторно и попросил назвать новые IP обоих серверов.

На старом сервере мне прописали неизвестно откуда взятые IP, но это и не важно, для меня главное – ip нового сервера, но и у нового сервера были непонятно какие IP. Пришлось позвонить в другую страну, чтобы по телефону накричать, что всё не так как надо.

Когда я позвонил хостеру, мне в тикет пришло сообщение «наш биллинг не позволяет менять IP на серверах. Мы оставили заявку разработчику, чтобы в биллинге перенесли IP».

Тогда-то я и понял, что идея была провалена хостером.

Итог:
Север не работал с обеда субботы и до вечера воскресенья (в тестовом режиме), в биллинге, на момент написания этой статьи (понедельник утро) информация отображается некорректно.

Выводы: не надейтесь на других, не изобретайте велосипед там, где он не нужен.

Если у вас есть идеи, как быстрее и менее затратно сделать миграцию отдельно стоящего сервера, буду рад прочитать это в комментариях.