Что вы думаете об этой стратегии резервного копирования Debian?

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

У нас много веб-серверов, некоторые из них работают на Mysql Srevers, другие apache, на другом работает nginx, и мы используем SVN в качестве системы управления версиями.

Мы с нетерпением ожидали реализации стратегии резервного копирования и возможности автоматического восстановления сервера.

У нас есть 2 варианта:

1. RSYNC весь диск каждый день
2. Проанализируйте нашу конфигурацию и нормализуйте каждый шаг установки, сделайте резервную копию только этой информации и используйте репликацию MySQL, SVN для восстановления данных и rsync для резервного копирования только параметров конфигурации и списка пакетов.

На наш взгляд, преимущество первого метода состоит в том, что он очень прост в реализации и имеет недостаток в использовании большого количества ресурсов сервера (ЦП / ОЗУ / пропускная способность).

Поскольку мы не хотели, чтобы наши серверы зависали из-за запуска скрипта резервного копирования, мы решили углубиться в (2).

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

1 - Данные веб-сервера

SVN может обрабатывать все наши файлы php/css/js/html, нам просто нужен файл конфигурации, в котором хранится информация о папках и репозиториях. Например: в файле /etc/backup/svn_folders.list я бы

FOLDERNAME1    SVN Repository Address1
FOLDERNAME2    SVN Repository Address2
etc...

Тогда в случае сбоя нам просто нужно проанализировать этот файл и проверить SVN.

2 - резервное копирование данных MySQL с репликацией

У нас есть 3 основных сервера mysql, которые я реализовал на резервном сервере mysql_multi, причем 3 экземпляра mysql выполняются одновременно, каждый из которых является частью основных серверов. Затем каждый день я

Stop slaves
mysqldump
start slave

Таким образом, я уверен, что наши основные серверы MySQL не будут затронуты процессом резервного копирования. Тогда для каждого основного сервера, мне просто нужно сохранить эту информацию в файле конфигурации /etc/backup/mysql.info serverID = ID

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

3 - Список пакетов

С помощью debian легко узнать полный список пакетов, установленных в системе. Хрон просто запишет этот список в /etc/backup/package.list

4 - Пользовательские приложения

Иногда нам нужно устанавливать пакеты вручную (perl, compilation и т. Д.). Я думал о создании папки /etc/backup/manual/, содержащей все сценарии автоматической установки, а затем при восстановлении запуск каждого сценария в этой папке должен сделать трюк

5 - Конфигурационные файлы

Файл /etc/backup/conf_data.list со списком всех каталогов конфигурации (например, /etc) может быть проанализирован с помощью cronjob, а затем rsynced на сервере резервного копирования.

При восстановлении нам нужно сначала восстановить /etc/apt/sources.list, выполняя шаг - и 4, а затем rsync сохранить сохраненные файлы конфигурации обратно на сервер.

Пожалуйста, дайте мне знать, что вы думаете об этой концепции. Вы уже реализовали что-то подобное? Вы столкнулись с проблемами?