Журнал LinuxFormat - перейти на главную

LXF155:Со­хра­нять Drupal

Материал из Linuxformat
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)


Си­сад­ми­ну Уз­най­те, как под­дер­жи­вать ваш сайт Drupal

Содержание

Ре­зерв­ные ко­пии Drupal

Джо­на­тан Ро­бертс нор­ма­ли­зу­ет ваш сон, нау­чив вас соз­да­вать ре­зерв­ные ко­пии и под­дер­жи­вать ос­нов­ные фай­лы Drupal.



Linux – ОС для Ин­тернета. Лю­ди лю­бят ее, по­то­му что она бес­плат­ная, бы­ст­рая и ста­биль­ная. Они так­же лю­бят ее, по­то­му что это иде­аль­ная плат­фор­ма для за­пуска од­ной из мно­гих сво­бод­ных и от­кры­тых сис­тем управ­ления кон­тен­том (CMS), та­ких как Drupal и Wordpress.

Рань­ше мы пуб­ли­ко­ва­ли учебники, по­ка­зы­ваю­щие вам, как на­чать ис­поль­зо­вать эти CMS, но они бы­ли со­сре­до­то­че­ны в основ­ном на на­чаль­ной уста­нов­ке и на­строй­ках. Тем не менее, за­пуск сай­та, будь то лич­но для се­бя или для сво­его бизнеса, не ог­раничи­ва­ет­ся этим.

Дру­гим, бо­лее важ­ным, фак­то­ром яв­ля­ет­ся по­сто­ян­ное об­нов­ление, ко­то­рое сле­ду­ет вы­пол­нять. По со­об­ра­жениям безо­пас­но­сти, вы долж­ны сле­дить за те­ку­щи­ми об­нов­ления­ми про­грамм­но­го обес­пе­чения, а так­же обес­пе­чи­вать це­ло­ст­ность дан­ных; сле­ду­ет вы­пол­нять ре­гу­ляр­ное ре­зерв­ное ко­пи­ро­вание ва­ше­го сай­та на слу­чай взло­ма, слу­чай­но­го уда­ления ба­зы дан­ных или пор­чи из-за сбо­ев же­ле­за.

На на­шем уро­ке мы по­ка­жем все необ­хо­ди­мое, что­бы дер­жать осно­ван­ный на Drupal сайт в хо­ро­шем со­стоянии – а имен­но ре­зерв­ное ко­пи­ро­вание и об­нов­ление.

Мы ис­поль­зу­ем Drupal в ка­че­­ст­ве при­ме­ра, по­то­му что он очень по­пу­ля­рен, и на­вы­ки, ко­то­рые вы по­лу­чи­те по ре­зерв­но­му ко­пи­ро­ванию в Drupal, мож­но бу­дет при­менить к ря­ду дру­гих CMS, в том чис­ле Joomla и WordPress. Начнем с ре­зерв­но­го ко­пи­ро­вания: жи­вой сайт без пред­ва­ри­тель­но­го осно­ва­тель­но­го ре­зерв­но­го ко­пи­ро­вания об­нов­лять не сто­ит. Итак, учи­ты­вая все ска­зан­ное вы­ше, при­сту­пим.

Пре­ж­де чем соз­дать ре­зерв­ную ко­пию все­го что ни на есть, важ­но от­сту­пить на­зад и по­ду­мать о стра­те­гии. Не зная, как час­то вы со­би­рае­тесь вы­пол­нять ре­зерв­ное ко­пи­ро­вание, для ка­ких фай­лов вы со­би­рае­тесь соз­дать ре­зерв­ную ко­пию, или как вы со­би­рае­тесь это де­лать, вы, ско­рее все­го, в конеч­ном ито­ге ока­же­тесь в сплошном завале: непол­ные ре­зерв­ные ко­пии, хра­ня­щие­ся где по­па­ло, не силь­но по­мо­гут, ес­ли при­дет­ся восста­нав­ли­вать­ся по­сле ка­та­ст­ро­фы.

