Интеграция Laravel Spatie/Backup с S3-хранилищем

В этой инструкции узнаете, как интегрировать пакет Spatie/Backup с облачным хранилищем, таким как S3. Этот процесс позволяет автоматизировать создание, проверку и управление резервными копиями приложения в Laravel, что обеспечивает высокую надежность данных и минимизирует риски их потери.

Рассмотрим шаги настройки, начиная с установки пакета и конфигурирования S3-хранилища, и заканчивая созданием автоматических уведомлений о состоянии резервных копий. Пример использует базу данных SQLite, но вы сможете легко адаптировать инструкцию под MySQL или другие СУБД.

После завершения этой инструкции вы:

• Освоите установку и настройку Spatie/Backup.
• Создадите планировщик задач для автоматизации резервного копирования.
• Настроите уведомления для мониторинга состояния резервных копий.

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

1. Установка Spatie/Backup

Установите пакет Spatie/Backup с помощью Composer:

composer require spatie/laravel-backup

Опубликуйте файл конфигурации пакета:

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

После выполнения команды в директории config/ появится файл backup.php.

2. Настройка подключения к S3

В файле config/filesystems.php добавьте настройки для S3-хранилища.

3. Настройка Spatie/Backup для использования S3

Шаг 1. В файле config/backup.php найдите секцию disks и укажите используемый диск:

'backup' => [
    'name' => env('APP_NAME', 'laravel-backup'),
    'disks' => [
        'tws3', // Указываем S3 как диск для резервного копирования
    ],
],

Шаг 2. В секции databases закомментируйте mysql:

'databases' => [
//'mysql',
],

Шаг 3. Настройте секцию monitorBackups:

'monitorBackups' => [
    [
        'name' => env('APP_NAME', 'laravel-backup'),
        'disks' => ['tws3'],
        'health_checks' => [
            \Spatie\Backup\Tasks\Monitor\HealthChecks\MaximumAgeInDays::class => 7,
            \Spatie\Backup\Tasks\Monitor\HealthChecks\MaximumStorageInMegabytes::class => 5000,
        ],
    ],
],

Секция monitorBackups в конфигурационном файле config/backup.php отвечает за контроль состояния резервных копий. В этой секции можно настроить автоматическую проверку их актуальности и соответствия заданным параметрам.

Рассмотрим подробнее два ключевых параметра проверки:

• MaximumAgeInDays::class => 7

Этот параметр отвечает за контроль максимального возраста резервной копии.

Пояснение:

• MaximumAgeInDays::class — класс проверки, который оценивает, не устарели ли резервные копии.

• 7 — максимальное количество дней, в течение которых резервная копия считается актуальной. Если самой «свежей» резервной копии больше 7 дней, система уведомит вас о проблеме.

Пример: Если сегодня 7 декабря, а последняя резервная копия была создана 29 ноября (более 7 дней назад), то при выполнении проверки вы получите уведомление о необходимости создать новую резервную копию.

• MaximumStorageInMegabytes::class => 5000

Этот параметр отвечает за контроль объема дискового пространства, занятого резервными копиями.

Пояснение:

• MaximumStorageInMegabytes::class — класс проверки, который анализирует общий объем всех резервных копий.

• 5000 — допустимый лимит хранилища в мегабайтах. Если общий объем резервных копий на указанном диске превышает 5000 МБ (5 ГБ), система уведомит вас о необходимости очистки или оптимизации хранения.

Пример: Если на вашем S3-диске накопилось резервных копий на 6 ГБ, система сообщит, что объем хранилища превышает установленный лимит, предлагая пересмотреть стратегию хранения.

Шаг 4. Настройте секцию cleanup:

'cleanup' => [
    /*
     * Стратегия, используемая для очистки старых резервных копий.
     * DefaultStrategy - стандартная стратегия, которая сохраняет резервные
     * копии в течение определенного времени, а затем упрощает их структуру:
     * - Все копии сохраняются несколько дней.
     * - Затем остаются только ежедневные, недельные и т.д.
     * Последняя резервная копия никогда не удаляется.
     */
    'strategy' => \Spatie\Backup\Tasks\Cleanup\Strategies\DefaultStrategy::class,

    'default_strategy' => [

        /*
         * Количество дней, в течение которых сохраняются все резервные копии.
         * Оптимально для восстановления данных в короткие сроки.
         */
        'keep_all_backups_for_days' => 7, // Храним все копии за последнюю неделю.

        /*
         * Количество дней, в течение которых сохраняются ежедневные резервные копии.
         * После этого сохраняются только еженедельные копии.
         */
        'keep_daily_backups_for_days' => 30, // Храним ежедневные копии за последний месяц.

        /*
         * Количество недель, в течение которых сохраняется одна еженедельная копия.
         * Полезно для восстановления данных за последние месяцы.
         */
        'keep_weekly_backups_for_weeks' => 12, // Храним еженедельные копии за последние 3 месяца.

        /*
         * Количество месяцев, в течение которых сохраняется одна ежемесячная копия.
         * Удобно для долгосрочного хранения данных.
         */
        'keep_monthly_backups_for_months' => 6, // Храним ежемесячные копии за последние полгода.

        /*
         * Количество лет, в течение которых сохраняется одна ежегодная копия.
         * Рекомендуется для архивации важных данных.
         */
        'keep_yearly_backups_for_years' => 2, // Храним ежегодные копии за последние 2 года.

        /*
         * Максимальный объем хранилища в мегабайтах, после которого
         * начинают удаляться самые старые резервные копии.
         */
        'delete_oldest_backups_when_using_more_megabytes_than' => 10000, // Ограничение хранилища до 10 ГБ.
    ],
],

