Перенос сайта на другой хостинг. Миграция битрикс

МИГРАЦИЯ САЙТА НА «1С-БИТРИКС» - Компания «IT Perfect Service»

Большое количество сайтов в интернете работают на бесплатных CMS или разработаны без использования CMS вовсе. Такие сайты написаны отдельными частными программистами или небольшими веб-студиями. У владельцев подобных сайтов постоянно возникают проблемы с поддержкой и развитием таких сайтов после того, как контакт с разработчиком утерян. Отыскать специалиста или веб-студию, которые возьмутся за поддержку, развитие или доработку такого сайта практически не возможно.

Чтобы избежать подобных проблем компания «IT Perfect Service» предлагает услугу по переносу сайта на CMS 1С-Битрикс. Перенос сайта может быть осуществлён с сохранением дизайна сайта или изменён по усмотрению заказчика.

На что рассчитывать после переноса сайта на CMS 1С-Битрикс

Сделать перенос сайта на 1С-Битрикс - означает убрать проблему с поиском администратора или разработчика для своего сайта. Партнёрская сеть компании «1С-Битрикс» насчитывает уже более 4000 профессиональных веб-студий, дизайн-студий, интеграторов, хостинг-провайдеров и других компаний, которые имеют опыт разработки, администрирования, поддержки и хостинга для CMS 1С-Битрикс.

Что нужно учесть при переходе на CMS 1С-Битрикс

Как уже упоминалось, «1С-Битрикс» платная система. Имеется несколько редакций с разными возможностями. Нужно выбрать подходящую для Вас редакцию и приобрести лицензионный ключ для неё. Уточнить подходящую для Вас редакцию можете позвонив в службу поддержки компании «IT Perfect Service» по телефону +7(499)346-62-38.

Следующим необходимым моментом при переходе на CMS 1С-Битрикс – является хостинг сайта. Для данной CMS нужен специализированный хостинг, рассчитанный на высокие нагрузки и с особыми настройками. При приобретении лицензионного ключа через компанию «IT Perfect Service» Вы получаете 1 год бесплатного хостинга!

Компания «IT Perfect Service» обладает всеми ресурсами для решения задач разработки, администрирования и хостинга сайтов на CMS 1С-Битрикс.

Если Вы хотите узнать дополнительную информацию о переносе Вашего сайта на 1С-Битрикс - позвоните оператору тех. поддержки компании «IT Perfect SERVICE» по телефону +7(499)346-62-38.

itisperfect.ru

Беседа о миграциях - Битрикс-Эксперты bitrix.expert

Михаил Журов [6:17 PM] Все мы знаем и понимаем всю необходимость и важность отделения кода приложения от базы данных. Так если посудить, то много чего из битрикса не нужно разработчику, однако оно попадает к разработчику все равно по разным соображениям. Но что делать, если наша замечательная и любимая платформа обязывает нас поступать так, как мы поступаем? :simple_smile:Поделитесь, как много у вас проектов, которые используют миграции для развертывания? Какие инструменты для создания миграций используете (кроме worksolutions/bitrix-module-migrations)? Каким образом осуществляется rollback (возможно ли при переходе по истории разработки в версионном контроле откатить и БД к нужной версии)? Каким образом выполняете наполнение БД тестовыми данными? С какими проблемами сталкивались при использовании миграций в битриксе? Даете ли вы в этом случае своим заказчикам доступ к настройкам дефолтных компонентов, где они сами без особого труда смогут поменять ID инфоблока, например?Тема очень важная и щепетильная, у вас, видимо, есть опыт по решению этих проблем, и я был бы очень признателен, если бы вы поделились своим опытом на этом поприще.

