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