25 марта 2008 в 17:33
Чтобы в будущем можно было восстановить базу данных, которая была утрачена нужно сделать резервную копию базы данных (дамп). Для этого можно использовать:
- автоматизированные инструменты, которые предоставляет ваш хостер,
- бесплатный скрипт phpMyAdmin, который позволяет управлять базой данных, а также создать дамп базы данных и скачать его
- бесплатный скрипт Sypex Dumper Lite, который позволит вам создавать резервные копии любых размеров и восстанавливать их.
Использование phpMyAdmin для создания резервной копии базы данных
- Прежде чем устанавливать этот скрипт, выясните у вашего хостера - возможно он уже установлен. Если же нет, то вы можете установить phpMyAdmin самостоятельно.
- После этого открыть в браузере этот скрипт (адрес зависит от того, в какой папке был установлен скрипт).
- Выбрать нужную базу данных
- Нажать вкладку Экспорт и настроить параметры экспорта.
Использование Sypex Dumper Lite для создания резервной копии базы данных
"Sypex Dumper в отличии от многих подобных скриптов не загружает бекап-файл целиком в память, благодаря чему, ему безразличен размер базы данных и он одинаково быстро работает, как с маленькими, так и с большими объемами данных."
Установка
- Распаковать скачанный zip-файл.
- Закачать dumper.php в один из каталогов вашего сервера (доступный из web).
- Установить для этого каталога CHMOD 777 (см. Права доступа к файлам).
Использование
- Открыть в браузере URL вида: http://domain.com/dumper.php.
- Ввести логин и пароль для вашей БД.
- Создание резервной копии БД:
- Выберите базу данных в верхнем разделе главной страницы.
- Фильтр оставьте пустым (будут дампиться все таблицы выбранной БД), подробнее о фильтрах см. ниже.
- Выберите метод сжатия (bzip2 наиболее эффективный, но и самый медленный).
- Выберите степень сжатия (как показала практика, наиболее оптимальная — 7).
- Нажмите Применить.
- После окончания работы скрипта (станут активны кнопки Скачать файл и Вернуться), можно скачать файл по http (предварительно возможно понадобится настроить перехват расширений .sql, .gz и .bz2 в менеджеры загрузки) или скачать по FTP. Название файла состоит из названия базы данных, а также даты и времени создания дампа, для упрощения работы с файлами резервных копий.
Фильтры
В фильтре таблиц указываются специальные шаблоны по которым отбираются таблицы. В шаблонах можно использовать следующие специальные символы:
- символ * — означает любое количество символов
- символ ? — означает один любой символ
- символ ^ — означает исключение из списка таблицы или таблиц
Примеры:
- drupal_* - все таблицы начинающиеся с "drupal_"
- drupal_*, ^drupal_sessions - все таблицы начинающиеся с "drupal_", кроме "drupal_sessions"
- drupal_s*s, ^drupal_sessions - все таблицы начинающиеся с "drupal_s" и заканчивающиеся буквой "s", кроме "ib_sessions"
- ^*s - все таблицы, кроме таблиц заканчивающихся буквой "s"
- ^drupal_???? - все таблицы, кроме таблиц, которые начинаются с "drupal_" и содержат 4 символа после знака подчеркивания
Комментарии
Спасибо, полезно.
Написал в фильтре:
^cache*, ^search_index
Что еще можно исключить?
у меня почему то дампер не хочет работать
То есть начинает бекапить, и через какое то время, линия "загрузки" останавливается
Подозреваю, что лимит времени
Кто нибудь сталкивался?
Юзал недавно Sypex Dumper Lite с 6-кой, так он на таблице user ошибку по дубликату выдал. У всех такая фигня?
еще нужно добавить резервирование БД по расписанию.
Я не уверен, что это сильно влияет, но я перед бекапом делаю оптимизацию таблиц...
Влияет. Я Sypex Dumper Lite пользуюсь второй год. Замечательный скрипт. По опыту работы все траблы связаны не с ним, а с проделками хостеров. Один из последних опытов - для того, что бы отбиться от дос-атак хостер автоматом перегружает сервер во время прецедента. После установления такой практики заметил временами возникающую проблему. Дамп генерируется нормально. А вот при восстановлении вылетает ошибка. Как правило это ошибка нарушения синтаксиса SQL скрипта дампа одной из восстанавливаемых таблиц. Очень коварный трабл. Так вот профилактическая мера против этой ошибки - оптимизация таблиц перед дампованием. Или же надо сразу проверять дамп на восстановление (для чего надо иметь резервную область БД для экспериментов).
>Подозреваю, что лимит времени
Там в скрипте есть такой параметр. Но это так же может быть таймаут сессии установленный у хостера. Скорее всего второе, ибо в другом случае дампер бы выдал сообщение. Я тоже столкнулся в одно время с такой проблемой, когда хостер кувыркался, пытаясь поддержать видимость функционирования изрядно перегруженного сервера. Поменял хостера - дампер заработал
У меня 6-ка на разных (в том числе и проверенном) хостерах непереносилась. Сам непойму в чем дело, но думаю не в хостере. Кто нибудь 6-ку переносил Sypex Dumper-ом?
player перед дампом, отключи все модули и темы.
я пользую mysqldump
Navicat форевер!! Совету всем!
так он вроде не бесплатный...
конечно ничего не надо отключать
Меня не раз спасал дампер.
Я проверил: у Navicat есть 30-дневная версия и свободная версия (Lite Edition). Вот таблица различий: http://www.navicat.com/feature.html
Для Линукс версия для некоммерческого использования весит 20 MB!
Это продукт класса phpMyAdmin для управления базой данных. Для получения дампа и востановления этого инструмента многовато. Дампер весит 35 кб! А для управления есть phpMyAdmin. Зачем что-то менять?
Из дампа, лично я, ничего не исключаю. А вот при переносе с локалхоста на сервер исключаю:
Они очень большие и их можно не импортировать.
player я переносил шестерку, промучался с ней целый день. phpmyadmin не как не хотел правильный дамп делать. Sypex Dumper спас, на user запнулся, но эти последние таблицы phpmyadmin-ом задампил и все работает.
Нет всетаки сбились настройки, и комментариев нехватает.
Продолжаю мучаться, буду писать в своей теме http://drupal.ru/node/20253
locale* исключать, плохая мысль. Не все в совершенстве знают английский. Так зачем переводы не переносить?
скорее всего чтобы заново симпортировать, минус - много действий...
если не ошибаюсь - 1-е правило программиста PHP - "не использовать РНР там, для чего оно не предусмотрено", и автор этого правила, если не ошибаюсь сам автор РНР
Не проще ли использовать однострочную команду "mysqldump --user=root --password drupaldb > drupaldb.sql"?
По-моему далеко не спроста ее создали.
Так что поддерживаю несколько трезвых голосов, которые здесь упомянули именно этот метод.
IMHO до 1 правила есть ещё одно: Если у вас нет доступа к mysqldump на сервере -то используйте все другие имеющиеся возможности.
Лично я использую mysqldump, потому что есть шел и это быстрее, но не у всех есть...
Хотя, опять же лично я, вряд ли когда нибудь перееду на хостинг без шела. Это первый параметр, который меня интересует.
Скажите, а непосредственно в момент создания резервной базы данных сайт должен быть в off или on line?
ребята, советую изучить linux shell и юзать mysqldump.
Всем привет,
пытаюсь восстановить БД с помощью Sypex Dumper Lite 1.0.8 шкала прогресс бара застревает на 0%. Раньше все работало!
Может кто нибудь сталкивался? В чем проблема?
P.S. хостинг nic.ru
Почему mysql hot copy не упомянули? Хотелось бы подробностей об этом методе бэкапа.
эт конешно все хорошо... 5 Мб это еще не сложно востановить... Вы мне лучше подскажите как мне востановить 13 Мб бэкапа безболезненно, а то чего то не получается... или я что то не так делаю... !?
mysqldump
Консоль мускуля -> source
sypex
Я понял почему у меня такой большой бэкап - не исключил следующее:
надеюсь все получится...
в принципе их можно почистить