Nik Samokhvalov [6:30 PM] worksolutions/bitrix-module-migrations не использовал. Штука интересная, но предпочитаю более проверенные решения. Был проект с yii2-мигратором (мопед не мой, но работало прекрасно). А так, использую Phinx (http://samokhvalov.info/blog/all/phinx-multiple-databases/). В популярных инструментах и интеграция с консольным приложением, и откаты, и просмотр истории. Всё включено :simple_smile:

Контент может набиваться разными способами. Либо тупо дамп боевых табличек. Либо консольная команда, которая забьёт тестовыми данными ваши таблички. Есть даже fake-библиотеки для этого.

Никаких проблем с использованием миграций не возникало.> Даете ли вы в этом случае своим заказчикам доступ к настройкам дефолтных компонентов, где они сами без особого труда смогут поменять ID инфоблока, например?Я считаю, что это плохо, если клиент полезет менять айди инфоблока. Это изменение логики приложения, которое без ведома разработчиков производиться не должно. Но тем не менее, даже если такое произойдёт, ничего страшного не случится, если в настройки компонента будет сохраняться символьный код, а не идентификатор.(edited)

> Но что делать, если наша замечательная и любимая платформа обязывает нас поступать так, как мы поступаем?@mikhail_zhurov: не поддавайтесь!

Игорь Цупко [6:36] >С какими проблемами сталкивались при использовании миграций в битриксе?

Основная проблема, связанная с миграциями в Битриксе - это отсутствие в Битриксе работы с консолью, как понятия.Ибо миграции могут выполняться долго и даже очень долго. Запускать тяжёлые процессы с веб-интерфейса - это зло.Но к счастью мы это победили и в скором времени презентуем миру наше решение в виде модуля.

Nik Samokhvalov [6:39 PM] А, кстати. Из минусов Финкса: 1) в названия классов не подставляет таймстамп, поэтому приходится следить, что бы названия миграций были уникальными; 2) конфиги умеет читать только из yml-файлов.

Игорь Цупко [6:42 PM] >Каким образом осуществляется rollback (возможно ли при переходе по истории разработки в версионном контроле откатить и БД к нужной версии)?

Одна из интереснейших вещей касательно rollback-а вскрывается на многосерверных конфигурациях. При корректной организации процесса rollback-и не так критичны (хотя я не говорю, что их не надо писать, отнюдь!)

Смотрите:У вас есть несколько нод. Пока вы обновляете одну ноду - остальные продолжают работать и отдавать клиенту контент. Задумайтесь: ваша база и код должны быть совместимы при переходе в рамках одной версии.Если вам нужно переместить данные из одной таблицы в другую, вы не можете просто сделать alter table - ведь другие ноды всё ещё смотрят на старую таблицу.

Михаил Журов [6:53 PM] @nik.samokhvalov: А как вообще выглядит расширение для Финкса? Судя по дефолтным примерам Финкс работает на уровне таблиц. Тогда я вижу 2 варианта - либо кодить миграции именно на уровне таблиц, возможно с помощью каких-то инструментов, которые возможно предоставляет Phinx. Либо каждая миграция это пара из 2х скриптов (функций/классов/методов, нужное подчеркнуть), один из которых, грубо говоря, создает инфоблок/группу пользователя/каталог через API битрикса, а другой - удаляет. Так? Может примерчик на gist? :simple_smile:

Получается, что это и есть «те самые» скрипты миграции, которые использует битрикс при обновлениях, только с интерфейсом в виде консоли, а не веб-морды в админке, только разве что поддерживается переход в обе стороны, а не в одну. В этом плане инструмент от WS выглядит несколько интереснее, поскольку может «записывать» действия по добавлению новых сущностей и воспроизводить их на другой платформе (но не знаю, сможет ли этот инструмент выполнит реверс)

Ivan Tsirulev [6:53 PM] @may-cat Пример не совсем понятный. Имеется ввиду применение open/closed принципа в контексте модели данных? При миграции разрешено дополнять базу данных новым, но запрещено изменять существующее?(edited)Если так, то подтверждаю — это единственный способ "выжить" в многосерверной среде.И в этом случае нужды rollback практически нет. Любые изменения в базе будут совместимыми со старым кодом.

Nik Samokhvalov [6:56 PM] > один из которых, грубо говоря, создает инфоблок/группу пользователя/каталог через API битрикса, а другой - удаляет. Так?Всё так. В одном классе описываются методы `up()` и `down()`. Разработчик должен сам прописать алгоритм создания инфоблока / группы пользователей / веб-формы / таблицы в БД. И откат.> Получается, что это и есть «те самые» скрипты миграции, которые использует битрикс при обновлениях, только с интерфейсом в виде консоли, а не веб-морды в админке, только разве что поддерживается переход в обе стороны, а не в одну.Разве у Битрикса есть такой инструмент? Его «инструмент», на сколько мне известно — `updater.php`. Топорный ПХП-файл, который выполнится при накатывании обновления.Никакой версионности, никакой истории, никаких откатов…

