Перенос сайта с хостинга на выделенный сервер

Создание временного домена

Более простым вариантом для нас будет создать временный поддомен на вашем сайте, например n.site.ru.
• Для этого нам надо добавить новую запись DNS. В панелях управления cPanel, DirectAdmin, ISPmanager присутствует возможность редиктирования DNS зон.
Поэтому открываем редактирования DNS в вашей панели управления, выбираем нужный домен и добавляем новую запись типа A: n (или n.site.ru.) с IP адресом сервера, на который собрались переносить свой сайт. Обратите внимание на точку в конце доменного имени, если вы будете прописывать домен полностью. В случае, если в вашей панели нет редактирования DNS, можете смело обратиться к вашему хостеру с просьбой добавить запись к вашему доменному имени. Не пишите сразу в тех. поддержку, что вы собираетесь съезжать с их хостинга, у них пропадет желание помогать Вам.
• Если Вы используете DNS сервер регистратора доменного имени, то делайте это в панели управления доменом.
• Можете так же воспользоваться другим доменным именем, если у Вас нет возможности отредактировать DNS зону.

На обновление DNS записей возможно потребуется некоторое время, обычно не дольше 15 минут. Не пробуйте сразу открыть в браузере сайт по новому домену, т.к. записи DNS еще не успеют обновиться и у Вас будет отображаться старый сайт. Лучше воспользуйтесь сторонними сервисами для проверки ip адреса по доменному имени (например wservice.info).
Внимание: менять основные DNS записи (www.site.ru и @.site.ru) будем только после полного переноса сайта!

Подготовка к переносу

Далее нам нужно определиться — отключить возможность регистрации, создания тем, сообщений и т.д. или же на время переноса показывать для всех пользователей сообщение о проведении технических работ на сервере.
• В первом случае нам надо не дать возможность пользователям сделать запрос на обновление информации в базе данных, либо в файлах самого сайта. Отключаем это либо в админцентре или путем правки (временного удаления или переименовывания) файлов движка.
• Если Вы не хотите все это делать, то можно отобразить страницу о проведении технических работ на сервере, желательно так же указать время завершения.
Для этого на сайте создаем файл: index.html и пишем в нем следующее сообщение:

На сервере проводятся технические работы, ориентировочное время завершения: ….

или скачайте готовый шаблон: [attachment=7]
Так же добавьте в .htaccess следующие строки:

DirectoryIndex index.html
RewriteEngine On
RewriteRule ^(.*)$ /index.html [R]


При желании можете так же полностью отключить сайт в адмицентре (если движок поддерживает данную функцию).

Создание бэкапов для последующего переноса

Сайт отключен, теперь можно начинать сам процесс переноса.
Чтобы быстро перенести сайт с одного сервера на другой мы создадим архив со всеми нашими файлами и сделаем бэкап нашей базы данных (тоже в архиве).
Перед созданием архива настоятельно рекомендую очистить все папки с кешем (например кеш шаблонов или запросов к БД). Если сомневаетесь, лишние файлы лучше не удаляйте.
В некоторых случаях могут возникнуть проблемы с доступом к данным файлам. Если вы этого не сделаете сразу, это можно будет исправить уже на новом сервере.

Если хостер предоставил доступ к шеллу (SSH), тогда будем работать именно с ним, ну а если у вас есть доступ только к FTP и панели управления, тогда прочитайте предыдущую статью про резервное копирование сайта в cPanel, DirectAdmin, ISPmanager вместо данного пункта.

И так подключаемся к серверу через shh клиент (я использую putty: [attachment=8])
Открываем директорию сайта (путь для cPanel):

cd /home/site/public_html

И создаем архив:

tar -c * | gzip -9 > backup.tar.gz

У меня возникли небольшие проблемы при создании бэкапа, т.к. файлов было очень много и их размер составлял несколько гигабайт, сервер просто завершил процесс (Killed), поэтому я уменьшил степень компрессии с 9 до 1.
У Вас должно быть достаточно места для создания архива, т.е. в 2 раза больше, чем занимает весь сайт (файлы и база данных).

