Бэкапы и БД. Бэкапы, восстановление сайтов, баз данных. Восстановление сайта из резервной копии и перенос между серверами
 Скачать 54.11 Kb.
|
]# mysqladmin -hc03db.hoster.ru -umanagemysql -pjka84nas8yfa processlist
]$ tar -cf - xn--80aerbai0dd.xn--p1ai | ssh srv102165@ssh-102165.srv.hoster.ru 'tar -xf - '
/xn--80aerbai0dd.xn--p1ai]$ du -h -d 1 .Восстановление сайта из резервной копии и перенос между серверами. Бесплатное восстановление файлов (архив в shadow); Платное восстановление с заменой файлов или бесплатное с заменой файлов (если баг нашей панели); Платное восстановление удалённой услуги на новом сервере или бесплатное (если баг нашей панели); Копия базы данных в shadow; Импорт дампа БД в новую базу и правка конфигурационных файлов; Поиск и восстановление удалённой БД; Перенос услуги между серверами; Переезд клиента от стороннего хостера; Win-хостинг; Postgres SQL. Бесплатное восстановление файлов В трансфере находим следующие данные о клиентском сайте: ID услуги, HUID (идентификатор пользователя), сервер на котором хранится услуга. * HUID может иметь вид: 12345, srv12345, huid1234 Заходим на st0 и оттуда переходим на нужный сервер -> ssh <сервер>; Входим в режим администратора -> sudo bash (знак приглашения сменится на #); Входим в контейнер (при необходимости) на he -> jexec 1 bash, на с -> vzctl enter 1; Перемещаемся в папку клиентской услуги: Старый хостинг (he2 – he16) -> cd /jail/home/ Старый-Новый (he18-he26) -> cd /jails/www/home/ Новый (с00-с03) -> cd /vz/root/1/home/ *he и he2 расположены на одном физическом сервере. Путь до папки клиента: cd /jail/he(he2)/home/ Из контейнера в клиентскую папку перемещаемся просто cd /home/ На старом и старом-новом хостинге папка shadow расположена в папке клиентского сайта на уровне с папкой html, на новом она распологается на одном уровне с папками сайтов. Если этой папки нет, её нужно создать командой mkdir <имя папки>. * На старом и старом-новом хостинге ОС FreeBsd, папку html создавать нужно, в неё размещается сайт. На новом хостинге ОС Linux, контент помещается непосредственно в папку сайта. ** he6 и he13 – сервера на платформе Windows, сервера he4,8,16,17 и 19 не используются. 7) Создав shadow заходим в неё -> cd shadow. Содержимое папки можно посмотреть командой ls с параметрами (ls -l, ls -la, ls -lat). ls -la покажет расширенный вывод вида: drwxdr-r-- 1 srv123456 123456 4096 Apr 17 10:39 shadow d -> показывает директория это или файл; rwxdr-r-- -> права пользователей на папку. Сначала идут права пользователя, потом группы пользователей, потом всех остальных (r - чтение, w - изменение, х - исполнение). Каждой букве соответствует свой числовой эквивалент: r - 4, w - 2, x - 1. Они суммируются, т.е 777 - все права для всех пользователей и т.д.; srv123456 123456 - владелец папки (root - администратор). По умолчанию, после выполнения, каких либо операций с файлом/папкой суппортом, права на папку или файл будут рутовые а не пользователя и он не сможет их увидеть; 4096 - размер папки/файла; Apr 17 10:39 - дата создания. 8) Теперь заходим на b00 в режим администратора, запускаем утилиту bconsole для восстановления состояния сервера за нужное число. sudo bconsole -c /usr/local/etc/bacula/servers/bconsole-<сервер>.conf Нажимаем 9, потом 6, вводим дату за которое нужен бэкап или дату самой ранней копии сервера, время берем любое на час позже времени завершения полного бэкапа (пометка F в табличке). Ввод вида: 2014-04-24 15:00:00 Ожидаем окончания построения бэкапа и появления надписи cwd is. !!!! ВНИМАНИЕ !!!! Не простраивайте несколько бэкапов состояния сервера на нескольких рабочих машинах. Это значительно затормозит работу сервера, а строиться они будут всё равно по очереди. Предупреждайте коллег о запуске бэкапа и уточняйте, не строит ли кто-нибудь бэкап на сервере, с которым вы собрались работать. Бэкапы состояния разных серверов строить одновременно можно как на одном компьютере, так и на разных. 9) Далее перемещаемся в простроенном бэкапе в клиентскую папку -> cd storage/home/HUID или в директорию где лежит нужный нам файл, смотрим содержимое папки командой ls, выбираем нужные папки/файлы командой mark <папка/файл>, когда закончили, пишем done, выбираем 1, выбираем yes (не ошибитесь! Иначе всё заново строить), затем выходим из интерфейса нажав q и enter. 10) Нужные клиенту папки/файлы перемещены во временную папку на клиентском сервере: /tmp/bacula-restores/storage/home. На новом хостинге может потребоваться дописать путь: /vz/root/2/tmp/bacula-restores/storage/home. На сервере с клиентской услугой, заходим в эту папку, архивируем контент клиента командой tar -cvf <название архива.tar> <папка которую архивируем> и перемешаем командой mv <созданный архив> <путь до папки shadow на клиентской услуге> в shadow к клиенту. Затем меняем права на папку shadow и её содержимое (т.е и на архив тоже), так чтобы клиент смог его увидеть и совершать с ним операции. * команда pwd покажет ваше текущее расположение на сервере. сd без параметров переместит в вашу домашнюю директорию на сервере /home/sup<> или в корень. ** Права групп можно изменить так: chmod -R 755 shadow Владельца папки можно сменить так: chown -R srv53741: 53741 shadow Ключ -R позволяет применять изменения для всего содержимого папки. 11) Радуемся, отписываем клиенту в рт, снимаем с себя ответственность за заявку. Пример: [sup03@c02 3) Звоним администраторам и называем им root id услуги из трансфера и сервер. Получаем от них huid. 4) Также перед тем, как строить бэкап, можно поискать архив удалённой услуги в папках удалённых услуг на сервере где ранее хранилась услуга.: /jail/backup/oldusers - для старого хостинга, /storage/backup -для нового и старого нового. Перемещаемся в эту папку и выполняем команду find . | grep 5) Если есть, его нужно переместить в директорию саппорта /home/sup<>, затем зайти на сервер, где будет восстанавливаться сайт, переместиться на клиентскую услугу и выполнить перемещение архива из папки /home/sup03 на старом сервере в клиентскую папку на новом сервере: [root@c02 srv53741]# scp sup03@he22.hoster.ru: /home/sup03/site.ru.tar site.ru.tar. Перед @ указываем свой sup, после сервер с которого переносим, потом путь до архива на старом сервере, потом имя архива с которым он будет помещён на новый сервер. 6) Теперь распаковываем архив в клиентской папке на новом сервере командой tar -xvf, помня о том, что html нам на серверах с Linux не нужен. Поэтому перемещаем папку html на уровень выше командой mv html .. , переходим на уровень выше cd .. , удаляем пустую папку сайта rm -rf <домен>, а затем переименовываем html в имя сайта: mv html <домен>. Естественно, что при переносе с нового сервера на старый все операции происходят наоборот. Создаём папку <домен_1> в неё перемещаем <домен>, переименовываем в html, папку <домен_1> переименовываем в <домен>. 7) Что делать если на старом сервере нету архива удалённой услуги? Строить бэкап этого сервера на b00. Если услуга удалена месяц-два назад, можно поварьировать выбор числа за которое будет строиться бэкап. Если удалена давно (3-6 месяцев), то самый ранний бэкап вообще. Далее всё, как описано выше. Ищем папку в выводе утилиты bconsole, отмечаем mark, выбираем 1-й метод восстановления, идём во временную папку на старом хостинговом сервере , пакуем в архив, архив перемещаем в свою домашнюю директорию старого сервера, заходим на новый хостинговый сервер в клиентскую папку, перемещаем архив между серверами scp, распаковываем, играемся с базами данных и конфигурационными файлами (об этом дальше). Если сайт не работает, два варианта: перенос, предложение клиенту идти к разработчикам. Второе выгоднее, но бесплатно. Копия БД в shadow 1) Клиент в заявке не всегда точно указывает хост БД или не указывает его вообще, поэтому заходим в трансфер и ищем его. 2) Заходим на клиентскую услугу, создаём shadow, если нужно, перемещаемся туда. 3) заходим на b00 -> cd /storage2/backup/databases/users/mysql/<хост>/<дата в формате 2014-04-25> 4) Ищем нужный дамп командой find . | grep <имя БД>. Если нет, можно вернуться в папку mysql и повторить команду. Так мы найдём все хосты, где встречалась база и все числа за которые есть дампы. 5) Копируем полный путь до базы на b00 нажатием ctrl+insert (помним, что ctrl+с отменяет ввод), возвращаемся в клиентский shadow, копируем дамп с b00 на клиентский сервер командой scp. Вставка пути осуществляется нажатием shift+insert, автоподстановка, если что-то забыли tab. Пример: находясь в shadow пишем - scp sup03@b00.hoster.ru:/storage2/backup/databases/users/mysql/dbhe22.hoster.ru/2014-04-25/db12345.dump.gz db12345.dump.gz 6) Если клиенту нужен дамп именно в формате .sql, нужно распаковать его командой gunzip <дамп>, а затем переименовать в .sql командой mv (mv db12345.dump db12345.sql). 7) Теперь меняем права на файл или на папку командой chown и отписываем клиенту. Восстановление базы данных с заменой 1) Тут всё сложнее. Для начала находим хост базы данных в трансфере, а затем саму базу на b00 за нужное число. 2) Теперь нужно найти конфигурационный файл, в котором прописаны реквизиты для подключения базы данных к сайту. Расположение этих файлов зависит от системы управления контентом, с помощью которой создан сайт: примеры для основных CMS: http://www.levik.info/raspolozhenie-konfiguracionnyx-fajlov-v-populyarnyx-cms.htm. Найти конфигурационные файлы можно, зайдя на клиентскую услугу в html или папку домена и выполнив команду grep -R hoster.ru ./ В выводе команды увидим строчки вида ./configuration.php: public $host = ’mysql-54231’.srv.hoster.ru’; Редактировать нужно только те файлы, где есть 4 строки схожие с db_host, db_name, db_pass и db_user. В зависимости от типа CMS эти строки в конфиге могут называться и писаться по-разному, но смысл примерно понятен. Например, строка db_host может писаться dbhost, а db_pass как password, плюс всё это может быть в строчку и неудобно для редактирования. 3) Редактировать конфиг можно различными редакторами, но удобнее всего mcedit -ом или vi. Команда будет выглядеть следующим образом: mcedit <путь к файлу до : из вывода команды grep -R hoster.ru ./ с учётом того, что вы поправите путь относительно папки в которой находитесь> Пример: [root@c02 site.ru]# grep -R hoster.ru ./ ./configuration.php: public $host = ’mysql-54231’.srv.hoster.ru’; [root@c02 site.ru]# mcedit configuration.php В выводе grep -R hoster.ru ./ могут быть лишние файлы, которые содержат только строчку hoster.ru, но в которых нет строчек с реквизитами. Их трогать не надо. В нужных файлах находим 4 строки: хост для внешнего подключения, имя БД, имя пользователя и пароль к БД. 4) Когда мы будем импортировать дамп с b00 за нужное число в базу данных, нужно удостовериться в том, что эта база есть. Заходим в клиентскую панель управления хостингом, находим вкладку «Базы Данных» и ищем название базы, которую клиент указал в заявке. Если таковой не имеется, нужно эту базу создать. Создаём в панели пользователя БД, пароль ему указываем из конфига, хост %. Теперь создаём БД, указываем этого пользователя и все привилегии. 5) Теперь сверяем конфиги и реквизиты в панели управления хостингом. Они должны соответствовать. Хост для подключения в конфиге указываем для внешнего подключения. Он есть над таблицей «Базы данных» и начинается с букв mysql. 6) Возвращаемся на b00 в папку с дампом, пишем команду zcat <имя дампа> | mysql -h<хост базы данных на сервере> -u<пользователь> -p<пароль> <имя базы в которую будет помещён дамп>. Реквизиты берутся из панели управления или из конфига. Пример: zcat db23412.dump.gz |mysql -hdbhe22.hoster.ru -usrv23412 -pusrpass11 srv54618_db23412 7) Открываем сайт в браузере, смотрим изменения. Если база была новая, заходим в phpmyadmin, смотрим, чтобы появились таблицы. В целом, это всё, но есть множество нюансов: Клиентская база использует localhost. В этом случае вывод команды grep -R hoster.ru ./ результатов не принесёт. Нужно будет зайти в панель управления хостингом, на вкладку БД, проверить, действительно ли пользователю задан хост localhost, а не % (сайт клиента может просто не использовать БД или не создана БД). Если база действительно использует localhost, это значит, что клиент не хочет, чтобы она не была доступна из вне, и редактировать её сможет только по ssh с нашего сервера. Конфигурационные файлы можно найти следующими командами: grep -R site.ru ./ | grep -v 'sql\|log' grep -ri html ./ | grep -v sc-error | grep -v errors site.ru или html - папка где Вы ищите конфиг. Иногда База не работает, потому что в импортированном дампе и конфигурационном файле не совпадают префиксы таблиц. Заходим в dbadmin, смотрим префикс (одинаковая часть для всех таблиц в dbadmin) и сверяем со строчкой db_prefix в конфиге. Обычно он указывается со слешом. Например, ntcih_. Иногда ничего не работает, потому что при редактировании мы нечаянно удалили закрывающие кавычки или двоеточия в строчках с реквизитами подключения, а потом не вернули их на место. Иногда нужно править абсолютные пути к различным папкам на сайте. Такая ситуация возникает в основном после переноса всего сайта на новую услугу. (подробнее в разделе перенос сайта) Бывает, что база отказывается работать из-за того что указан хост для внешнего подключения. Можно попробовать задать хост базы на сервере. Восстановление удалённых баз данных 1) Удалённые базы можно поискать тут: /storage1/backup/oldusers/databases/mysql/ или тут, если база переехала: /storage1/backup/oldusers/databases/mysql/moved командой find . | grep <имя бд>. 2) Далее всё как выше. Сначала находим конфигурационные файлы со старыми реквизитами подключения к базе данных, создаём новую базу данных в клиентской панели управления. Исправляем конфиги с учётом изменений, внесённых в панель, так чтобы хост в конфиге соответствовал хосту для внешнего подключения в панели, имя пользователя, пароль и имя базы были новыми, везде были проставлены кавычки и запятые, префикс таблиц из phpmyadmin совпадал с тем, что в конфиге (если такая строчка вообще есть). Потом накатываем дамп с b00 в новую базу: zcat db23412.dump.gz |mysql -hdbhe22.hoster.ru -usrv23412 -pusrpass11 srv54618_db23412 Помним что реквизиты в этом случае обновлённые. Нюанс. Клиентский конфиг может быть доступен только для чтения. Тогда для внесения изменений можно воспользоваться редактором vi: Основные необходимые команды i - войти в режим редактирования текста esc - выйти из режима редактирования x - удаляет символ, на котором находится курсор u - отмена предыдущего дизменения ctrl+r -возврат предыдущего изменения shift+z+z - выход с сохранением :wq! - выход с сохранением и принудительной записью изменений :q! - выход без изменений Смена тарифа или переезд клиента на новый сервер 1) В силу того, что мы не можем просто взять и изменить версию PHP на старых серверах, клиенту, которому нужна более новая версия PHP, мы предлагаем перенос. Сделать он его может как сам, так и мы ему платно: К сожалению, изменение версии PHP для данного тарифа невозможно, поэтому рекомендуем Вам перейти на один из новых тарифов: Альфа, Бета, Гамма или Дельта, которые поддерживают последнюю версию PHP 5.4. Для переноса сайтов Вам следует выполнить следующие действия: 1) Загрузить файлы Ваших сайтов и дампы баз данных на Ваш компьютер. Файлы загружаются по FTP (инструкции по работе с FTP Вы можете найти на нашем сайте в разделе "Помощь": http://www.hoster.ru/faq/r62.htm), базы данных Вы можете экспортировать через dbAdmin. Почтовые ящики при переносе также будут удалены, поэтому, если Вам нужны некоторые письма, рекомендуем также сделать их копии. 2) Заказать и активировать новый тарифный план через раздел "Новые услуги (заказ)". 3) Удалить виртуальные хосты, базы данных и почтовые ящики, привязанные к Вашим сайтам на старом тарифе Делается это в разделах «Виртуальные хосты», «Базы данных» и «Почта». 4) Перенести домены на новую услугу через раздел "Перенос домена" (Сначала выбираете услугу, с которой следует перенести домен, затем переносимый домен и, наконец, услугу, на которую следует осуществить перенос). Не забудьте после переноса обновить DNS-записи. Сначала можно оставить переключатель в положении «Создать по умолчанию», а затем подкорректировать созданные запись так, как Вам нужно. 5) Загрузить файлы сайтов на новую услугу по FTP, создать новые виртуальные хосты для доменов на новом тарифе (раздел "Виртуальные хосты"). Обратите внимание, что для загрузки файлов следует создать папку с именем домена и загрузить файлы непосредственно в нее (подпапок вроде html создавать не нужно). Кроме того необходимо создать новые базы данных в соответствующем разделе и импортировать в них дампы старых баз данных. Создать их можно в разделе "Базы данных". Сначала создайте пользователя (в поле "Хост" рекомендуем указать символ "%"), затем – саму базу данных. Получить доступ в dbAdmin можно, нажав на кнопку "dbAdmin" в таблице с базами данных. После этого в конфигурационных файлах сайта необходимо будет заменить реквизиты старых баз данных на новые. Размещение этих файлов зависит от типа Вашей CMS или специфики сайта. Затем для каждого домена необходимо восстановить почтовые ящики и алиасы. Предупреждаем, что при смене версии PHP на более новую, у вас могут возникнуть проблемы с совместимостью, если Ваш сайт не адаптирован к новой версии. В решени проблемы могут помочь разработчики Вашего сайта. Если в процессе переноса у Вас возникнут вопросы, мы обязательно на них ответим. Если Вы не хотите или не можете произвести вышеуказанные операции сами, мы можем перенести сайты с услуги на услугу за Вас на платной основе. Стоимость операции 1500 рублей для одного-двух сайтов и по 500 рублей за каждый дополнительный сайт. 2) В целом, из шпоры всё понятно. Если сайт после переноса отказывается работать и техподдержка и админы не знают или не могут решить вопрос с адаптацией сайта к новой платформе, можно предложить клиенту либо обратиться к разработчикам (восстановление бесплатно), либо перенести услугу на сервер со старой версией PHP. В любом случае, выбор за клиентом. Сайт может не работать из-за того что не исправлены абсолютные пути. Этот момент тоже нужно проверить. 3) Кодировка сайта задается как для файлов, так и для баз данных и делается это различными способами. Для файлов сайта она задается в файле .htaccess директивой AddDefaultCharset <значение>, где <значение> может быть:UTF-8, cp1251 (или windows-1251), koi8-r и некоторые другие, намного менее распространенные кодировки. Также можно добавить строку php_value mbstring.internal_encoding utf-8 в .htaccess В некоторых случаях, кодировка определяется в самих файлах, тогда нужно отключать принудительную выдачу кодировки строкой: AddDefaultCharset off Узнать нужную кодировку (если она не битая) можно по ссылке: http://www.artlebedev.ru/tools/decoder/ Если манипуляции с .htaccess не дают результата (отображение неправильной кодировки не меняется вообще), переходим к пункту два. Для баз данных кодировка задается в php-файле, через который идет подключение к серверу MySQL. Для начала, файл нужно найти: grep -R mysql_connect * Далее, открываем текстовым редактором файл, ищем в нем строку с mysql_connect и сразу после нее (на следующей строке) добавляем: mysql_query("SET NAMES 'кодировка'"); где кодировка - UTF-8, cp1251 (или windows-1251), koi8-r и некоторые другие, намного менее распространенные кодировки (которые и не каждому встречались). Указывается она в одинарных кавычках. 4) Если после переноса сайт не заработал, и было принято решение тащить клиента на старый сервер, то делается это сменой сервера и хоста базы данных в трансфере, а потом простым ручным перетаскиванием. На c00 версия php 5.3 и в большинстве случаев перенос с сервера с php5.4 на 5.3 помогает. В трансфере справа от услуги меняем клиенту сервер и хост базы данных. Удаляем базу данных в клиентской панели, пересоздаём её там же но уже с новым хостом. Архивируем содержимое услуги клиента на новом сервере, перемещаем в /home/sup<> командой mv, затем заходим на c00 в папку с тем же хуидом что и прежде и тащим туда архив из Вашей домашней директории командой scp. Распаковываем содержимое архива, повторно заливаем дамп БД в базу с хостом c00db.hoster.ru Правим абсолютные пути на всякий, проверяем, помогло ли. Переезд клиентской услуги от стороннего хостера нашими силами 1) Существует такой класс клиентов-извращенцев, которые вообще не хотят ничего делать со своими файлами. Перенести их услугу от стороннего хостера на наш сервер мы тоже можем, но платно и при выполнении некоторых условий: Клиент регистрируется в нашей панели и приобретает интересующий его тариф. Клиента нужно предупредить, что его сайт может не заработать после переноса, а деньги за перенос мы возьмём, поэтому если он не хочет попасть впросак, лучше делать всё самому на тестовом периоде на 10 дней бесплатно. Если клиент согласился платить, от него требуется ssh-доступ к его услуге (логин и пароль), которые он может найти в панели управления или запросить у хостера. И расположенные на услуге архивы с файлами его сайта (папки, в принципе, тоже хватит, потому что можно осуществить архивирование на лету) и дампом базы. 2) Начинается самое интересное. Подобный перенос лучше делать, если есть возможность задать админам вопрос, потому что просто скачать файлы с его услуги у стороннего хостера и залить на новую услугу у нас с помощью ftp клиента может занять добрых 5 часов. 3) Подключаемся к клиентской услуге у стороннего хостера с предоставленными реквизитами ssh и оцениваем размер сайта: [u295727@btx8 |
Файлы восстанавливаются С ЗАМЕНОЙ, а это значит, что прежде чем их заменить, нужно зайти в клиентскую папку и запаковать старую папку в архив на всякий случай. Распаковать архив можно так: tar -xvf <архив>.
Клиентскую папку теперь можно удалить командой rm -rf <папка> - это сотрёт её со всем содержимым, rm без ключа стирает один файл.
На b00 в утилите bconsole после построения бэкапа нужно выбрать пункт 2.
Особое внимание обратить на этот пункт. Прежде чем делать ПЛАТНОЕ восстановление, нужно написать клиенту о том, что оно платное и дождаться либо того, что он попросит бэкап в shadow, либо пополнит баланс лицевого счёта на договоре:
2,0k ./cgi-bin
2,0k ./tmp
4,6G ./www
4,6G .
4) Осуществляем перенос архива сайта на наш сервер
[u295727@btx8
Или, если там незапакованная папка, а памяти на его услуги для создания архива уже нет, то осуществляем перенос папки с архивацией на лету. То есть, файлы будут архивироваться, а потом распаковываться уже на нашем сервере:
[u295727@btx8