2 марта 2021 в 13:39
$ dr archive-dump --destination=../backups/site_backup.tar.gz
Database dump saved to c:\openserver\userdata\temp/drush_tmp_1614680771_603e12c33994a/site.sql [success]
Archive saved to C:\OpenServer\domains\backups/site_backup.tar.gz
Database dump saved to c:\openserver\userdata\temp/drush_tmp_1614680771_603e12c33994a/site.sql [success]
Archive saved to C:\OpenServer\domains\backups/site_backup.tar.gz
Архив файловой структуры создается. А вот дампа БД по указанному адресу не наблюдается.
Почему не работает? Как сделать чтобы работало?
Комментарии
drush sql-dump > mart2.sql
tar -cvzf mart2.tar.gz mart2.sql
rm -rf mart2.sql
То, что можно другими командами создать отдельно и бэкап и дамп - безусловно. Но раз есть одна команда специально для этого, то хотелось бы заставить ее работать. Ведь и восстанавливаться тоже одной командой намного проще.
A tar-то тут зачем?
drush sql-dump | gzip -6 > mart2.sql.gzНу, я пока не все команды наизусть знаю. Adminer tar.gz жрет. Это для друга, а не для меня
А разархивировать полученный архив какой командой?
Вот разные варианты:
gzip -d filename.gz
zcat filename.gz | mysql dbname
А tar нужен для того, чтобы упаковать дерево каталогов с атрибутами правами и.т.п. в один файл. Когда файл и так один, в нем просто нет смысла.
В архиве всё должно быть, если settings.php рабочий.
Хотя все может быть с виндой и 8-ым драшем...
а как понять рабочий или нет settings.php? В принципе сайт-то работает, все ок.
А если слэши в обратную сторону повернуть?
На винде вроде так правильно:
--destination=..\backups\site_backup.tar.gzP.S. Без destination нормально всё?
разобрался вобщем... оказывается, тот путь с дампом БД - он временный. Драш сбрасывает туда дамп, пока делается архив файловой структуры. Когда архив готов, дамп переносится в архив, а временная папка удаляется. В финальном бэкапе и файловая структура и дамп БД.
только осваиваю drush, поэтому и возникают такие нелепые ошибки.
Ну как и сказал, смотрите архив...
Кстати, в более новых версиях драша, этой команды уже нет. В 9-ой, точно.
нет команды для бэкапа сайта?
Зачем делать бэкап драшем, когда есть консольные утилиты сервера?
А какие? И какими командами сделать файловый бекап без всякого мусора из папок файловой системы типа:
css
js
php
styles
Я только стереть и заархивировать могу.
tar или rsync
drush8 делает это одной командой. И файлы и бд. И восстанавливает тоже одной командой. Это удобно. Особенно, при переносах сайта.
Зачем Друпал, когда есть PHP? Зачем PHP, когда есть ассемблер? ;))
Драш до сих пор есть не на всех хостингах, а на многих нужно поплясать с бубном, чтобы его завести. А tar, rsync, mysqldump точно есть везде)
Я кстати, регулярно пишу сайты на C++ (esp8266). Так что в этой шутки есть не только шутка.
Ну а я много писал на ассемблере PDP11 (не сайты,конечно) лет 35 назад, и даже восьмеричные коды команд в уже скомпилированном исполняемом файле доводилось править руками (и я их знал и помнил, эти коды). Но зачем так делать, когда есть более эффективные инструменты? Вот когда их нет, тогда другое дело.
В некоторый местах где Драша нет, его можно установить Композером. Но наверное хостинг может и заблокировать подобное.
на друпале 7 вот так делаю единичный бэкап с копированием на уделенный сервер. обычно перед работой по изменению сайта:
myfilename=mysite$( date +%H.%M_%d.%m.%Y ).tar
#echo -$myfilename-
#make archive
drush --root=/home/$dirofusername/public_html vset site_offline 1
drush archive-dump default --root=/home/$dirofusername/public_html --destination=/home/$dirofusername/myetcandwork/$myfilename
drush --root=/home/$dirofusername/public_html vset site_offline 0
#backup
scp ./$myfilename username@jura12.ru:~
а вы не знаете, как сделать бэкап только ядра? Перед обновлением этого самого ядра?
вам только ядро не нужно. надо бэкапить все иначе сайт работать не будет. если хотите уменьшить размер бэкапа то надо использовать инкрементальный бэкап с помощью duplicity . но не на всех хостингах он установлен. есть еще варианты с использованием rsync . но эту тему я прорабатываю.
у меня есть сайты, которые весят по несколько гигабайт. А все что нужно - обновить ядро. По-моему, логично делать бэкап именно того, что будет меняться. К слову, команда drush up drupal - такой бэкап делает. Но только имею негативный опыт: в случае, если накатывание обновления ядра происходит с ошибками - бэкап не создается. То есть именно тот случай, когда бэкап необходим, чтобы откатиться, а он не создался.
у меня тоже есть такая проблема. сайт друпала 7 на 2 гига. планирую делать по ssh sync на удаленный сервер. а там по накатанной дороге инкрементальный duplicity.
Для бэкапа сейчас очень удобно git использовать
а как именно? опишите алгоритм, плиз.
Обычный алгоритм работы с git. Делаете коммит текущего состояния. Обновляете файлы. Если что-то пошло не так, делаете git reset и откатываетесь к состоянию последнего коммита. Но как уже сказали, бэкап БД всё равно нужно делать отдельно, потому что после выполнения обновления БД её уже нельзя будет использовать со старыми файлами (до обновления)
спасибо!
с git-ом я тоже пока на вы. Как и drush предстоит все это на хостинге установить. Пока что все эксперименты на локальной машине на винде.
В отличие от drush, git на хостингах встречается гораздо чаще
Рекомендую rsnapshot: rsync в отличии от duplicity есть практически везде, куда пускают по ssh. А ему большее и не нужно.
Но ведь меняться может ещё и БД. Представьте себе такой сценарий: Вы обновляете файлы ядра, запускаете update.php, который обновляет БД в соответствии с требованиями новой версии, всё проходит успешно, только... сайт не работает, ну или жестоко глючит - вполне реальная ситуация. Если Вы просто восстановите из бэкапа старые файлы ядра, то они не будут работать с обновленной структурой БД.
согласен, поэтому и актуально было бы делать бэкап ядра + БД. Командой drush. А не бэкап всего сайта.