У меня есть автономная система IDS linux, которую я собирал. Он запускает MySQL локально, а также ntop, nagios, base, snort, apache и т. Д. Я хочу иметь возможность сделать резервную копию системы, в которой есть все из старой системы, чтобы я мог быстро выполнить dd из статического образа систему, а затем восстановить ее до последнего состояния.
Насколько мне известно, я не могу выполнить DD для живой системы, что оставляет меня в недоумении относительно того, как получить все с сервера для резервного копирования.
Раньше я никогда не использовал rsync, и я думаю, что это может быть решение, но я не уверен, что смогу использовать его в живой базе данных mysql.
Я почти уверен, что здесь потребуется многоуровневый подход, но любой ввод будет полезен.
редактировать:
Контролируемые системы большую часть времени имеют низкий трафик, а apache предназначен только для веб-интерфейсов приложений, поэтому он не так перегружен, как может показаться.
В вашей ситуации я вижу два варианта:
Вы можете использовать rsync в живой БД, но вы можете получить повреждение данных. Остановите db, запустите rsync и снова запустите. Вы также можете сделать дамп БД и rsync этого файла.
Знаете, я ДЕЙСТВИТЕЛЬНО большой поклонник выключения сервера и использования чего-то вроде Clonezilla или Norton Ghost для создания образа этого лоха.
Даже если это 11 вечера в пятницу вечером, раз в месяц ... вы поняли.
Пара часов «запланированного простоя» стоит ЧАСЫ и ЧАСЫ восстановления после сбоя.
Как я говорю своему помощнику: «Я говорю это не потому, что я умен. Я говорю это потому, что в какой-то момент я БЫЛ глупым и усвоил урок ТЯЖЕЛО!
Спасибо за ваше обновление. Хорошо, у этого сервера нет простоев.
Можно ли создать «теплый резерв», который можно использовать в течение 2–3 часов, которые потребуются для клонирования диска?
Можно ли отключить сеть в 3 часа ночи воскресным утром?
Конечно, должен быть какой-то способ запланировать какое-то время простоя?
Я просто пытаюсь предложить вам "простое" решение. :-)
Для mysql вы можете использовать mysqldump чтобы выгрузить содержимое базы данных в файл. В остальном вам обычно требуется только резервное копирование файлов конфигурации (/etc и любые другие каталоги, которые вы изменили), любые другие каталоги данных, файлы журналов и список установленных пакетов. Вы сможете восстановить систему, выполнив новую установку ОС, установив пакеты из списка и заменив файлы данных и конфигурации.
Я действительно большой поклонник использования грязный для резервных копий. По сути, это просто сценарий Perl, который упрощает создание резервных копий с помощью rsync.
Для базы данных mysql вам действительно нужно использовать утилиту mysqldump или что-то специально разработанное для этой цели. Копирование файлов базы данных с помощью rsync - не лучшая идея.
Обычно можно просто выполнить синхронизацию содержимого файловой системы в другое место и все. Инкрементное резервное копирование должно быть довольно быстрым (несколько минут? В зависимости от пропускной способности, доступной для rsync и от того, как часто вы выполняете резервное копирование), поэтому вы можете даже отключить проблемные службы на время почти без каких-либо последствий (я заметил «отсутствие простоев» требование).
Обычным нарушителем этой практики является база данных MySQL, которая плохо обрабатывает моментальные снимки. Вы можете решить эту проблему, воспользовавшись предложением Камила сделать дамп в файл SQL и создать его резервную копию, или выполнив своего рода «горячее резервное копирование». Преимущество последнего подхода заключается в том, что он намного больше нравится rsync - создание нового дампа SQL для каждой резервной копии приводит к тому, что rsync каждый раз копирует всю базу данных, что является длительным процессом для больших баз данных. Используя «горячее резервное копирование», вы можете воспользоваться возможностью rsync копировать только изменения в данных. Innobase (создатели InnoDB) продают коммерческий продукт для горячего резервного копирования всей базы данных. Я обнаружил, что до тех пор, пока у вас мало записей в БД, вы можете обойтись LOCK TABLES, rsync двоичные файлы и UNLOCK TABLES. когда вы восстанавливаете MySQL, думает, что у вас произошел сбой сервера, и восстанавливается нормально (вы действительно хотите запустить mysqlcheck после восстановления).
Другой метод резервного копирования вашего сервера, немного похожий на первое предложение Дейва, - это резервное копирование устройства рейда. Это совсем другой подход, чем мой первый ответ, поэтому я помещаю его в другой ответ.
Что вы можете сделать, так это настроить свой сервер с помощью программного рейда (mdraid) с зеркалированием. Затем, когда вы хотите сделать снимок, отключите одно устройство рейда (mdadm /dev/md0 --fail /dev/sdb1 --remove /dev/sdb1), dd содержимое отключенного устройства сервера и повторно подключите его к рейду (mdadm --re-add /dev/sdb1). Синхронизация рейда скопирует все данные, которые были изменены, когда устройство было выключено.
При восстановлении можно dd одинаковые данные для обоих рейдовых устройств (в любом случае это зеркало). В худшем случае восстановленный образ будет выглядеть так, как будто сервер потерял питание во время транзакции, поэтому вам в любом случае следует использовать журналируемую файловую систему и транзакционные базы данных.
В таком случае вы, вероятно, захотите использовать систему с 3 дисками, чтобы ваша система могла справиться с аварией во время резервного копирования, и в этом случае вам нужно либо иметь 3-стороннее зеркало и отключить 3-е устройство для резервного копирования, либо даже установите его в отсеке горячего выключателя и просто снимите его физически, как описано в эта тема (пожалуйста, прочтите ветку, если вы хотите сделать это таким образом - исходный плакат имеет некоторые проблемы с конкретными командами и их порядком)
я использую
Цитата
rsync --delete --times --recursive --perms --owner --group --verbose --progress --stats -e ssh root@192.168.0.100: / backup1 / / backup1 /
Цитата
на 2-м сервере на этом сервере у меня есть конфигурация lvm, поэтому очень легко запустить резервное копирование, просто сделав снимок, вы можете перейти по ссылке
Взгляните на backupEdge на сайте www.microlite.com
(Жаль, что у них нет версии для Windows)
Клонирование не является жизнеспособной схемой резервного копирования для производственной системы.
Поищите книгу Кертиса Престона "Резервное копирование и восстановление Unix". Резервное копирование действующей системы возможно с помощью множества коммерческих приложений, а также приложений с открытым исходным кодом, таких как Amanda. Тем не менее, придется учиться.
Обычно наиболее сложным аспектом резервного копирования является восстановление. Сначала начните планирование восстановления. Если вы не можете позволить себе отключить систему для резервного копирования, вы не сможете позволить себе ее восстановление.