Михаил Журов [6:59 PM] а я и не назвал это «инструментом» :simple_smile: я назвал их «скриптами миграции», которые рекомендует использовать команда разработки битрикса в своем курсе. Откатов - нет. История, скорее всего, есть, но у битриксоидов

Михаил Журов [7:09 PM] А как вы поступаете, если на ваших тестовых данных проблема не моделируется, а моделируется только на данных с прод сервера? Скажем, ошибка появляется только у группы товаров, которые находятся на 5м уровне вложенности каталога только у тех товаров, которые имеют в своем названии какой-нибудь специальный символ (но понятно, что вы этих кейсов заранее не знаете). Каким образом осуществляется перенос нужных данных с прода на дев?или же вы не переносите ничего, а пытаетесь воспроизвести проблему у себя любой ценой, даже если не получается этого выполнить в течение длительного времени?

Nik Samokhvalov [7:19 PM] Как правило (по крайней мере, у меня так было), получается воспроизводятся на деве: смотришь, что есть на проблемной площадке и воссоздаёшь похожую ситуацию у себя. В противном случае, да, выкачиваем нужные таблички и моделируем окружение у себя. Но это редкость.

Ivan Tsirulev [7:21 PM] Полагаю, у каждой команды свой подход. Опишу наш:

- Обязательно используется сервер разработки, где, собственно, все и работают. Для приверженцев локальной разработки подойдет вариант использования сервера базы данных внутри сети, что позволит работать с файлами локально.

- Каждая задача относится либо к поддержке (решение существующих ошибок), либо к разработке (расширение функциональности).

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

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

Михаил Журов [7:22 PM] @nik.samokhvalov: А много ли времени отнимает операция по воспроизведению данных с прода на деве в типичной ситуации (без переноса таблиц)

Ivan Tsirulev [7:22 PM] При решении ошибок (задачи поддержки) надобности в сохранении данных изо дня в день нет. Потому полная переливка БД — допустимое и практичное решение.

Игорь Цупко [7:23 PM] Добавлю также, что значительную часть проблем можно продиагностировать, не вмешиваясь в исходный код/данные, если иметь достаточный кругозор. Этим должны заниматься специально обученные люди. И заниматься они этим могут даже на боевой базе.

Nik Samokhvalov [7:25 PM] Эм… Зависит от проблемы. Что-то можно воспроизвести на раз-два, что-то чуть дольше. Как верно заметил Игорь, иногда не обязательно даже запускать приложение, что бы обнаружить косяк, как бы грустно это не звучало :simple_smile:

Ivan Tsirulev [7:28 PM] И это подводит нас ко второй по значимости вещи при разработке — обязательному логгированию всего и вся. Наверное прозвучит экстремально, но я твердо верю, что проект можно считать поддерживаемым, только если совокупные размеры его логов превышают размер файлов и базы вместе взятых. И лучше в несколько раз.

Игорь Цупко [7:29 PM] а также мониторингу всего и вся, что плохо и хорошо привинченовообще всегоесли проблема возникла, а по результатам инцидента в мониторинге или тестах не появилось проверки - с высокой вероятность что-то организовано не так.(edited)

Ivan Tsirulev [7:31 PM] Именно. Из опыта, результатом решения где-то половины ошибок становится не только непосредственное решение, но и появление нового мониторинга.

Михаил Журов [7:41 PM] @ivan.tsirulev Иван. А вы тестовую базу обновляете с прода в автоматическом режиме? Какими инструментами пользуетесь для регулярного обновления?

Ivan Tsirulev [7:43 PM] На простых проектах — простыми bash скриптами, которые забирают свежую резервную копию "оттуда" и разворачивают ее "здесь". На непростых проектах — лютыми самописными bash скриптами и нестандартными топологическими решениями. Непростые проекты — это где размер базы от 500 Гб и более.

Ivan Tsirulev [7:46 PM] Предвосхищая возможный вопрос: развертывание четырех копий БД размером в 500 Гб в среде разработки занимает от 3 часов до 3 часов 20 минут, в зависимости от погоды. Время развертывания зависит от размера линейно. Процесс происходит ночью.

bitrix.expert

Миграция Bitrix с 7 версии на 11