Здесь мы настраиваем параметры:

1. Краткосрочные резервные копии
   Хранение всех резервных копий за последнюю неделю keep_all_backups_for_days позволяет оперативно восстановить данные, если сбой произошел недавно.

2. Среднесрочное восстановление
   Ежедневные копии за месяц и еженедельные за 3 месяца keep_daily_backups_for_days, keep_weekly_backups_for_weeks покрывают большинство стандартных бизнес-случаев.

3. Долгосрочная архивация
   Ежемесячные и ежегодные копии keep_monthly_backups_for_months, keep_yearly_backups_for_years полезны для хранения данных на случай редких запросов или юридических требований.

4. Ограничение объема
   Указанный лимит в 10 ГБ позволяет эффективно управлять хранилищем, удаляя устаревшие копии при необходимости. Если объем данных большой, этот параметр можно увеличить.

Эти настройки подходят для большинства приложений среднего масштаба. Для больших проектов или систем с ограниченным хранилищем параметры можно скорректировать.

cloud

4. Настройка уведомлений

Spatie/Backup поддерживает отправку уведомлений о выполнении резервного копирования или его сбоях через различные каналы, включая электронную почту. В этом пункте мы настроим уведомления для отправки сообщений по электронной почте.

Шаг 1. Настройка уведомлений в config/backup.php

Откройте файл config/backup.php и отредактируйте секцию notifications, чтобы включить уведомления через email:

'notifications' => [
    \Spatie\Backup\Notifications\Notifications\BackupHasFailedNotification::class => ['mail'],
    \Spatie\Backup\Notifications\Notifications\UnhealthyBackupWasFoundNotification::class => ['mail'],
    \Spatie\Backup\Notifications\Notifications\CleanupHasFailedNotification::class => ['mail'],
    \Spatie\Backup\Notifications\Notifications\BackupWasSuccessfulNotification::class => ['mail'],
    \Spatie\Backup\Notifications\Notifications\HealthyBackupWasFoundNotification::class => ['mail'],
    \Spatie\Backup\Notifications\Notifications\CleanupWasSuccessfulNotification::class => ['mail'],
],

• BackupHasFailedNotification

  • Описание: Уведомляет о том, что процесс резервного копирования завершился с ошибкой.

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

• UnhealthyBackupWasFoundNotification

  • Описание: Уведомляет о том, что найдена резервная копия, не соответствующая заданным параметрам (например, устарела или превышает лимит размера).

  • Зачем нужно: Позволяет проверить состояние резервных копий и обновить или удалить их при необходимости.

• CleanupHasFailedNotification

  • Описание: Сообщает, что процесс очистки старых резервных копий завершился с ошибкой.

  • Зачем нужно: Это сигнализирует о необходимости ручной очистки или устранения проблем с доступом к хранилищу.

• BackupWasSuccessfulNotification

  • Описание: Уведомляет о том, что резервное копирование успешно выполнено.

  • Зачем нужно: Позволяет быть уверенным, что резервные копии создаются корректно и в соответствии с расписанием.

• HealthyBackupWasFoundNotification

  • Описание: Сообщает, что состояние резервных копий удовлетворяет всем заданным параметрам.

  • Зачем нужно: Подтверждает, что резервные копии находятся в хорошем состоянии и готовы к использованию.

• CleanupWasSuccessfulNotification

  • Описание: Уведомляет о том, что процесс очистки старых резервных копий завершился успешно.

  • Зачем нужно: Помогает убедиться, что хранилище поддерживается в актуальном состоянии.

Шаг 2. Добавьте email-адрес в .env

В файле .env укажите email-адрес, на который будут приходить уведомления:

NOTIFICATION_EMAIL=test@example.com

Шаг 3. Настройка почтового драйвера

