Я пытаюсь протестировать и задокументировать процедуру резервного копирования и восстановления для Centos 6. Вот, что я задумал, но есть несколько областей, в которых мне нужна небольшая ясность. Документация по резервному копированию / восстановлению CentOS в сети немного удачна.
Выполняйте резервное копирование систем каждый день с помощью любимого программного обеспечения для резервного копирования. Я не собираюсь вдаваться в подробности, но предположим, что у вас есть надлежащая система резервного копирования, которая позволяет вам делать резервную копию одной системы и восстанавливать ее на другой.
Дым и пламя охватили один из ваших серверов! После того, как вы столкнулись с непосредственной опасностью, вы понимаете, что важная система непоправимо повреждена. Вам нужно восстановить его на другое оборудование.
Проверьте файлы резервных копий. Взгляните на резервную копию неисправной системы. /etc/redhat-release
файл. Используйте это, чтобы установить, какую версию (уровень исправления) CentOS использовала неисправная система? Возьмите установочный носитель для этой версии.
Используя установочный носитель, выполните минимальную установку операционной системы на заменяемое оборудование, разбив диски на разделы в соответствии с конечным использованием системы.
После установки минимальной системы временно отключите selinux, echo ‘0’> /selinux/enforce
остановить iptables, service iptables stop
и установите клиент резервного копирования.
Восстановить из резервной копии, без учета следующие файлы из recovery:
/ proc
/ sys
/ tmp
/ dev
/ var / lock<- не исключать из восстановления - см. ответ
/ var / run<- не исключать из восстановления - см. ответ
/ var / tmp
/ etc / fstab
/etc/mdadm.conf
/ etc / mtab
/etc/resolv.conf
/ и т.д. / сети
/ и т.д. / sysconfig / сеть *
/ и т.д. / sysconfig / ядро
/ etc / hosts
/ и т.д. / modprobe *
/ etc / networkmanager <- чтобы не восстановить IP - см. ответ
/ etc / udev
/ lib / модули
/ boot
Когда восстановление будет завершено, перезагрузитесь и следите за ошибками
Проверьте правильность конфигурации сети. Возможно, вам придется использовать system-config-network
чтобы внести изменения в настройки вашей сети.
Некоторые приложения, такие как Apache и MySQL, могут некорректно запускаться после восстановления. Так как Это не должно быть проблемой, если вы не исключите / var / run и / var / lock из восстановления - см. Ответ./var/run
был исключен из восстановления, вложенные папки вроде /var/run/httpd
не будет существовать, и поэтому приложения не смогут правильно создавать файлы PID. Вам нужно восстановить папки типа /var/run/httpd/
и /var/run/mysqld/
и дайте им правильные разрешения.
После выполнения корректирующих действий убедитесь, что приложения появляются правильно.
Если вы используете базу данных MySQL, она все еще может быть в порядке, без необходимости восстанавливать ее из любой резервной копии плоского файла, которую вы, возможно, сделали. Вы можете проверить состояние базы данных, запустив mysqlcheck -c -u root –p******** --all-databases
. Если вы видите какие-либо ошибки, запустите mysqlcheck -c -u root –p******** --all-databases --auto-repair
отремонтировать их. Вы всегда должны убедиться, что у вас есть надлежащая резервная копия вашей базы данных, как указано в ответе ниже. Я лично использую mysqldump.
Обновите систему до последнего уровня, используя yum update
.
После перезагрузки, чтобы убедиться, что система вернется в исходное состояние, четко и тщательно проверив / var / log / messages на наличие ошибок, проверьте функциональность системы, чтобы убедиться, что она работает правильно. В этом случае используйте system-config-network
для изменения IP-адреса на IP-адрес исходной неисправной системы.
Без учета /var/run/*
из восстановления приводит к тому, что подпапки, используемые для хранения идентификаторов PID для некоторых приложений, не создаются при восстановлении. Неужели нужно исключать /var/run/*
от восстановления? Это лучший способ просто не восстанавливать файлы PID?
Когда система была восстановлена, IP-адрес «неисправной системы» также был восстановлен. Я этого не хотел. Я, должно быть, пропустил файл из моего списка «исключить из восстановления». Есть идеи, где это?
При обновлении я получаю много сообщений вроде /sbin/ldconfig: /usr/lib64/libblah.so is not a symbolic link
. Когда я перезагружаю систему после обновления, некоторые службы работают некорректно. Интересно, связано ли это с системой резервного копирования, восстанавливающей файлы, на которые указывают символические ссылки, вместо самих символических ссылок. Если я запустил ldconfig и посмотрю на один из общих объектов, на который он жалуется, общий объект будет фактическим файлом, а не символической ссылкой. Кто-нибудь еще видел это?
/var/run
Как вы уже заметили, исключая /var/run
во время полного восстановления системы CentOS 6 вызывает проблемы, поскольку также исключает каталоги, созданные установленными пакетами. Без учета /var/lock
также могут вызывать аналогичные проблемы, потому что некоторые пакеты также создают там подкаталоги.
(В более свежих дистрибутивах Linux, использующих systemd
- на таких раздачах /var/lock
и /var/run
(действительно /run
) может быть размещен на tmpfs
, и все необходимые подкаталоги создаются при каждой загрузке; однако CentOS 6 намного старше и не поддерживает автоматическое создание подкаталогов в /var/lock
или /var/run
.)
Однако фактически исключая /var/run
и /var/lock
не требуется для правильного восстановления, потому что /etc/rc.d/rc.sysinit
скрипт на CentOS 6 включает следующую команду:
find /var/lock /var/run ! -type d -exec rm -f {} \;
Эта команда удалит все устаревшие файлы блокировки или pid (или любые другие файлы, не относящиеся к каталогам, такие как сокеты и символические ссылки) во время загрузки системы. Поэтому вам следует удалить /var/lock
и /var/run
из списка исключений восстановления.
Вы уже исключили /etc/sysconfig/network*
при восстановлении из резервной копии; это должно соответствовать как /etc/sysconfig/network
файл (глобальная сетевая конфигурация) и /etc/sysconfig/network-scripts
каталог (файлы конфигурации для каждого интерфейса ifcfg-*
). Однако эти файлы используются только скрипты конфигурации сети в старом стиле включены в initscripts
пакет, а CentOS 6 имеет другую систему конфигурации сети - Сетевой менеджер, конфигурация которого хранится в /etc/NetworkManager
. Попробуйте также исключить этот каталог при восстановлении резервной копии.
Если вы видите, что символические ссылки были заменены простыми файлами после восстановления, это означает, что либо ваша программа резервного копирования / восстановления была неправильно настроена, либо (если нет возможности для сохранения и восстановления фактических символических ссылок) программа, которую вы использовали, не подходит для резервного копирования / восстановления системы Linux вообще. Вы можете обойтись без программы, которая не поддерживает символические ссылки, только если программа используется для резервного копирования и восстановления только некоторых конкретных данных, которые определенно не будут содержать символических ссылок. Обратите внимание, что вы можете найти символические ссылки там, где вы их не ожидали - например, в некоторых случаях символические ссылки могут использоваться в каталогах базы данных MySQL (для хранения некоторых частей данных на другом устройстве), поэтому полагаясь на предположение «отсутствие символических ссылок» может быть опасно.
Если ваша программа резервного копирования просто копирует файлы с работающего сервера, ваша резервная копия на самом деле не является «согласованной при сбоях», потому что разные файлы (и даже разные блоки одного и того же файла) копируются в разное время, поэтому вы фактически не получите согласованный моментальный снимок. базы данных в вашей резервной копии. (Это применимо к любой базе данных, а не только к MySQL.)
Есть несколько способов резервного копирования баз данных MySQL, используя только резервную копию на уровне файлов:
Использовать mysqldump
создать дамп SQL перед запуском резервного копирования на уровне файлов; сделайте резервную копию файла дампа вместо каталога базы данных. Это наиболее переносимый формат резервных копий, но и дамп, и восстановление могут выполняться медленно.
Остановите сервер MySQL перед началом резервного копирования, сделайте резервную копию на уровне файлов, затем снова запустите сервер MySQL. Для восстановления просто восстановите все файлы на новом сервере, а затем запустите сервер в обычном режиме. Этот вид резервного копирования выполняется быстро, но требует значительного времени простоя во время резервного копирования.
Чтобы сократить время простоя сервера MySQL, требуемое предыдущим методом, вы можете создать моментальный снимок файловой системы после остановки сервера, затем снова запустить сервер MySQL, а затем смонтировать моментальный снимок, выполнить резервное копирование на уровне файлов и удалить моментальный снимок. У вас должна быть файловая система на томе LVM с некоторым свободным пространством в группе томов для моментального снимка.
Чтобы еще больше сократить время простоя, вы можете использовать FLUSH TABLES WITH READ LOCK
перед созданием снимка вместо остановки сервера, как описано Вот; в этом случае моментальный снимок будет содержать таблицы MyISAM в согласованном состоянии и таблицы InnoDB в согласованном состоянии (после восстановления на уровне файлов потребуется восстановление InnoDB).
Читать эта документация для получения дополнительной информации о резервном копировании MySQL.
Есть отличный проект с открытым исходным кодом ReaR (Relax and Recover), который сделал потрясающие вещи в области создания резервных копий Linux в стиле образа (включая CentOS и Red Hat). Особо следует отметить классный способ, которым они фиксируют структуру файловой системы и встраивают ее в свой диск восстановления, чтобы восстановление структуры файловой системы работало достаточно хорошо. Лучше всего то, что он написан на bash (и действительно хорошо написан на bash!).
У нас нет связи с проектом, кроме того, что мы написали краткое руководство http://carroll.net/blog/red-hat-bare-metal-backup.
Объединив список исключений в этом потоке вопросов и одно руководство по Rackspace, я смог надежно настроить приведенную ниже конфигурацию для репликации / копирования всего установленного сервера CentOS.
Моя установка - CentOS 6.7 + Virtualmin. Однако это могло бы работать с CentOS 6.X без какой-либо панели управления.
Созданная мной процедура приведена ниже:
Если вы не используете Virtualmin, вам, возможно, придется не включать элементы Virtualmin.
Список исключаемых файлов для копирования на удаленный сервер приведен ниже:
/boot
/proc
/sys
/tmp
/dev
/var/tmp
/etc/fstab
/etc/mdadm.conf
/etc/mtab
/etc/resolv.conf
/etc/networks
/etc/sysconfig/network*
/etc/sysconfig/kernel
/etc/hosts
/etc/modprobe*
/etc/networkmanager
/etc/udev
/lib/modules
/var/lock
/etc/conf.d/net
/etc/network/interfaces
/etc/sysconfig/hwconf
/etc/sysconfig/ip6tables-config
/etc/hostname
/etc/HOSTNAME
/etc/modules
/net
/etc/rc.conf
/usr/share/nova-agent*
/usr/sbin/nova-agent*
/etc/init.d/nova-agent*
Кредиты:
https://support.rackspace.com/how-to/migrating-a-linux-server-from-the-command-line-2/