Есть у нас заказчик один, у него большой развесистый сайт был на битриксе седьмой версии. А битрикс седьмой версии, как известно, вышел давным-давно, и мы подчас сталкивались с какими-то косяками, которые были исправлены в более поздних версиях. Более того, приходилось дописывать вручную всякую функциональность, которая в более поздних версиях появилась, а в седьмой ещё не было. Самое ужасное, на что пришлось пойти - мы подменили модуль main на модуль, взятый из девятой версии, как раз по этим причинам (более свежий вариант модуля main уже не работал после имплантации). Такое довольно необычное монстрообразные сооружение существовало до недавнего времени, потому что мы уговорили заказчика обновить битрикс до самого свежего, одиннадцатой версии.

Процесс обновления от версии к версии мы решили не проводить, а купить новый битрикс редакции "Эксперт", и накатить на него контент со старого сайта. Для этого мы развернули у себя две дополнительные площадки, на одной - клон промышленного сайта заказчика, на второй - свежеустановленный битрикс одиннадцатой версии. На него мы накатили всю публичную часть, и принялись смотреть, что ещё где не работает.

Перенос инфоблоков осуществляли через экспорт в XML со старого сайта и импорт в XML на новом. Разумеется, у них поменялись идентификаторы, и по всей публичной части пришлось лазить и везде их менять, потому что в битриксе везде по умолчанию привязка к ID. Веб-формы мы просто перенесли, сделав дамп отдельных таблиц, и накатив их на новый сайт. Точно так же мы поступили с почтовыми шаблонами, но тут нас ожидала засада. Во-первых, таблицы почтовых шаблонов в одиннадцатой версии имеют дополнительные поля, мы их добавили руками. Во-вторых, что оказалось не сразу очевидно, идентификатор сайта на старом сайте был "ru", потому что на седьмой версии битрикса (или даже более ранней, потому что у заказчика сайт давно, и он, может, с пятой или шестой обновлял его до седьмой несколько лет назад), а на новом по умолчанию создался "s1". Разумеется, вся привязка почтовых шаблонов к сайту побилась. Мы заметили это не сразу, пришлось вынимать данные, которые пользователи вносили в веб-формы, формировать из них неотправленные письма, и рассылать.

Экспорт и импорт пользователей в битриксе по вполне понятным причинам не предусмотрен. Мы поступили с пользователями и группами точно так же, как с веб-формами и почтовыми шаблонами - накатили дампы таблиц на новую базу, а потом добавили в них новые в одиннадцатой версии поля.

Ну а потом обнаружили, что у заказчика на сервере стоит Zend Server с PHP версии 5.1, в то время, как у нас уже на всех площадках 5.3. И на версии 5.1 отвалился визуальный редактор страниц. Путём долгих поисков я обнаружил, что дело в классе CMain, в том месте, где начинается буфферизация вывода при обработке каких-то аяксовых случаев. На PHP версии 5.1 в этом месте интерпретатор то ли выпадал с подавленной ошибкой, то ли просто не отдавал начатый буффер при закрытии. Поправил код ядра, и забыл об этом. И спустя пару дней закачик поставил себе обновления на сайт и, конечно, мои изменения затёрлись. Я их вернул (одну строчку закомментировать, главное - знать, какую), починив визуальные редакторы PHP и HTML, а самый главный визуальный редактор текста и стилей так и не починился. Написал в ТП битрикса, хотя не питаю надежд на вразумительный ответ.

blog.axshavan.cz

Перенос сайта на другой хостинг 1C Битрикс

Сегодня научимся грамотно переносить сайт, сделанный на Битрикс с одного хостинга на другой хостинг или VPS/VDS.

Вообще, без разницы куда переносить, предварительные настройки сделать все равно придется в обоих случаях.

Итак, имеем рабочий сайт на Битрикс и готовый купленный хостинг, куда переносить сайт, доступы к новому хостингу имеются, остается только перенести сайт.

Реально существует ЧЕТЫРЕ способа переноса сайта на другой хостинг

Создание локальной резервной копии сайта и перенос на новый хостинг с помощью WinSCP.
Восстановление резервной копии сайта на новом хостинге из облака "1С-Битрикс".
Создание локальной резервной копии сайта и перенос на новый хостинг с помощью консольной программы в Linux для загрузки файлов "wget".
Синхронизация сайта на другой хостинг с помощью консольной программы в Linux для синхронизации файлов и каталогов "rsync".

