XAMPP for Linux: Туда и обратно. Бэкап, зеркалирование сайтов.
Поддержка и администрирование сайтов, модернизация, редизайн – все эти и связанные с ними дела вряд ли можно делать без локального хостинга; по крайней мере, я даже не могу себе такого представить.
А поэтому тему бэкапа и зеркалирования сайтов я и включил в цикл постов о XAMPP.
Бэкап самого XAMPP
1. Поскольку XAMPP представляет собой совершенно автономное от операционной системы образование, сделать его полный бэкап до изумления просто: надо скопировать/переместить куда-нибудь в удобное место директорию /opt/lampp – и всё. Теперь мы можем установить, к примеру, другую версию XAMPP, не опасаясь, что в случае возврата на старую версию нам придется опять всё настраивать.
2. Предыдущий пункт, как вы понимаете, приведен только в качестве теоретической иллюстрации. Не очень-то много радости занимать сотни мегабайт места ради всего лишь нескольких нужных файлов. Как мы помним, базовая настройка XAMPP осуществляется правкой всего-навсего двух его файлов – /opt/lampp/etc/httpd.conf и /opt/lampp/etc/extra/httpd-vhosts.conf (не считая системного /etc/hosts). Сохранить их – необходимо и достаточно для последующего восстановления XAMPP. Естественно, если мы правили еще какие-нибудь файлы (отключали/подключали модули apache и php, конфигурировали mysql и т.п.), надо не забыть и про них.
Бэкап сайтов
1. Наши виртуальные сайты располагаются в домашней директории, поэтому их бэкап (в случае необходимости) входит в область общих забот по сохранению важной пользовательской информации и никаких особенностей не имеет.
2. Совсем другое дело – бэкап наших реальных сайтов на реальных хостингах.
2-1. Сайты "на файлах", т.е. сайты, не использующие баз данных, бэкапятся также весьма просто: скачиванием (обычно по ftp) доменной папки со всеми потрохами. О конкретной механике – чуть ниже, в разделе Инструментарий.
2-2. Сайты с базами данных должны сохраняться двумя частями: всеми файлами сайта и дампом базы (или баз) данных.
О том, как осуществлять задачи из пункта 2, мы опять-таки поговорим в разделе Инструментарий.
Зеркалирование сайтов
1. Данная операция, означающая перенесение точной копии сайта с одного места на другое, так же не представляет собой, теоретически, никакой сложности. Берем бэкап сайта и переносим все файлы в выделенное для сайта место, а дамп базы импортируем в тамошние базы.
2. Но теория, как известно из классики, суха, а древо жизни нередко бывает шершавым.
Что и почему может пойти не так? Многое и по разным причинам. Здесь я советчик слабый, сам еще плаваю по-щенячьи. Но, по моему скромному опыту, некоторые важные причины всяких "детских неожиданностей" таковы:
2-1. Права на файлы и директории. Заботится ли ваш ftp-клиент о правах хотя бы так же, как наши омбудсмены? Изменение прав на файлы/каталоги в процессе перемещения с хоста на хост чревато тем, что некоторые скрипты и модули CMS, хорошо работавшие на одном месте, на другом отказываются работать.
2-2. Конфигурация серверов. Сравните ради интереса phpinfo XAMPP'a и какого-нибудь реального хостинга (в особенности бесплатного или дешевого), и скорее всего, количество модулей в разделе/секции Configuration → apache2handler → Loaded Modules:
будет сильно отличаться (естественно, в пользу XAMPP'a). У меня только что, на днях, обнаружилось, что один из модулей CMS (слава богу, не из жизненно необходимых) не работает из-за того, что у хостера не включен модуль negotiation. Судорожное гугление быстро позволило найти собратьев по несчастью, которые уже давно решили эту проблему добавлением записи в .htaccess. Но это (относительный) пустяк. А если бы в глаз, как говорила одна старая дева?!
Кроме того, на новом хостинге php может быть подключен как модуль Apache, а может – как FastCGI, или использоваться связка Nginx+Apache (это не все, а лишь самые распространённые случаи), и вы должны быть более-менее готовы к таким ситуациям.
Желательно выбирать хостинг с тестовым периодом (или манибэком) хотя бы в неделю.
2-3. Ошибки при экспорте/импорте баз данных. Типичная для начинающих ситуация: установили файлы, успешко импортировали базу, сайт вроде даже открывается, но... пустой. Что за хрень, вопрошает ошарашенный юзер. Хорошо, если у него в голове водится внутренний голос, который шепнет ему: а ты создал на новом месте пользователя базы, с теми же логином, паролем и правами, что и были на старом, а?!
Случаются и другие сюрпризы: например, вы создали два сайта-близнеца (на XAMPP и реальном хостинге), при этом использовали разные "секретные фразы" (на некоторых CMS они служат для генерации хеша пароля), а теперь пытаетесь заменить один из сайтов на другой и не понимаете, почему вдруг вас не пускают в админку. Общее понятие о том, как разрулить данную ситуацию при помощи правки базы данных, можно почерпнуть, например, на сайте rutheme.ru.
Ещё один нюанс (по совсем недавно приобретенному опыту спешного перезда на новый хостинг). Новый хостер может выделить вам базу с уже определённым именем (или с префиксом к имени, например myaccount_ ). В отношении CMS MaxSite проблема решается правкой файла-конфига database.php, в котором старое имя базы нужно поменять на новое и, если требуется, исправить строку
(имя сервера базы должен указать хостер). Старая база из бэкапа содержала старое имя только в одной строке коммента, но я и там его поправил 
. Создав базу на хостинге, удалил все ее таблицы, выставил кодировку utf-8 ("Основные настройки → Сопоставление соединения с MySQL → utf_general_ci"), после чего импортировал (первый раз – вручную, с помощью phpMyAdmin) старую базу. В дальнейшем уже пользовался Sypex Dumper, о котором речь в разделе Инструментарий.
Зеркалирование: краткая шпора.
Учитывая всё вышесказанное, смастерим краткую шпаргалку (cheatsheet) по зеркалированию сайтов:
1. Скачиваем по ftp все файлы первого (зеркалируемого) сайта с точным сохранением файловой структуры и прав на файлы и каталоги;
2. Берем дамп базы первого (зеркалируемого) сайта тем или иным способом (phpMyAdmin, Sypex Dumper или другой инструмент), запоминая (склеротикам – записывая) настройки, при которых создавался дамп;
3. Закачиваем все файлы на сайт-зеркало, контролируя сохранность файловой структуры и прав на файлы и каталоги;
4. Импортируем базу, используя по возможности тот же инструмент, которым создавался дамп и контролируя соответствие настроек (при возникновении траблов сравнение настроек дампа и импорта может стать важным);
5. Создаем пользователя для базы сайта-зеркала с теми же логином-паролем и такими же (или бóльшими) правами на базу, что были на первом (зеркалируемом) сайте.
Инструментарий
1. FTP
Обязательным условием нормального хостинга является доступ к своему сайту по протоколу ftp. Вы должны иметь все необходимые данные вашего ftp-аккаунта: имя_пользователя, пароль, ftp-хост и т.д.
Скачать все файлы сайта – обычно не проблема даже для начинающих веб-мастеров. С этой задачей легко справляются различные ftp-клиенты, например, один из самых популярных FileZilla. Он кроссплатформенный, на Linux-системах может быть установлен как из репозиториев (где версия, как водится, постарее), так и простой распаковкой файлов пакета, взятого отсюда, в любое удобное место. В последнем случае для запуска FileZilla нужно создать где-нибудь в директории, включенной в PATH (я использую для подобных целей специальную директорию $HOME/.bin) симлинк на файл FileZilla3/bin/filezilla.
Несмотря на устрашающий на первый взгляд интерфейс, FileZilla легко и практически интуитивно настраивается. Кроме интуиции, можно использовать довольно подробную (но, увы, на английском) документацию, как прилагающуюся к пакету (man1 и man5), так и на Вики.
Но у линуксоидов есть и специфически линуксоидные средства, и из них вне конкуренции старый добрый интернет-насос wget.
1-1. Одной-единственной командой такого формата:
мы получаем в папке, откуда запустили эту команду, полный бэкап нашего сайта (и даже с небольшим довеском, но об этом чуть ниже).
Разжуём мелко:
опция -m (или --mirror) является алиасом (сокращением) для нескольких опций: -r, -N, -l inf, --no-remove-listing. Благодаря последней в каждом каталоге скачанного сайта появится файл .listing, назначение и содержание которого очевидны. Вообще-то для контроля он бывает полезен, но если желательно избавиться от него, нетрудно сделать это командой
запущенной в папке с бэкапом.
ftp://ваш_ftp-логин:ваш_ftp_пароль – тут всё понятно;
@ваш_ftp_хост.ru/ваша_домашняя_директория – для ясности приведу пример: если хостер предоставляет вам имя ftp-хоста mysite.ru, а загружать файлы сайта велит в папку, скажем, /public_html, то строка после собаки будет такая:
@mysite.ru/public_html
1-2. Кому-то, кто уже начал входить в курс и во вкус true Linux, предыдущее решение покажется не айс – и из-за файликов .listing, и из-за необходимости каждый раз вбивать логин-пароль. Возникает вопрос: а нельзя ли это как-нибудь усовершенствовать?
Предлагаю одно из возможных решений.
Умнице wget'у можно подсунуть для каждой задачи свой отдельный конфигурационный файл – этакий временный .wgetrc – с помощью опции --config=FILE. Это позволит нам гораздо более гибко управлять поведением wget, сделать процесс более безопасным, а заодно (и это главное, не так ли ) и более удобным.
Не буду подробно останавливаться на этом псевдо-wgetrc файле, его директивах и синтаксисе (желающие узнать больше могут покурить главу "Конфигурационный файл .wgetrc : установка умолчаний" из ставшей уже классической (но, увы, в чем-то уже и устаревшей) работы Андрея Шевеля "Операционная система LINUX и её окрестности". Просто приведу свой пример конфига с краткими пояснениями.
# Данный файл может располагаться где вам удобно
# и называться как угодно.
# Выставьте на него жесткие права доступа: на время отработки 440,
# на готовый файл -- 400
# Строки комментов и пустые строки игнорируются.
# Включаем опцию --mirror
mirror = on
# Не используем файл ~/.netrc
netrc = off
# Если хотим, чтобы wget работал молча, раскомментируем след. строку:
# quet = on
# Включаем пассивный режим
passive_ftp = on
login = мой_ftp_логин
passwd = мой_ftp_пароль
# Сохраняем права на папки/файлы
preserve-permissions = on
# Удаляем из бэкапа файлы листингов .listing
remove_listing = on
add_hostdir = off
cut_dirs = 1
# Последние две строки требуют подробного объяснения, см. ниже
Директива add_hostdir = off заставляет wget исключать из бэкапа вершинную папку вашей сайтовой иерархии. Например, если файлы вашего сайта расположены в mysite.ru/public_html/файлы_сайта, то wget по умолчанию и образует вам точно такую же структуру бэкапа. При директиве add_hostdir = off бэкап будет иметь вид public_html/файлы_сайта. Если же нужно избавиться и от папки public_html и загрузить только файлы сайта, так сказать, россыпью, добавляем директиву cut_dirs = 1.
Например, у меня есть такая структура на хостинге: ftp://myhost.ru/domains/mysite.ru При включенных директивах add_hostdir = off и cut_dirs = 1 бэкап моего сайта будет содержаться в папке mysite.ru и никакой лишней "матрёшки" не будет.
Теперь, имея этот файл (назовем его для примера просто config) и определившись с директорией для бэкапа, мы можем сочинить простенький скриптик такого примерно вида:
#!/bin/bash # Загрузка файлов сайта mysite.ru по ftp DIR=/путь/к_директории/бэкапа CONF=/путь/к_файлу/config cd $DIR wget --config="$CONF" ftp://myhost.ru/domains/mysite.ru # Дальше при желании можно заархивировать бэкап для хранения #(например, с меткой времени в имени) и удалить исходную папку бэкапа #(будьте очень осторожны при использовании rm, перепроверяйте пути и синтаксис!!) #например, так: wait; tar -Jcvf mysite_$(date +%d_%m_%y-%H).tar.xz "$DIR"/mysite.ru && rm -rf "$DIR"/mysite.ru # или прописать другое нужное вам действие, или же ничего больше не делать. exit 0
Тщательно отработанный, протестированный скрипт, помещенный в одну из PATH-директорий, можно использовать для бэкапа по расписанию с помощью cron, что уже гораздо интереснее.
2. Базы данных
Как правило, если хостер выделяет вам базу данных, то и предоставляет доступ к ней через phpMyAdmin. Этого вполне достаточно для экспорта/дампа базы и для ее импорта/восстановления, – пока база не слишком велика. Для отработки этих действий также весьма пригодится XAMPP, чтобы потом не бояться их на удаленном сервере. Обычно достаточно дефолтных настроек phpMyAdmin, хотя надо, конечно, хоть раз эти настройки просмотреть и осмыслить (прежде всего, видимо, надо обращать внимание на кодировки).
Кроме phpMyAdmin, есть и другие инструменты для экспорта/импорта баз данных. На сегодня один из самых популярных (по крайней мере, в рунете) – Sypex Dumper, продукт киевской фирмы "БИНОВАТОР". Он прост в установке, хорошо документирован, имеет платную недорогую и полностью бесплатную (с лицензией BSD) версию, покрывающую потребности большинства юзеров. Sypex Dumper весьма быстр (я сам в этом убедился), что немаловажно даже при небольших базах, но главная его фишка – дамп больших, в сотни мегабайт и даже гигабайты, баз, когда phpMyAdmin может уже работать слишком медленно, сбоить или совсем не справляться. Документация на оффсайте качественная и достаточная для установки, наладки и эксплуатации, там же есть небольшой FAQ и форум, так что отсылаю вас к ним.
