Продвинутые стратегии резервного копирования

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

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

В нашем документе «Стратегии резервного копирования» мы привели пример процесса резервного копирования с помощью mysqldump.

Mysqldump — это встроенное приложение, которое поставляется с вашим пакетом MySQL-сервера. Оно позволяет выгружать данные из выбранных баз данных в файлы SQL, CSV или XML. Это даёт возможность редактировать данные перед восстановлением. Однако, поскольку по сути создаётся текстовая копия, на серверах с высокой нагрузкой создание и восстановление резервной копии из неё могут занять значительное время.

Это означает, что время восстановления увеличивается, а мы хотим сохранить его как можно более коротким.

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

Резервное копирование исходных файлов

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

Наш предпочтительный метод — xtrabackup от Percona.

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

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

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

Примерное сравнение времени полного резервного копирования базы объёмом 2 ТБ — mysqldump: более 12 часов, xtrabackup: 5,5 часов

Репликация

Резервное копирование необходимо. Однако на базе данных с высокой нагрузкой даже ежедневные бэкапы не дают полной защиты. В этом случае худший сценарий потери данных — 24 часа. Это гораздо лучше, чем потерять всё, но всё ещё значительный объём данных.

Здесь полезна настройка сервера репликации.

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

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

Резервное копирование приложения

Вся телематическая информация хранится в базе данных и постоянно обновляется. Между тем файлы приложения Navixy (backend, frontend и их конфигурации) со временем остаются статичными — изменяются только логи. Поэтому вы можете просто сохранить файлы платформы на отдельном сервере и держать там копию платформы в резерве.

Таким образом, если с вашим основным сервером произойдёт какая‑то авария, вы можете переключить IP‑адрес на резервный сервер, запустить платформу там, и она продолжит работу. Этот простой метод позволит быстро восстановить доступ к платформе с минимальными простоями.

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

Комбинированный метод

Оба метода резервного копирования баз данных отлично работают по отдельности. Их одновременное использование может дать максимальную защиту. Ниже представлена упрощённая схема резервного копирования для достижения приемлемой отказоустойчивости, а также приёмы восстановления в случае проблем.

Руководства по методам резервного копирования баз данных доступны в сети. Чтобы максимально повысить надёжность бэкапов, рекомендуется иметь в команде специалиста DevOps/DBA.

Если вам нужна помощь нашей службы поддержки, свяжитесь с нами по адресу [email protected]