Резервная копия сайта

Главные вкладки

Аватар пользователя victorious victorious 1 мая 2010 в 11:29

Хочу сделать резервную копию всего сайта. Вроде бы база SQL сохраняется через phpMyAdmin в разделе "Экспорт", но так столько настроек, что просто не могу понять для чего они. Подскажите, как ее сохранить и нужно ли сохранять что-либо еще кроме этой базы?..

Комментарии

Аватар пользователя GDI@drupal.org GDI@drupal.org 1 мая 2010 в 15:27

backup_migrate
Очень легко делается копия сайта:
1. Делаете пофайловую копию сайта, т.е. просто копируете все файлы с сервера, например себе на локалхост в денвер.
2. С помощью указанного модуля делаете бэкап базы, настройки трогать не надо, можно оставить все по умолчанию, я лишь добавляю упаковку в gzip
3. На локалхосте просто восстанавливаете базу из каталога.

Аватар пользователя victorious victorious 1 мая 2010 в 18:24

а как ее "восстанавливать из каталога"? что-то я не пойму. где в локальном phpMyAdmin эту сохраненную базу данных подгружать?

Аватар пользователя GDI@drupal.org GDI@drupal.org 1 мая 2010 в 21:17

victorious wrote:
а как ее "восстанавливать из каталога"? что-то я не пойму. где в локальном phpMyAdmin эту сохраненную базу данных подгружать?
Это модуль, для него вообще phpMyAdmin не нужен, все делается из админ панели вашего сайта на друпале.

Аватар пользователя abarmot abarmot 2 мая 2010 в 10:20

mysqldump - хорошо.
backup_migrate - возможно даже лучше.

аргументы в пользу backup_migrate:

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

Сейчас мы используем связку amazon s3 + duplicity + backup_migrate для ежедневного бекапа.
Уже полгода все работает как часы и всем довольны.

Аватар пользователя Azerot Azerot 2 мая 2010 в 10:55

Недостатки backup_migrate которые можно назвать с ходу
1. Требует РАБОЧЕГО drupal, а в случае проблем - не работает
2. Возможны грабли с кодировками БД и таблиц, если кодировка БД по умолчанию отличается от кодировки конкретной БД (как это часто бывает в phpmyadmin)
3. Хостеры частно налагают ограничение на время выполнения PHP-скрипта. Как следствие дамп БД может просто не успеть сделаться.

Аватар пользователя GDI@drupal.org GDI@drupal.org 2 мая 2010 в 20:44

"Azerot" wrote:
3. Хостеры частно налагают ограничение на время выполнения PHP-скрипта. Как следствие дамп БД может просто не успеть сделаться.
А phpmyadmin разве не является php скриптом? Smile