Laravel поддерживает несколько почтовых драйверов, таких как SMTP, Mailgun и другие. Однако для тестовой среды или в случаях, когда отправка реальных писем не требуется, можно использовать драйвер log, который записывает все почтовые сообщения в системный журнал Laravel.

MAIL_MAILER=log
MAIL_FROM_ADDRESS=hello@example.com
MAIL_FROM_NAME="Laravel Backup"

• MAIL_MAILER=log — Указывает, что для отправки писем будет использоваться логирование, а не реальная доставка.

• MAIL_FROM_ADDRESS=hello@example.com — Адрес отправителя, который будет использоваться в уведомлениях. Этот адрес должен быть валидным в соответствии с RFC 2822.

• MAIL_FROM_NAME="Laravel Backup" — Имя отправителя, отображаемое в заголовке писем.

Важно: Если MAIL_FROM_ADDRESS оставить пустым или указать некорректный адрес, это приведет к ошибке: Address in mailbox given [] does not comply with RFC 2822, 3.6.2.

Шаг 4. Тестирование уведомлений

Выполните резервное копирование вручную:

php artisan backup:run

Проверьте логи в файле storage/logs/laravel.log. Вы должны увидеть запись о том, что отправка уведомления прошли успешно.

Чтобы проверить уведомление о сбое, временно введите неправильные параметры (например, неверное имя бакета S3) и повторите команду:

php artisan backup:run

Проверьте логи в файле storage/logs/laravel.log.

5. Настройка планировщика задач

Добавьте задание резервного копирования в файл app/Console/Kernel.php:

    protected function schedule(Schedule $schedule)
    {
        // Команда для удаления старых резервных копий.
        // Выполняется каждые 5 минут.
        // Удаляет резервные копии, которые больше не соответствуют
        // параметрам хранения, указанным в конфигурации backup.php.
        $schedule->command('backup:clean')->everyFiveMinutes();

        // Команда для запуска процесса резервного копирования.
        // Выполняется каждые 5 минут.
        // Создает резервные копии базы данных, файлов и другой информации,
        // настроенной в конфигурации backup.php.
        $schedule->command('backup:run')->everyFiveMinutes();

        // Команда для мониторинга состояния резервных копий.
        // Выполняется раз в месяц.
        // Проверяет соответствие резервных копий заданным параметрам (например,
        // максимальный возраст или размер), и уведомляет в случае отклонений.
        $schedule->command('backup:monitor')->monthly();
    }

Для оптимальной настройки планировщика команд в Laravel важно учитывать требования вашего проекта и доступные ресурсы сервера. В большинстве случаев рекомендуется следовать следующим принципам:

• Частота выполнения задач:

Команды для очистки старых резервных копий backup:clean и создания новых резервных копий backup:run следует запускать достаточно часто, чтобы минимизировать потерю данных в случае сбоя. Например, каждые 5–30 минут для активных систем, где данные изменяются часто. Однако, для менее активных систем можно увеличить интервал до одного раза в день.

• Мониторинг состояния резервных копий:

Команда backup:monitor должна выполняться реже, например, раз в неделю или месяц. Ее цель — уведомлять о нарушениях в процессе резервного копирования, например, если резервные копии становятся слишком старыми или не выполняются.

• Баланс нагрузки:

Убедитесь, что команды выполняются в разное время, чтобы избежать одновременной нагрузки на сервер. Например, запуск backup:clean можно выполнить за несколько минут до backup:run, чтобы сначала освободить место для новых резервных копий.

• Планирование в нерабочее время:

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

Запустите планировщик с помощью команды:

php artisan schedule:work

Важность хранения резервных копий вне сервера

Резервные копии всегда должны храниться в месте, независимом от основного сервера приложения. Использование облачных сервисов, таких как Amazon S3, Google Cloud Storage или Timeweb Cloud, позволяет:

1. Обеспечить надежность данных: В случае отказа сервера или утраты доступа к нему вы сможете восстановить данные с резервного носителя.

2. Защититься от атак: Если сервер будет скомпрометирован, данные в облаке останутся в безопасности, поскольку находятся в отдельной инфраструктуре.

3. Обеспечить дублирование хранения: Храните копии не только в облаке, но и локально (например, на внешнем жестком диске), чтобы минимизировать риски.

4. Соблюдение законодательства: В некоторых странах или для определенных проектов (например, медицинских или финансовых) требуется хранение резервных данных в соответствии с нормативными стандартами.

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

Разверните свой Laravel-проект в облаке

Заключение

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

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

Если в будущем потребуется интеграция с другими хранилищами (например, Google Cloud Storage или локальными серверами), вы сможете адаптировать эту систему, используя те же подходы.

Регулярное резервное копирование с мониторингом состояния — это не только защита вашего приложения, но и уверенность в его стабильности и надежности.