На самом деле я не системный администратор, я в основном разработчик с некоторыми знаниями Unix, и, поскольку у нас нет компетентного системного администратора, мне делегировали задачу по реализации стратегии резервного копирования.
У нас много веб-серверов, на одних работает Mysql Srevers, на других - apache, на третьем - nginx, и мы используем SVN в качестве системы управления версиями.
Мы с нетерпением ждали реализации стратегии резервного копирования и возможности автоматического восстановления сервера.
У нас есть 2 возможности:
С нашей точки зрения, преимущество первого метода состоит в том, что он очень прост в реализации, а недостатком - в использовании большого количества ресурсов сервера (ЦП / ОЗУ / пропускная способность).
Поскольку мы не хотели, чтобы наши серверы отставали из-за запущенного сценария резервного копирования, мы решили углубиться в (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 не подвержены процессу резервного копирования. Затем для каждого основного сервера мне просто нужно сохранить эту информацию в файле conf /etc/backup/mysql.info serverID = ID
Чтобы восстановить базу данных, мне просто нужно получить этот serverID из файла conf, а затем выполнить синхронизацию соответствующего образа дампа с сервера резервного копирования на восстановленный сервер.
3 - Список пакетов
С помощью debian легко узнать полный список пакетов, установленных в системе. Cron просто сохранит этот список в /etc/backup/package.list
4 - Пользовательские приложения
Иногда нам нужно установить пакеты вручную (perl, компиляция и т. Д.). Я думал о создании папки / etc / backup / manual /, содержащей все сценарии автоматической установки, а затем при восстановлении запуск каждого сценария в этой папке должен сделать трюк
5 - Файлы конфигурации
Файл /etc/backup/conf_data.list со списком всех каталогов конфигурации (например, / etc) можно проанализировать с помощью задания cron, а затем синхронизировать на сервере резервного копирования.
При восстановлении нам нужно сначала восстановить /etc/apt/sources.list, выполнив шаги - и 4, а затем выполнить синхронизацию сохраненных файлов конфигурации обратно на сервер.
Не могли бы вы сообщить мне, что вы думаете об этой концепции. Вы уже реализовали что-то подобное? Вы столкнулись с проблемами?
Возможно, вы захотите добавить в свою схему регулярный запуск aptitude-create-state-bundle для полного восстановления системы. Видеть http://man.he.net/man1/aptitude-create-state-bundle.
Я думаю, что вы придумали неплохой план, однако выше есть 2 ошибки. rSync выполняет резервное копирование только изменений, а не всего диска, и rsync должен получать файлы конфигурации, если они меняются, независимо от того, если вы настроили его правильно.
Я считаю, что вам нужно начать с твердой оценки того, во что обойдется потеря этих данных, и решить, стоит ли менять потерю, исходя из ваших знаний. Если стоимость выше, чем ваша зона комфорта, вам нужно получить консультацию или нанять другую компанию для реализации надежной стратегии. Без обид, но если есть значительный риск, не стоит оставлять сумку в руках, когда колеса соскочат с вагона. Я видел, как люди теряли работу из-за подобных вещей. Они хотят сделать все возможное, но, когда что-то идет не так, они не справляются. Иногда нужно просто знать, когда откланяться. Вы все еще можете вносить свой вклад, но не брать на себя вину, если это не удается.
Просто нью-йорк. 02