Назад | Перейти на главную страницу

Centos 6 - Резервное копирование и восстановление / восстановление

Я пытаюсь протестировать и задокументировать процедуру резервного копирования и восстановления для Centos 6. Вот, что я задумал, но есть несколько областей, в которых мне нужна небольшая ясность. Документация по резервному копированию / восстановлению CentOS в сети немного удачна.

Общий план резервного копирования и восстановления

/ 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

Проблемы / вопросы

1. Исключая /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 из списка исключений восстановления.

2. Расположение файлов конфигурации сети.

Вы уже исключили /etc/sysconfig/network* при восстановлении из резервной копии; это должно соответствовать как /etc/sysconfig/network файл (глобальная сетевая конфигурация) и /etc/sysconfig/network-scripts каталог (файлы конфигурации для каждого интерфейса ifcfg-*). Однако эти файлы используются только скрипты конфигурации сети в старом стиле включены в initscripts пакет, а CentOS 6 имеет другую систему конфигурации сети - Сетевой менеджер, конфигурация которого хранится в /etc/NetworkManager. Попробуйте также исключить этот каталог при восстановлении резервной копии.

3. Проблема с заменой символических ссылок файлами.

Если вы видите, что символические ссылки были заменены простыми файлами после восстановления, это означает, что либо ваша программа резервного копирования / восстановления была неправильно настроена, либо (если нет возможности для сохранения и восстановления фактических символических ссылок) программа, которую вы использовали, не подходит для резервного копирования / восстановления системы Linux вообще. Вы можете обойтись без программы, которая не поддерживает символические ссылки, только если программа используется для резервного копирования и восстановления только некоторых конкретных данных, которые определенно не будут содержать символических ссылок. Обратите внимание, что вы можете найти символические ссылки там, где вы их не ожидали - например, в некоторых случаях символические ссылки могут использоваться в каталогах базы данных MySQL (для хранения некоторых частей данных на другом устройстве), поэтому полагаясь на предположение «отсутствие символических ссылок» может быть опасно.

4. Резервное копирование MySQL

Если ваша программа резервного копирования просто копирует файлы с работающего сервера, ваша резервная копия на самом деле не является «согласованной при сбоях», потому что разные файлы (и даже разные блоки одного и того же файла) копируются в разное время, поэтому вы фактически не получите согласованный моментальный снимок. базы данных в вашей резервной копии. (Это применимо к любой базе данных, а не только к MySQL.)

Есть несколько способов резервного копирования баз данных MySQL, используя только резервную копию на уровне файлов:

  1. Использовать mysqldump создать дамп SQL перед запуском резервного копирования на уровне файлов; сделайте резервную копию файла дампа вместо каталога базы данных. Это наиболее переносимый формат резервных копий, но и дамп, и восстановление могут выполняться медленно.

  2. Остановите сервер MySQL перед началом резервного копирования, сделайте резервную копию на уровне файлов, затем снова запустите сервер MySQL. Для восстановления просто восстановите все файлы на новом сервере, а затем запустите сервер в обычном режиме. Этот вид резервного копирования выполняется быстро, но требует значительного времени простоя во время резервного копирования.

  3. Чтобы сократить время простоя сервера MySQL, требуемое предыдущим методом, вы можете создать моментальный снимок файловой системы после остановки сервера, затем снова запустить сервер MySQL, а затем смонтировать моментальный снимок, выполнить резервное копирование на уровне файлов и удалить моментальный снимок. У вас должна быть файловая система на томе LVM с некоторым свободным пространством в группе томов для моментального снимка.

  4. Чтобы еще больше сократить время простоя, вы можете использовать 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 без какой-либо панели управления.

Созданная мной процедура приведена ниже:

  • Установите Centos 6.X Minimal на целевой сервер
  • Установите Virtualmin из install.sh
  • Выйдите из целевого сервера, но оставьте его включенным
  • Восстановить резервную копию сервера с помощью rsync с сервера резервного копирования
  • Перезагрузите целевой сервер
  • Войти в Virtualmin
  • Исправьте IP-адреса с помощью инструмента Virtualmin (он уже спросит)
  • Правильное имя хоста
  • Восстановление резервных копий виртуального сервера (сайта) с сервера резервного копирования (если вы используете виртуальные серверы и имеете там какие-либо учетные записи)
  • Удалите php_value, php_admin_value из httpd.conf, если virtualmin добавил их
  • Выполните проверку конфигурации Virtualmin с помощью инструмента Virtualmin

Если вы не используете 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/