Настрой бэкап в Laravel сегодня — это быстро и совсем не больно

На днях в чате Laravel-разработчиков я увидел сообщение, от которого у меня буквально зашевелились волосы на спине:

То, что нужно настраивать резервное копирование своих БД, понимают вроде бы все. Но не всегда до бэкапа доходят руки.

Почему? Причины могут быть разными. Самые рядовые:

1. Неопытность пользователя.Запустил тесты, случайно очистил БД, неудачно обновил приложение, случайно нажал не ту кнопку, кошка запрыгнула на клавиатуру и запустила команду sudo rm -rf /var/lib/mysql и т.д.
2. Поломка дисков на сервере.
3. Заражение сайта вирусами. Мошейник нашел дыру в приложении и все удалил.
4. Пожар в дата-центре (и такое бывает)
5. И ещё миллион случайностей.

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

Бэкап вам понадобится ровно тогда, когда делать его будет поздно, сервер перестанет работать или приложение скажет, что БД не смогло, ну извини.

Как и когда делать резерные копии:

• бэкап должен быть автоматическим. Ручной бэкап можно забыть сделать, кому-то будет лень или человек будет уверен, что он бог бэкапа и уже всё забэкапил и т.п.
• Перед деплоем. Во время деплоя что-то может пойти не так, например, миграции содержат ошибку, и всё будет удалено.
• Ежедневно по расписанию — частота бэкапов зависит от критичности. Во время выполнения основная производительность всего сервера может сильно проседать, поэтому создание резервных копий обычно планируют на период минимальной активности.

Ниже я расскажу, как это сделать в ваших Laravel проектах в 3 шага.

Что потребуется от вас:

• Laravel;
• Deployer;
• Linux;
• облачное хранилище, а лучше несколько (s3, dropbox, google drive);
• mysqldump или pg_dump или mongodump в зависимости от используемого типа БД;
• базовые знания в PHP и установке composer пакетов.

Шаг 1. Настройка бэкапа по расписанию

Начнём с установки одного из самых популярных пакетов для создания резервных копий Spatie’s backup пакета. Этот пакет нужен, чтобы создавать дампы БД и файловой системы, и при необходимости загружать их в облачное хранилище.

$ composer require spatie/laravel-backup

Публикуем конфиг файл:

$ php artisan vendor:publish --provider="Spatie\Backup\BackupServiceProvider"

Добавляем необходимые задачи в планировщик:

// Удаление устаревших резервных копий 
$schedule->command('backup:clean')->dailyAt('01:30');
// Создание резеврной копии
$schedule->command('backup:run --only-db')->dailyAt('01:35');

Планировщик следит за тем, чтобы архив резервных копий не разрастался, а оставались последние n копий. Это настраивается через конфиг.

Открываем конфиг config/backup.phpи указываем места где мы хотим хранить наши резервные копии, например

'disks' => [
    's3',                
    'local',             
],

Очень советую настроить отправку резервных копий в облачное хранилище, а лучше продублировать в несколько разных. Это сохранит резервную копию в случае повреждения диска на production сервере, а также если одно из облачных хранилищ случайно потеряет ваши данные.

Данный пакет берет настройки дисков из конфига config/filesystems.php О подключении драйверов для сторонних облачных хранилищ можно почитать здесь.

Затем указываем БД, для которых мы собственно и создаём резервные копии. Полное описание можно посмотреть в документации.

'databases' => [
    'pgsql',
    'mysql',
    '...',
],

В результате мы получаем автоматическое создание резервных копий по расписанию.

Важно: проверьте, что scheduler добавлен в cron сервера.

Шаг 2. Настройка бэкапа при деплое

Для деплоя проекта на prod серверах я использую deployer, в котором удобно спланировать нужную последовательность команд при обновлении проекта.

Начнем с установки инструмента на нашей локальной машине:

$ curl -LO https://deployer.org/deployer.phar
$ mv deployer.phar /usr/local/bin/dep
$ chmod +x /usr/local/bin/dep

Далее переходим в папку нашего проекта и запускаем инициализацию конфига деплоя:

$ cd /home/.../my-super-project
$ dep init

И отвечаем на вопросы, после чего для нашего проекта будет сгенерирован конфиг deploy.php

<?php
namespace Deployer;
require 'recipe/laravel.php';
...
// Migrate database before symlink new release.
before('deploy:symlink', 'artisan:migrate');

Содержимое recipe/laravel.php можно изучить здесь.

В сценарии выше после успешного деплоя на сервере запускается команда миграции БД. Мы добавим ещё одну задачу — перед собственно миграцией запустим создание резервной копии.

task('artisan:backup:run', function () {
    run('{{bin/php}} {{release_path}}/artisan backup:run --only-db');
});
// Create backup before migration
before('artisan:migrate', 'artisan:backup:run');

Окончательный вариант конфига будет выглядеть например так:

<?php
namespace Deployer;
require 'recipe/laravel.php';
// Project name
set('application', 'my_project');
// Project repository
set('repository', 'git@bitbucket.org:test/my_project.git');
// [Optional] Allocate tty for git clone. Default value is false.
set('git_tty', true);
// Shared files/dirs between deploys 
add('shared_files', []);
add('shared_dirs', []);
// Writable dirs by web server 
add('writable_dirs', []);
// Hosts
host('my_project.com')
    ->set('deploy_path', '~/{{application}}');    
    
// Tasks
task('artisan:backup:run', function () {
    run('{{bin/php}} {{release_path}}/artisan backup:run --only-db');
});
// [Optional] if deploy fails automatically unlock.
after('deploy:failed', 'deploy:unlock');
// Migrate database before symlink new release.
before('deploy:symlink', 'artisan:migrate');
// Create backup before migration
before('artisan:migrate', 'artisan:backup:run');

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

$ dep deploy

Шаг 3. Настройка CI/CD

Далее мы можем настроить CI/CD для автоматического запуска деплоя на стороне Git сервера.

Пример конфига для bitbucket pipelines

// bitbucket-pipelines.yml
pipelines:
  branches:
    master:
      - step:
          name: Deploy to production server
          deployment: Production
          image: php:7.4-alpine
          script:
            - apk update --no-cache && apk add --no-cache openssh-client
            - curl -L https://deployer.org/deployer.phar > /usr/local/bin/dep && chmod +x /usr/local/bin/dep
            - dep deploy

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

P.S. Если интересно узнать больше про автоматизацию деплоя проекта на stage и production сервера — оставляйте комментарий и лайки.

Следите за моими публикациями в моем Тви: https://twitter.com/ButscH

Редактор текста — Ольга Т.