Итак, час­то ли сле­ду­ет де­лать ре­зерв­ное ко­пи­ро­вание? На са­мом де­ле это за­ви­сит от за­груз­ки ва­ше­го сай­та. Ес­ли вы еже­днев­но по­лу­чае­те де­сят­ки но­вых по­стов и ком­мен­та­ри­ев, бы­ло бы ра­зумно вы­пол­нять ре­зерв­ное ко­пи­ро­вание ка­ж­дый день. А ес­ли жизнь на ва­шем сай­те го­раз­до ти­ше, и при­хо­дит лишь несколь­ко но­вых со­об­щений в неде­лю или ме­сяц, мож­но по­зво­лить се­бе де­лать ре­зерв­ную ко­пию ре­же.

Знать свой пре­дел

Час­то­та ре­зерв­но­го ко­пи­ро­вания мо­жет так­же дик­то­вать­ся ог­раничен­но­стью ре­сур­сов. Ес­ли у вас ма­ло мес­та для хранения и скромный бюд­жет на трафик, вы мо­же­те ре­шить де­лать ре­зерв­ную ко­пию ре­же, чем при неог­раничен­ных ре­сур­сах.

Ряд ог­раничений ре­сур­сов мож­но час­тич­но смяг­чить, внима­тель­но рас­смот­рев, для че­го вы бу­де­те де­лать ре­зерв­ную ко­пию. Drupal, на­при­мер, мо­жет быть в об­щем опи­сан как со­стоя­щий из трех ком­понен­тов:

  • Ос­нов­ные фай­лы, со­дер­жа­щие PHP, HTML, CSS и фай­лы кон­фи­гу­ра­ции, ко­то­рые ле­жат в осно­ве ра­бо­ты Drupal.
  • Со­пут­ст­вую­щие фай­лы, со­дер­жа­щие сто­ронние мо­ду­ли, поль­зо­ва­тель­ские те­мы и за­гру­жен­ные фай­лы.
  • Ба­за дан­ных, со­дер­жа­щая со­об­щения и ме­та­дан­ные, ком­мен­та­рии поль­зо­ва­те­лей и их на­строй­ки.

Да­же на бой­ком сай­те, где со­дер­жание ба­зы дан­ных ме­ня­ет­ся по несколь­ку раз на дню, ма­ло­ве­ро­ят­но, что вы бу­де­те ре­гу­ляр­но из­ме­нять основ­ные или со­пут­ст­вую­щие фай­лы. А зна­чит, мож­но соз­да­вать ре­зерв­ную ко­пию этих фай­лов ре­же – мо­жет быть, раз в ме­сяц – а ба­зу дан­ных ко­пи­ро­вать еже­днев­но. Это сэ­ко­но­мит вам зна­чи­тель­ные объ­е­мы дис­ко­во­го про­стран­ст­ва и про­пу­ск­ной спо­соб­но­сти.

Ог­раничения ре­сур­сов так­же мож­но обой­ти, вклю­чив в свою стра­те­гию ин­кре­мен­таль­ные ре­зерв­ные ко­пии. Вме­сто по­сто­ян­но­го вы­полнения пол­но­го ре­зерв­но­го ко­пи­ро­вания мож­но про­сто за­пи­сать из­менения с мо­мен­та по­следнего ко­пи­ро­вания. Объ­е­динив их, вы по­лу­чи­те са­мый ак­ту­аль­ный на­бор фай­лов для восста­нов­ления.

Вы­бе­ри­те ме­сто­по­ло­жение

Пре­ж­де чем рас­смат­ри­вать ре­зерв­ное ко­пи­ро­вание, при­кинь­те, где вы на­ме­ре­ны хранить ре­зерв­ные ко­пии.

Ре­зерв­ное ко­пи­ро­вание вас не спа­сет, ес­ли ко­пии хра­нят­ся на той же ма­шине, что и ис­ход­ный кон­тент. На са­мом де­ле, не очень хо­ро­шо, да­же ес­ли они хра­нят­ся в том же здании. Ес­ли ком­пь­ю­тер сло­мал­ся или слу­чил­ся по­жар, и ори­ги­нал, и ко­пии бу­дут унич­то­же­ны.

Принимая все ска­зан­ное во внимание, ка­кую сле­ду­ет вы­брать стра­те­гию для ре­зерв­но­го ко­пи­ро­вания? Ну, мы со­би­ра­ем­ся соз­да­вать ре­зерв­ную ко­пию основ­ных и со­пут­ст­вую­щих фай­лов раз в ме­сяц, а за­од­но и пол­ную ре­зерв­ную ко­пию ба­зы дан­ных; но, что­бы не по­те­рять об­нов­ления ме­ж­ду ре­зерв­ны­ми ко­пи­ро­вания­ми, бу­дем так­же де­лать еже­днев­ное ин­кре­мент­ное ре­зерв­ное ко­пи­ро­вание ба­зы дан­ных. Ре­зерв­ные ко­пии бу­дут соз­да­вать­ся на сер­ве­ре и хранить­ся в /home/<user>/backups/. Ин­кре­мент­ные ре­зерв­ные ко­пии бу­дут от­сы­лать­ся на уда­лен­ную ма­ши­ну раз в неде­лю, а на­ша еже­ме­сяч­ная пол­ная ре­зерв­ная ко­пия, в том чис­ле основ­ных и со­пут­ст­вую­щих фай­лов и ба­зы дан­ных, бу­дет вы­сла­на сра­зу по из­го­тов­лении.

Вме­сто веч­но­го хранения ре­зерв­ных ко­пий, что тре­бу­ет боль­шо­го про­стран­ст­ва для хранения, мы бу­дем за­ме­щать ре­зерв­ные ко­пии стар­ше шес­ти ме­ся­цев на сер­ве­ре и на уда­лен­ной ма­шине.

И, на­конец, от­ме­тим, что все на­ши ре­зерв­ные ко­пии бу­дут да­ти­ро­ва­ны. Та­ким об­ра­зом, в непред­ви­ден­ной си­туа­ции мы бу­дем точ­но знать, ка­кие ре­зерв­ные ко­пии са­мые по­следние и ка­кие из них наи­бо­лее под­хо­дят для восста­нов­ления.

Ко­пи­ро­вание фай­лов

Со­ста­вив план, да­вай­те по­смот­рим, как соз­дать ре­зерв­ную ко­пию ка­ж­до­го из ком­понен­тов, а за­тем – как объ­е­динить их вме­сте, что­бы по­лу­чить пол­ную ре­зерв­ную ко­пию.

Начнем с основ­ных и со­пут­ст­вую­щих фай­лов. Ос­нов­ные фай­лы Drupal хра­нят­ся в ка­та­ло­ге под на­званием “Drupal root folder”. Это та же пап­ка, ко­то­рую вы за­гру­зи­ли с сай­та при пер­вой уста­нов­ке, и те­перь, ско­рее все­го, она на­хо­дит­ся в корневом ка­та­ло­ге до­ку­мен­тов web-сер­ве­ра.

Со­пут­ст­вую­щие фай­лы по умол­чанию хра­нят­ся в под­пап­ке sites/ этой же ди­рек­то­рии.

Это зна­чи­тель­но все уп­ро­ща­ет: для соз­дания ре­зерв­ной ко­пии основ­ных и со­пут­ст­вую­щих фай­лов доста­точ­но соз­дать ар­хив

tar -cvzf /home/<user>/backups/drupal-files-backup-<date>.tar.gz /var/www/drupal/

В этом при­ме­ре мы ис­поль­зо­ва­ли оп­ции tar -c и -z, ука­зы­ваю­щие на соз­дание но­во­го ар­хи­ва и сжа­тия его по ал­го­рит­му gzip.

Мы так­же ис­поль­зо­ва­ли оп­цию -v, ко­то­рая ста­вит «раз­го­вор­чи­вый» ре­жим, и -f для вы­во­да ар­хи­ва на пер­вый ар­гу­мент. Вто­рой ар­гу­мент оп­ре­де­ля­ет ис­ход­ную пап­ку.

<user> мож­но за­менить на имя до­машнего ка­та­ло­га лю­бо­го поль­зо­ва­те­ля, где хра­нят­ся ре­зерв­ные ко­пии, а <date> – те­ку­щей да­той. В за­ви­си­мо­сти от на­стро­ек, вы так­же мо­же­те из­менить путь к корневой пап­ке Drupal (в на­шем слу­чае /var/www/drupal/).

Ко­пи­ро­вание ба­зы дан­ных

И это все, что тре­бу­ет­ся для ре­зерв­но­го ко­пи­ро­вания основ­ных и со­пут­ст­вую­щих фай­лов для Drupal. Те­перь по­ра взгля­нуть на то, как вы­полнить ре­зерв­ное ко­пи­ро­вание ба­зы дан­ных, и об­су­дить стра­те­гию.

Мы го­во­рим здесь о вы­бо­ре стра­те­гии, по­сколь­ку есть два спо­со­ба сде­лать это, ка­ж­дый со свои­ми плю­са­ми и ми­ну­са­ми.

Пер­вый ме­тод из­вес­тен как ло­ги­че­­ское ре­зерв­ное ко­пи­ро­вание. Он пред­по­ла­га­ет соз­дание еди­но­го фай­ла, вклю­чаю­ще­го опе­ра­то­ры язы­ка SQL (Structured Query Language) для восста­нов­ления ба­зы дан­ных. К ним от­но­сят­ся ин­ст­рук­ции CREATE DATABASE, CREATE TABLE и INSERT.

Вто­рой ме­тод из­вес­тен как фи­зи­че­­ская ре­зерв­ная ко­пия. Речь идет про­сто о соз­дании ко­пии фай­лов и ка­та­ло­гов, ко­то­рые пред­став­ля­ют со­бой ба­зу дан­ных, как мы де­ла­ли для основ­ных и со­пут­ст­вую­щих фай­лов Drupal.

До­ку­мен­та­ция MySQL со­дер­жит убе­ди­тель­ные ар­гу­мен­ты в поль­зу фи­зи­че­­ских ко­пий, ут­вер­ждая, что они бы­ст­рее и тре­бу­ют мень­ше мес­та для хранения ре­зерв­ных ко­пий, чем ло­ги­че­­ское ко­пи­ро­вание.

Ло­ги­че­­ское ре­зерв­ное ко­пи­ро­вание, од­на­ко, го­раз­до бо­лее гиб­кое (оно ра­бо­та­ет со все­ми движ­ка­ми хранилища MySQL, и копии мо­гут быть восста­нов­ле­ны на лю­бой ма­шине – че­го нель­зя ска­зать о фи­зи­че­­ских ре­зерв­ных ко­пи­ях), а их мед­ли­тель­ность и боль­шие тре­бо­вания к хранили­щу мож­но смяг­чить, де­лая ин­кре­мент­ные ко­пии.

Итак, мы все-та­ки оста­но­вим­ся на ло­ги­че­­ском ре­зерв­ном ко­пи­ро­вании. Од­на­ко не за­бы­вай­те о воз­мож­но­сти фи­зи­че­­ско­­го ко­пи­ро­вания: ес­ли ваш босс бу­дет не в востор­ге от мно­го­ча­со­во­го восста­нов­ления, оно по­дой­дет вам боль­ше!

Ин­кре­мент­ные ре­зерв­ные ко­пии

Что­бы сис­те­ма ре­зерв­но­го ко­пи­ро­вания ба­зы дан­ных за­ра­бо­та­ла, вклю­чая ин­кре­мент­ные ко­пии, на­до пре­ж­де все­го на­стро­ить MySQL на за­пуск с нуж­ны­ми па­ра­мет­ра­ми. Ин­кре­мент­ное ре­зерв­ное ко­пи­ро­вание по су­ти пред­став­ля­ет со­бой дво­ич­ный файл жур­на­ла MySQL, ско­пи­ро­ван­ный в безо­пас­ное ме­сто. По­это­му сле­ду­ет вклю­чить ве­дение жур­на­ла в дво­ич­ном ви­де. Что­бы вклю­чить эту функ­цию,

  • От­крой­те /etc/MySQL/my.cnf в лю­бом тек­сто­вом ре­дак­то­ре.
  • Най­ди­те раз­дел, по­ме­чен­ный [mysqld].
  • Убе­ди­тесь, что при­сут­ст­ву­ет log-bin.
  • Перезапустите MySQL командой

sudo service mysql restart

или ее эк­ви­ва­лен­том в ва­шем ди­ст­ри­бу­ти­ве.