Чтобы ускорить процесс можете открыть параллельную сессию SSH (нажав правой кнопкой мыши по заголовку окна и выбрав пункт в меню Duplicate Session) и сделать дамп базы данных:

mysqldump -u user  -ppassword -B bd > /home/site/backup/bd.sql

Обратите внимание на отсутствие пробела после опции -p, сразу указываем пароль. В данном случае будет создан файл резервной копии, содержащий структуру и данные. Не забудьте изменить путь на свой.

После создания дампа заархивируем его:

tar -c bd.sql | gzip -9 > bd.tar.gz


Внимание, в момент создания архива или дампа ваш аккаунт будет создавать повышенную нагрузку на сервер!

Перенос файлов сайта на новый сервер

После того, как архивы готовы заливаем их сразу на новый сервер, делается это следующим способом:
Переходим в папку, в которой будет находиться наш сайт:

cd /home/site/data/www/site.ru

И скачиваем файл по протоколу HTTP или FTP (разницы в скорости нет):

wget http://site.ru/backup.tar.gz


Можно и на своем сервере открыть параллельную сессию и сделать импорт базы данных из дампа:

wget http://site.ru/bd.tar.gz

Распаковываем sql дамп:

tar xfz bd2.tar.gz

И импортируем его в нашу БД (по сути мы просто выполняем SQL запросы на вставку):

mysql -u bd_user -p bd_name < backup.sql

Пользователь и база данных должна быть создана перед импортом.
Если название базы данных на старом и новом сервере отличаются, то надо его исправить в нашем дампе, делается это очень просто.
Скачивать файл и редактировать его у себя на компьютере Вам не прийдется, все операции будем делать прямо на сервере.
Открываем файд bd.sql при помощи текстового редактора:

vi bd.sql


Ищем строки CREATE DATABASE и USE и меняем название нашей БД (для того, чтобы переключиться в режим редактирования нажмите 1 раз на клавишу Insert).
Они находятся в самом начале файла, если этих строк нет, значит нет никакой привязки к базу данных, можете смело закрывать файл (Esc, :q!) и делать импорт.
Затем сохраняем и закрываем файл: нажимаем на Esc, вводим :wq и нажимаем на Enter.

После того, как скачался архив нашего сайта, распаковываем его:

tar xfz backup.tar.gz

Если будут проблемы с правами (нет доступа к файлам или другой владалец файла), то выполняем следующую команду:

chown -hR user:user /home/site/data/www/site.ru

, где user — имя аккаунта на сервере, созданного для нашего сайта.
После этого проверьте права доступа на файлы, они должны сохраниться, в противном случае просто выставьте права на запись для соответствующих файлов и папок.

Не забудьте отредактировать файл конфигурации (config.php или dbconfig.php) для соединения с базой данных.

Заходим на наш сайт, который уже на новом сервере

Наш сайт уже доступен по адресу: http://n.site.ru
Созданный файл index.html удаляем, открываем .htaccess и удаляем добавленные нами строки:

DirectoryIndex index.html
RewriteEngine On
RewriteRule ^(.*)$ /index.html [R]


Если сайт был отключен через админцентр — включаем его.

А на старом хостинге в самом начале файла .htaccess прописываем следующее:

redirect temp / http://n.site.ru/?

temp — возвращает код 302 (документ перемещен временно) — это требуется для поисковиков, чтобы они не начали индексировать Ваш сайт с новым доменом.

Прописываем новые DNS

Осталось прописать новые DNS и через несколько часов у всех пользователей сайт будет доступен по старому доменному имени.

Не забудьте удалить все архивы (бэкапы), которые вы создавали как на старом, так и на новом сервере, чтобы никто посторонний не смог ими воспользоваться.
При создании бэкапов рекомендую использовать имена файлов вроде таких: backup6ckv4.tar.gz

