В настоящее время у нас есть приложение, работающее на выделенном сервере, которое использует стек LEMP (Linux, Nginx, MariaDB, PHP). Сейчас мы делаем резервные копии только с заданным интервалом (каждые x часов). Я исследовал, как мы должны делать живую резервную копию, и мне было любопытно, что делают другие люди?
В настоящее время наша идея состоит в том, чтобы иметь еще один сервер в другом географическом месте, на котором установлен mariadb, а затем синхронизировать базы данных, создавая живую копию нашей производственной базы данных только для чтения на этом резервном сервере. Для файлов, загруженных пользователями, мы должны настроить rsync для синхронизации с сервером резервного копирования при внесении изменений в каталог загрузок на производственном сервере. Это звучит как надежный план?
Кроме того, нам пришла в голову мысль, что, если мы собираемся платить за дополнительный выделенный сервер, мы должны запускать приложение с обоих серверов, настраивая DNS для циклического перебора между ними. Это не только обеспечит нам резервную копию, но и обеспечит отказоустойчивость в случае выхода из строя одного из серверов.
Мы на правильном пути или упустили какой-то жизненно важный элемент?
Вы решаете проблему избыточности. Это хорошо. Вы можете переключиться на резервный сервер в экстренной ситуации. Это НЕ РЕЗЕРВНАЯ решение. Вы хотите, чтобы ваши резервные копии, особенно для веб-приложения, возвращались в прошлое.
Если разработчик приходит и запускает DROP TABLE myApp_users, это изменение будет распространено на ваш сервер резервного копирования, доступный только для чтения, и у вас не будет возможности восстановить данные. У вас должна быть возможность вернуться на разумное время.
Если кто-то найдет способ обновить ваш логотип или загруженный пользователем файл на главном сервере, изменение будет распространено на резервный сервер через rsync.
Вам нужно сбрасывать базу данных через определенные промежутки времени, и через определенные промежутки времени копировать файлы куда-нибудь и сохранять x данных по времени, чтобы называть это резервное копирование.
Эта стратегия резервного копирования кажется хорошей. Вероятно, есть способы улучшить это, но это улучшит вашу текущую ситуацию. Вам по-прежнему нужны резервные копии, чтобы предотвратить повреждение базы данных, атаки и т. Д.
Циклический перебор с базовым DNS, вероятно, не лучшая идея. Некоторые клиенты всегда будут использовать первую запись, некоторые не будут переключаться при отказе. Использование чего-то более умного, например AWS Маршрут53 или CloudFlare которые могут выполнять проверки работоспособности и отключать трафик на неотвечающий сервер, будут работать лучше.