Предварительное тестирование сервера/хостинга

Перед тем, как переносить сайт, место назначения (Сервер/Хостинг) необходимо протестировать скриптом БУСТЕСТ

Все выявленные проблемы скрипт подсветит красным цветом, зеленым цветом будут подсвечены корректные настройки, которые не требуют вмешательства, а вот красные надо исправлять.

Вообще, вы можете восстановить как-нибудь Битрикс с некорректными настройками сервера, но велика вероятность, что будут потом проблемы всплывать или что-то будет работать неправильно на сайте, лучше исправить, особенно если кодировка сервера отличается от кодировки сайта.

Если хостинг/сервер позволяет изменять настройки PHP в файле php.ini, то я всегда в самом конце этого файла добавляю эти настройки, они просто перезапишут эти же настройки выше, изменять в файле больше ничего не нужно.

Настройки php.ini для Битрикс в кодировке UTF-8

[PHP] ;error_reporting = E_ALL error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED ;log_errors = On ;error_log = "/var/log/php/PHP_errors.log" short_open_tag = On max_execution_time = 60 max_input_vars = 10000 max_input_nesting_level=100000 memory_limit = 300M session.use_trans_sid = 0 display_errors = On post_max_size = 200M upload_max_filesize = 200M max_file_uploads = 30 output_buffering = 4096 default_socket_timeout = 60 allow_url_fopen = On session.gc_probability = 1 realpath_cache_size=4096k mbstring.internal_encoding = UTF-8 mbstring.func_overload = 2 zlib.output_compression = Off zlib.output_compression_level = -1 zend.enable_gc = On expose_php = Off report_memleaks = On session.entropy_file = /dev/urandom session.entropy_length = 128 date.timezone = Europe/Moscow ;date.timezone = "Asia/Novosibirsk" [MySQL] mysql.allow_persistent = Off

Настройки php.ini для Битрикс в кодировке Windows-1251

Все настройки как и выше, но надо заменить UTF-8 на cp1251 и func_overload на 0

mbstring.internal_encoding cp1251 mbstring.func_overload = 0

Если нет возможности самому изменять настройки php.ini:

либо скиньте все настройки хостеру и попросите его это сделать;
либо пробуйте задавать их в в секции mod_php5 файла .htaccess, который в корне сайта.

<IfModule mod_php5.c> php_flag allow_call_time_pass_reference on php_flag session.use_trans_sid off php_value mbstring.func_overload 2 php_value mbstring.internal_encoding UTF-8 </IfModule>

если значение опции число или строка - php_value
если значение опции флаг On или Off - php_flag

Обратите внимание! Если сайт будет работать в кодировке UTF-8, то перед восстановлением сайта обязательно надо настроить в php.ini настройки mbstring, иначе сайт не восстановите, т.к. через .htaccess данные настройки не изменить.

Как выше было сказано, есть проблема: с версии PHP 5.2.8 значение опции mbstring.func_overload через .htaccess сайта изменить нельзя!

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

Также замечено. Вам хостер отписался, что, вроде как, все сделал, но на самом деле, он ничего не сделал, он просто сделал вид, мол, что-то сделал, а иногда даже сделал, но все неправильно или как попало, часть настроек установил, часть нет, такие случаи тоже бывают, особые случаи, имейте это в виду, все проверяйте. Все рекомендуемые для Битрикс требования есть в мануале Bitrix Framework и хостинг, обязательно прочитайте.

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

Перенос сайта

1. Создание локальной резервной копии сайта Битрикс и перенос на новый хостинг с помощью WinSCP.

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

Через админку сайта создаем полную локальную резервную копию (файлы и БД). О том, как создать полную резервную копию сайта для переноса читайте в статье Резервное копирование в битрикс;
Закачиваем архив сайта на новый сервер/хостинг. Переносить файлы между сервером/хостингом можно с помощью программы WinSCP и PuTTY, как их установить и настроить Вы можете прочитать в статье Установка и настройка WinSCP и PuTTY;
Закачиваем файл restore.php на сервер, с его помощью и будем восстанавливать сайт;
Обратите внимание! В момент восстановления сайта через данный файл в корне сайта либо не должно быть файла .htaccess, либо закомментируйте или удалите его, иначе будут проблемы.
В адресной строке браузера наберите http://ваш_сайт/restore.php и нажмите кнопку Далее.
Дальше все пойдет пошагово, сначала распакуйте архив с файлами на сервер, потом укажите доступы к БД на новом сервере (если нет БД, ее необходимо создать) и все на этом, сайт должен восстановиться полностью, жмите кнопку "Перейти на сайт";
Но это еще не все, сайт уже работает, но есть еще один важный момент. После восстановления сайта создается новый файл .htaccess, а старый переименовывается в .htaccess.restore, его нужно вернуть обратно, обратно .htaccess.restore в .htaccess, т.к. в нем могут быть всякие 301 редиректы и прочие конфиги сервера, иначе вы можете убить все продвижение сайта, последствия будут неприятные.
Но и это еще не все, далее Вам необходимо авторизоваться на сайте, который мы перенесли и еще раз протестировать хостинг штатными инструментами тестирования в Битрикс, еще может много чего всплыть, это : Панель производительностиРабочий стол -> Настройки -> Производительность -> Панель производительности
Сканер безопасностиРабочий стол -> Настройки -> Проактивная защита -> Сканер безопасности

Здесь я из своего опыта хочу добавить: - В "Панели производительности" ошибок быть не должно точно, крайне редко что-то там будет красным; - В "Сканере безопасности" всех ошибок не исправить на хостинге точно, которые относятся к настройкам apache2, nginx и т.д., но на VPS/VDS можно исправить и даже нужно!

Вот и весь перенос сайта Битрикс с одного хостинга на другой, на все 30-60 минут, если без плясок.

Все остальные способы опишу чуть позже.

2. Восстановление резервной копии сайта на новом хостинге из облака "1С-Битрикс".

3. Создание локальной резервной копии сайта и перенос на новый хостинг с помощью консольной программы в Linux для загрузки файлов "wget".

4. Синхронизация сайта на другой хостинг с помощью консольной программы в Linux для синхронизации файлов и каталогов "rsync".

Заключение

Свои сайты переносить можно не боясь, настроили хостинг для Битрикс, восстановили сайт из резервной копии, все, процесс завершен.

А вот, если вы работаете в веб-студии, которая готова бездумно перенести все сайты на планете на самые дешевые хостинги, да по 10 штук на аккаунт, то тут вы столкнетесь с очень серьезными проблемами, часто даже не решаемыми, и что делать?

- Первая ситуация: Вы перенесли сайт, все ок, забыли уже про него, через 1-2 недели приходит от клиента весточка, мол: "Не работает загрузка файлов в статьи", и кто будет решать проблему? Конечно Вы ее будет решать, вы же переносили сайт, Вам нужно будет найти проблему и исправить ее, если хватит знаний и опыта, если не хватит, Вы плохой переносчик сайтов, а если загрузчик на flash, ой... вей...

- Вторая ситуация:

Вы перенесли сайт, все ок, забыли уже про него, через 1-2 недели приходит от клиента весточка, мол: "У нас была на сайте панель добавления товара, вторая админка, в одной админке мы добавляем статьи, страницы, а в другой админке у нас магазин, там каталог отдельно наполняется", ну так получилось, две админки у одного сайта, и кто будет решать проблему?

Конечно Вы ее будет решать, вы же переносили сайт, Вам нужно будет найти проблему и исправить ее. А когда Вы начали разбираться, оказалось, что где-то там в папке /admin/engine/controller/ была символьная ссылка с папки "catalog" на папку, внимание "/var/www/user/some_dir_name", ок, тут вы понимаете, что админка вообще где-то в другом месте сервера лежит, подключаетесь к старому серверу и тут Вас ждет очень неприятный сюрприз, аккаунт уже удален за неуплату, все данные потеряны, продолжать не вижу смысла...

- Третья ситуация:

По файлам на сервере видно, что сайт вроде как один, но БД почему-то 4шт., клиент не в курсе, ок, все сделали, восстановили сайт, пробежались по первым страничкам, вроде все работает. Потом оказалось, что те 3 базы данных просто старые, ненужные, ок, а в чем подвох?

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

Вывод

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

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

Т.е. так сайт разработают, что на другой сервер он уже либо не переедет совсем, либо его перенос будет стоить дороже разработки, т.к. собирать его придется по всему серверу и конфигурировать VPS/VDS под этот сайт.

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

tuning-soft.ru