Перенос сайта с хостинга на выделенный сервер: 0 комментариев

  1. 2 ошибки.

    1.
    временный адрес вообще не нужно создавать.
    достаточно сразу на новом хосте прописать домен второй раз. в новых ДНС. целиком. и сайт поднимать уже на основном домене сразу.

    тк домен будет делегирован к старым ns — то пользователи будут ходить по старому адресу. их это не коснется.
    а для того, что бы самому мониторить то, как сайт встал на новый хост — можно у себя поправить файлы hosts — куда вписать домен и новый ип адрес. что бы комп ходил на новый хост напрямую — не обращаясь к ДНС.

    2.
    делать какие-то заглушки для сайта и страницы о технических работах — глупость неимоверная — тк выпадут страницы (если поисковый бот спалит такую табличку).

    достаточно просто данному юзеру базы ограничить доступ на запись.
    ну и на каталоги (куда заливаются например картинки) поставить запрет на запись.

    в этом случае ПС вообще не заметит никаких изменений на сайте (в плане остановки его работы).

    с глюком столкнутется только часть аудитории, которая попытается именно что-то запостить на сайт.

    та часть посетителей — которая читает — не заметит переезда вообще.

  2. psih,
    Вобще-то речь идет о переносе сайтов (например форумов) с высокой посещаемостью, где каждую минуту регистрируется как минимум по 1 человеку.
    Я уж не говорю о количестве сообщений, которые появятся за сутки.
    Чтобы не заниматься синхронизацией базы данных приходится придумывать такие методы.

  3. вот именно.
    если регистрируется по 1 человеку, то сколько народу вы пропустите мимо своей "заглушкой".
    моя методика — без остановочная.
    разве что на 5 минут (когда база заливается на новый сервак).

    а что бы базу не синхронизировать.
    на старом хосте ТОЖЕ надо сменить настройки mysql.
    те старым хостом юзать удаленно базу с нового хоста.

    или вы такое и представить не могли?

  4. psih, оба сервера в разных странах и к тому же некоторые хостеры блокируют удаленные исходящие соединения на все порты, кроме 80, 443. Конечно же можно было попросить открыть порты, но не факт что вам их сразу же откроют после запроса.
    Это загрушка автоматически перенаправляет пользователей на новый временный адрес и многие даже ничего не замечают, а поисковикам говорит что это временно (например статусом 302).

    Напишите статью про свою методику, может быть она окажется лучше 🙂
    Помимо Бд надо будет синхронизировать статистический контент (или как вы предлагаете заливать файлы сразу на новый сервер, а лучше на оба, чтобы не возникло временных проблем со скачиванием).

  5. Вы сами себе противоречите.
    От того что сервера в разных странах или в одной комнате — разницы нету.
    Какие порты? Какая зависимость от хостера. Вы же сами сказали речь о высоконагруженных проектах где регистрации по 1 в минуте. Это что по вашему на шаред хостинге сидит?

    Про статический контент — лучше наверное ситуация когда несколько картинок не прогрузится, в течении получа часа ( чем целиком сайт отвалится ).
    Хотя, опять же для нормальных проектов статика раздаетсяы совсем с других сабдоменов img.site.ru и тд. Их переносить можно вообще отдельно и как угодно.

    В моей технологии простоя у сайта нет. Есть только невозможность запись в базу на короткое время (копирование базы в новый сервак).

    И еще. Опять же при переносит под высокой нагрузкой за несколько суток до этого меняются А записи (и устанавливатеся придельно малый TTL). И в процессе переноса меняют именно их, а уже затем сами ns (через пару суток после переноса сайта).

  6. Шаред хостинг — сервер, на котором 10 клиентов и с которого меня выгоняли за нагрузку (VIP хостинг).
    Я с Вами не спорю, что в вашем методе простоя нет — хотите, пишите про него, многим интересно узнать и про него.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *