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

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

Материал из Linuxformat
Перейти к: навигация, поиск


Си­сад­ми­ну Уз­най­те, как под­дер­жи­вать ваш сайт 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.
  • Убе­ди­тесь, что все про­шло хо­ро­шо, вой­дя в жур­нал и про­ве­рив Ад­минист­ри­ро­вание > От­че­ты > Ста­тус.
  • Вы­клю­чи­те ре­жим тех­об­слу­жи­вания.
Персональные инструменты
купить
подписаться
Яндекс.Метрика