По умол­чанию, дво­ич­ные жур­на­лы бу­дут хранить­ся в ка­та­ло­ге дан­ных (в боль­шин­ст­ве сис­тем это /var/lib/MySQL), с именем фай­ла, осно­ван­ном на имени хоста ком­пь­ю­те­ра, с рас­ши­рением .bin. Мож­но из­менить это, до­ба­вив =/path/to/log/<base-name> в стро­ку log-bin в /etc/mysql/my.cnf..

За­тем вы мо­же­те ис­поль­зо­вать это, что­бы все жур­на­лы пи­са­лись в еди­ное ка­нониче­­ское ме­сто ре­зерв­но­го ко­пи­ро­вания, ти­па /home/<user>/backups/incremental. Ес­ли вы сде­лае­те это, не за­будь­те из­менить пра­ва досту­па, что­бы поль­зо­ва­тель MySQL имел пра­во на запись в этом ка­та­ло­ге.

Вклю­чив эту функ­цию, вы мо­же­те соз­дать но­вую ин­кре­мент­ную ко­пию в лю­бое удоб­ное вре­мя, за­пустив:

mysqladmin -u <mysql-user> -p flush-logs

Со­глас­но на­шей стра­те­гии ре­зерв­но­го ко­пи­ро­вания, эта ко­ман­да долж­на вы­пол­нять­ся раз в день. Раз в неде­лю на­до так­же при по­мо­щи tar свя­зы­вать эти фай­лы вме­сте в да­ти­ро­ван­ной ре­зерв­ной ко­пии, ко­то­рая так­же по­ме­че­на как ин­кре­мент­ная, а за­тем со­хра­нять на уда­лен­ной сис­те­ме.

Пол­ное ло­ги­че­­ское ко­пи­ро­вание

На­стро­ив ин­кре­мент­ные ре­зерв­ные ко­пии, рас­смот­рим, как сде­лать пол­ное ре­зерв­ное ко­пи­ро­вание ба­зы дан­ных (без ко­то­ро­го на­ши ин­кре­мент­ные ре­зерв­ные ко­пии бы­ли бы бес­по­лез­ны!).

MySQL по­став­ля­ет­ся со скрип­том mysqldump, ав­то­ма­ти­зи­рую­щим этот про­цесс, и все, что вам нуж­но сде­лать – это вы­полнить ко­ман­ду

mysqldump -u <mysqluser> -p --single-transaction –flushlogs --master-data=2 --databases <databasename> > / home/<user>/backups/db-backup-<data>.sql

Рас­смот­рим эту ко­ман­ду по­под­робнее, что­бы по­нять, что про­ис­хо­дит:

  • -u <mysqluser> оп­ре­де­ля­ет, ка­кой поль­зо­ва­тель MySQL по­лу­ча­ет доступ к ба­зе дан­ных. Вы мо­же­те ука­зать су­пер­поль­зо­ва­те­ля-root или кон­крет­но­го поль­зо­ва­те­ля, имею­ще­го доступ к ба­зам дан­ных в Drupal. Ес­ли вы ука­же­те не-root, ему по­на­до­бят­ся при­ви­ле­гии RELOAD. Оп­ция -p ве­лит MySQL ав­то­ри­зо­вать поль­зо­ва­те­ля, за­пра­ши­вая па­роль.
  • --single-transaction га­ран­ти­ру­ет, что mysqldump ви­дит дан­ные толь­ко один раз – ес­ли ба­за дан­ных из­менит­ся во вре­мя ре­зерв­ного ко­пи­ро­вания, это не при­ве­дет к уве­ли­чению mysqldump, так как из­менения не бу­дут ему вид­ны.
  • --flush-logs за­пи­сы­ва­ет те­ку­щий жур­нал на диск. Тогда вы мо­жете быть уве­ре­ны, что лю­бые дан­ные, ко­то­рые не ви­дит mysqldump, вой­дут в ин­кре­мент­ные ко­пии.
  • --master-data=2 до­бав­ля­ет запись по­следнего фай­ла жур­на­ла к фай­лу пол­ной ре­зерв­ной ко­пии. Это по­зво­лит вам знать на­вер­ня­ка, ка­кие фай­лы жур­на­ла на­до ис­поль­зо­вать для восста­нов­ления при ин­кре­мент­ном ре­зерв­ном ко­пи­ро­вании.
  • --databases по­зво­ля­ет оп­ре­де­лить, для ка­ких баз дан­ных соз­да­вать ре­зерв­ную ко­пию. Вы мо­же­те ука­зать несколь­ко баз дан­ных, а так­же ис­поль­зо­вать --all-databases вме­сто это­го.
  • > Пе­ре­на­прав­ля­ет вы­вод mysqldump в лю­бой ука­зан­ный ва­ми файл. Как пра­ви­ло, mysqldump про­сто вы­во­дит дан­ные на stdout.

Когда ко­ман­да за­кон­чит вы­полнение, вы долж­ны получить пап­ку /home/<user>/backups, со­дер­жа­щую запись основ­ных и со­пут­ст­вую­щих фай­лов Drupal и баз дан­ных. Мож­но ис­поль­зо­вать tar, что­бы свя­зать эти фай­лы вме­сте и соз­дать пол­ную ре­зерв­ную ко­пию всех фай­лов, необ­хо­ди­мых для восста­нов­ления Drupal. Не за­будь­те ука­зать да­ту, мар­ки­ро­вать ар­хив как пол­ную ре­зерв­ную ко­пию и со­хранить его в безо­пас­ном мес­те – на дру­гой ма­шине.

Восста­нов­ление из ко­пии

От­лич­но! Те­перь у вас есть пол­ная ре­зерв­ная ко­пия, и вы так­же де­лае­те ре­гу­ляр­ные ин­кре­мент­ные ре­зерв­ные ко­пии со­дер­жи­мого, ко­то­рое из­ме­ня­ет­ся ча­ще все­го. Но это вас не силь­но спа­сет, по­сколь­ку вы не умее­те его восста­нав­ли­вать.

Что­бы из­бе­жать нелов­кой си­туа­ции, когда ва­ша сис­те­ма рух­ну­ла и у вас есть ре­зерв­ная ко­пия, но вы не знае­те, как ее при­менить, сде­ла­ем-ка учеб­ное восста­нов­ление.

Во-пер­вых, на­до уста­но­вить тес­то­вую ма­ши­ну. Мож­но ис­поль­зо­вать фи­зи­че­скую или вир­ту­аль­ную ма­ши­ну – ка­кая вам удобнее. За­тем уста­но­ви­те ди­ст­ри­бу­тив и убе­ди­тесь, что Apache и MySQL уста­нов­ле­ны и за­пу­ще­ны, вме­сте со все­ми PHP-за­ви­си­мо­стя­ми, нуж­ны­ми для Drupal. Помните, что уста­нов­ка по умол­чанию LAMP не всегда вклю­ча­ет php5-gd, на ко­то­рый ссы­ла­ет­ся Drupal, так что его то­же нуж­но уста­но­вить.

За­тем ско­пи­руй­те по­след­нюю пол­ную ре­зерв­ную ко­пию (ко­то­рая, как мы пред­по­ла­га­ем, со­дер­жит все основ­ные фай­лы, а не толь­ко под­пап­ку sites/) на ма­ши­ну, с по­мо­щью scp, rsync или лю­бо­го дру­го­го ин­ст­ру­мен­та, ко­то­рый вам нра­вит­ся. Кро­ме то­го, ско­пи­руй­те все ин­кре­мент­ные ре­зерв­ные ко­пии, сде­лан­ные со вре­мени по­следней пол­ной ре­зерв­ной ко­пии.

Из­вле­ки­те фай­лы с по­мо­щью tar ко­ман­дой

tar -xvzf full-backup-<date>.tar.gz

Здесь ключ -х ис­поль­зу­ет­ся для из­вле­чения фай­лов, в от­ли­чие от клю­ча -с, ко­то­рый мы ис­поль­зо­ва­ли ранее и ко­то­рый от­ве­ча­ет за соз­дание но­во­го па­ке­та. Когда вы это сде­лае­те, поя­вит­ся но­вая пап­ка в те­ку­щем ка­та­ло­ге, внут­ри ко­то­ро­го бу­дет ре­зерв­ная ко­пия фай­лов Drupal и ба­зы дан­ных.

Ес­ли вы сна­ча­ла из­вле­че­те со­дер­жи­мое ар­хи­ва drupal-фай­лов ко­ман­дой, ана­ло­гич­ной ко­ман­де вы­ше, вы по­лу­чи­те ста­рый корневой ка­та­лог Drupal об­рат­но. Ско­пи­руй­те его пря­мо в корневой ка­та­лог до­ку­мен­тов но­во­го web-сер­ве­ра.

За­тем восста­но­ви­те ба­зу дан­ных с по­мо­щью фай­ла .sql от mysqldump и со­от­вет­ст­вую­щего на­бора ин­кре­мент­ных ко­пий:

mysql -u <user> -p < backups/db-backup-<date>.sql

Эта ко­ман­да вы­полнит все ко­ман­ды SQL, со­дер­жа­щие­ся в фай­ле, восста­но­вив таб­ли­цы ба­зы дан­ных, стро­ки, столб­цы и т. д.

В за­вер­шение восста­нов­ления ба­зы дан­ных при­мените ин­кре­мент­ные ре­зерв­ные ко­пии, что­бы ее со­дер­жи­мое со­от­вет­ст­во­ва­ло по­следним из­менениям. Для это­го ско­ман­дуй­те

mysqlbinlog inc-backup-file-1 inc-backup-file-2 ... | mysql -u <user> -p

Тепрь поч­ти все ра­бо­та­ет, но при по­пыт­ке по­лу­чить доступ к сай­ту Drupal вы по­лу­чи­те со­об­щение об ошиб­ке. Это оз­на­ча­ет, что Drupal еще не име­ет досту­па к сер­ве­ру MySQL и его ба­зам дан­ных.

Что­бы ис­пра­вить это, мож­но на­стро­ить Drupal, ука­зав но­во­го поль­зо­ва­те­ля и па­роль для MySQL, или соз­дать но­во­го поль­зо­ва­те­ля MySQL, имею­ще­го те пол­но­мо­чия, на ис­поль­зо­вание ко­то­рых Drupal уже на­стро­ен.

В по­следнем слу­чае, про­сто по­вто­ри­те ин­ст­рук­ции из на­шей врез­ки Ус­та­нов­ка Drupal для пре­достав­ления при­ви­ле­гий поль­зо­ва­те­ля на работу с ба­зой дан­ных Drupal.

Вот и все. Те­перь у вас есть воз­мож­ность по­се­тить ва­шу уста­нов­ку Drupal, ве­ро­ят­но, зайдя на http://localhost/drupal или нечто подобное, в за­ви­си­мо­сти от то­го, что вы ус­та­но­ви­ли на тес­то­вой ма­ши­не.

Скрип­ты для ко­пи­ро­вания

Знать, как вы­полнить ре­зерв­ное ко­пи­ро­вание – толь­ко по­ло­ви­на про­бле­мы. Обес­пе­чение ре­гу­ляр­но­го ре­зерв­но­го ко­пи­ро­вания по гра­фи­ку – дру­гая ее по­ло­ви­на. Не­что спеш­ное всегда при­во­дит к пре­ры­ванию ре­зерв­но­го ко­пи­ро­вания, и оно от­кла­ды­ва­ет­ся на по­том.

Луч­ший спо­соб из­бе­жать та­ко­го ро­да про­блем – скрипт ре­зерв­но­го ко­пи­ро­вания и ис­поль­зо­вание за­дания cron, обес­пе­чи­ваю­ще­го ав­то­ма­ти­че­­ский за­пуск по уста­нов­лен­но­му рас­пи­санию.

Мы не бу­дем объ­яс­нять это здесь под­роб­но: вам тре­бу­ет­ся все­го-на­все­го со­брать все ко­ман­ды на­ше­го уро­ка в один файл .sh, а за­тем про­чи­тать man-страницу cron, что­бы уста­но­вить ав­то­ма­ти­че­­ский за­пуск скрип­та.

А что касается ав­то­ма­ти­за­ции ведения дво­ич­но­го жур­на­ла, мож­но обой­тись и без cron. От­крой­те файл /etc/mysql/my.cnf сно­ва, и в раз­де­ле [mysqld], где вы вклю­ча­ли log_bin, до­бавь­те max_binlog_size и уста­но­ви­те его в от­но­си­тель­но неболь­шое зна­чение. Та­ким об­ра­зом, вся­кий раз, когда дво­ич­ный жур­нал достигнет оп­ре­де­лен­но­го раз­ме­ра, MySQL бу­дет ав­то­ма­ти­че­­ски очи­щать жур­нал.

Это не со­всем то же, что сброс жур­на­лов ка­ж­дый день, но име­ет та­кой же эф­фект.

Дру­гие web-при­ло­жения

Как мы на­мек­ну­ли во вве­дении к этой ста­тье, ре­зерв­ное ко­пи­ро­вание дру­гих web-при­ло­жений час­то сле­ду­ет про­це­ду­рам, очень по­хо­жим на ис­поль­зо­ван­ные здесь. Но что это за при­ло­жения?

Ну, для на­ча­ла, есть Wordpress, очень по­пу­ляр­ная блог-плат­фор­ма. Хо­тя это со­вер­шен­но раз­ные плат­фор­мы, ре­зерв­ное ко­пи­ро­вание Wordpress идет прак­ти­че­­ски че­рез ту же про­це­ду­ру: ко­пи­ро­вание ба­зы дан­ных и ко­пи­ро­вание основ­ных фай­лов.

Так­же есть Joomla. На са­мом де­ле это про­из­вод­ная Drupal, и ее про­це­ду­ра ре­зерв­но­го ко­пи­ро­вания точ­но та­кая же. А ес­ли вы ра­бо­тае­те на Wiki MediaWiki или в фо­ру­ме phpBB? Без про­блем, про­це­ду­ра и здесь та­кая же!

Итак, поль­зуй­тесь вновь об­ре­тен­ны­ми на­вы­ка­ми управ­ления лю­бым из этих web-при­ло­жений, и спокойный сон но­чью вам га­ран­ти­ро­ван.

Об­нов­ление Drupal

(thumbnail)
При обновлении Drupal не забудьте включить режим обслуживания

Об­нов­ление Drupal так же важ­но, как под­дер­жание ре­гу­ляр­но­го ре­зерв­но­го ко­пи­ро­вания – по крайней ме­ре, не менее важ­но, чем об­нов­ления по­сле ма­лых ре­ли­зов. Это обес­пе­чи­вает безо­пас­ность и ис­прав­ля­ют ошиб­ки, де­лая ваш сайт бо­лее безо­пас­нем и менее под­вер­жен­ным сбо­ям – ко­ро­че, обновления сде­ла­ют ва­шу жизнь в ро­ли сис­тем­но­го ад­минист­ра­то­ра менее на­пря­жен­ной!

Пе­ред вы­полнением лю­бых об­нов­лений сде­лай­те пол­ную ре­зерв­ную ко­пию ва­ше­го сай­та. По­сле это­го мож­но об­но­вить сайт Drupal 7.x на дру­гой ре­лиз вер­сии 7.x.

  • За­гру­зи­те по­след­нюю вер­сию Drupal и рас­па­куй­те ее со­дер­жи­мое.
  • Вой­ди­те в Drupal как поль­зо­ва­тель с пра­ва­ми ад­минист­ра­то­ра и уста­но­ви­те сайт в ре­жим тех­об­слу­жи­вания, вы­брав Кон­фи­гу­ра­ция > Ад­минист­ри­ро­вание > Раз­ви­тие > Ре­жим тех­об­слу­жи­вания.
  • Уда­ли­те из корневой ди­рек­то­рии Drupal все фай­лы, при­над­ле­жа­щие к ста­рой вер­сии, кро­ме фай­лов sites/ и profiles/.
  • Ско­пи­руй­те но­вые фай­лы, за­гру­жен­ные с сай­та Drupal, об­рат­но в корневой ка­та­лог Drupal.
  • За­пусти­те скрипт update.php, что­бы пе­ре­на­стро­ить ба­зу дан­ных по domain.name/drupal/update.php.
  • Убе­ди­тесь, что все про­шло хо­ро­шо, вой­дя в жур­нал и про­ве­рив Ад­минист­ри­ро­вание > От­че­ты > Ста­тус.
  • Вы­клю­чи­те ре­жим тех­об­слу­жи­вания.
Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF155:%D0%A1%D0%BE%C2%AD%D1%85%D1%80%D0%B0%C2%AD%D0%BD%D1%8F%D1%82%D1%8C_Drupal&oldid=16546»
Персональные инструменты
купить
подписаться
Яндекс.Метрика