Бэкап Linux и восстановление его на другом железе

Я работаю в организации с маленьким штатом, деятельность тесно связана с IT и у нас возникают задачи по системному администрированию. Мне это интересно и частенько я беру на себя решение некоторых.

На прошлой неделе мы настраивали FreePBX под debian 7.8, нанимали фрилансера. В процессе настройки оказалось, что сервер (да, я так называю обычный PC) не хочет грузится с HDD при подключенных USB 3G модемах, которые мы используем для звонков на мобильные, колупание BIOSа не помогло. Непорядок. Решил, что нужно перенести его на другую железяку. Так появилось сразу две связанные задачи:

  • сделать бэкап сервера;
  • восстановить бэкап на другом железе.

Гугление не дало внятных ответов, как это сделать, пришлось собирать информацию кусками и пробовать. Всякие acronis’ы отбросил сразу, ибо не интересно.

Опыт общения с linux-системами у меня небольшой: настройка VPN сервера на open-vpn, ftp-сервера и еще пара мелочей. Сам себя я характеризую как человека умеющего читать маны и править конфиги :)

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

Начинаем копать теорию:

По созданию бэкапов уйма статей, я для себя отметил два способа: tar — упаковывает и сжимает все файлы, при этом не сохраняется MBR, мой бэкап будет весить около 1.5 Gb; dd — делает полную копию раздела, включая MBR и всю область, где нет файлов, архив будет равен размеру раздела, в моем случае ~490 Gb.

Второй способ требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем. Да и что с ним потом делать, непонятно, хранить на полочке? Остановился на tar, чуть сложнее в реализации, нужно будет создать MBR, но время создания/восстановления архива существенно меньше, хранить бэкап проще, полтора гига можно закинуть в облако и скачать, когда будет нужно. Записывать его можно на ту же live-флэшку, с которой буду грузиться.

Итак, план действия:

  1. создание бэкапа;
  2. форматирование, разметка диска, создание файловой системы;
  3. восстановление бэкапа;
  4. создание MBR;
  5. тестирование и устранение неполадок.

1. Создание бэкапа


Грузимся с live-флэшки, у меня это debian-live-7.8.0-amd64-standard.

Переключаемся на root:

sudo su

Монтируем раздел, который будем архивировать, у меня это sda1, чтобы случайно не наломать дров, монтируем только для чтения. Посмотреть все свои разделы можно при помощи команд ls /dev | grep sd или df -l

mount -o ro /dev/sda1 /mnt 

Наша флэшка уже примонтирована, но в режиме только чтения, нужно перемонтировать для чтения-записи, чтобы писать туда бэкап.

mount -o remount,rw /dev/sdb1 /lib/live/mount/medium

Все готово для создания архива

tar -cvzpf /lib/live/mount/medium/backupYYYYMMDD.tgz --exclude=/mnt/var/spool/asterisk/monitor --exclude=/mnt/var/spool/asterisk/backup /mnt/

Здесь у нас параметры: c — создать архив, v — выводить информацию о процессе, z — использовать сжатие gzip, p — сохраняем данные о владельцах и правах доступа, f — пишем архив в файл, путь к файлу, --exclude — исключаем из архива каталог (я исключил каталоги с записями разговоров и каталог с бэкапами FreePBX), /mnt/ — каталог, который архивируем.

Ждем… у меня вся подготовка и создание архива заняли 10 минут. Будь флэшка быстрее, уложился бы в 7-8 минут.

Отмонтируем диск:

umount /mnt

… и перезагружаемся.

reboot

Складываем архив в надежное место за пределами офиса.

Восстановление бэкапа на другом железе


2. Размечаем диск, создаем файловую систему

Грузимся с live-флэшки, у меня все та же debian-live-7.8.0.

Переключаемся на root:

sudo su

Размечаем диск. Мне понравилась утилита с псевдографическим интерфейсом cfdisk. Там все просто и понятно.

cfdisk

Удаляем все имеющиеся разделы. Я создал два новых раздела, один на 490 Gb под / (sda1) и 10 Gb под swap (sda2) в конце диска, т.к. он практически не будет задействован. Проверим типы разделов. Который под систему должен иметь тип 83 Linux, второй — 82 Linux swap / Solaris. Помечаем системный раздел загрузочным (bootable), сохраняем изменения и выходим.

Cоздаем файловую систему на первом разделе.

mkfs.ext4 /dev/sda1

3. Распаковываем архив.

Монтируем отформатированный раздел

mount /dev/sda1 /mnt

Распаковываем архив прямо с флэшки

tar --same-owner -xvpf /lib/live/mount/medium/backupYYYYMMDD.tgz -C /mnt/

Параметр --same-owner — сохраняет владельцев у распаковываемых файлов, x — извлекаем из архива, v — выводить информацию о процессе, p — сохраняем права доступа, f — указываем файл, который распаковываем, C — распаковываем в категорию.

4. Создаем MBR на новом диске.

Чтобы корректно создать загрузочную запись, монтируем рабочие каталоги к нашему будущему root-каталогу, у меня это /mnt. Каталоги /dev и /proc сейчас используются live-системой, используем параметр bind, чтобы они были доступны сразу в двух местах:

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc

Переключаемся на новую систему используя chroot:

chroot /mnt

Делаем swap-раздел для новой системы:

mkswap /dev/sda2 

Подключаем его же:

swapon /dev/sda2

Чтобы grub работал, нужно указать ему правильные UUID разделов в fstab, сейчас там прописаны разделы предыдущей системы:

nano /etc/fstab

Открываем второй терминал (Alt+F2) под root:

sudo su

Вызываем:

blkid

И видим текущие UUID разделов.

Вручную переписываем их в fstab переключаясь между Alt+F1 и Alt+F2. Да, муторно, но попытки копировать занимали у меня больше времени, чем переписывание. Сохраняем fstab.

Устанавливаем grub2. У меня один физический диск, поэтому ставим его на sda:

grub-install /dev/sda

На чистый диск должно встать без ошибок. Обновляем информацию из fstab:

update-grub

Возвращаемся в Live-систему:

exit

Размонтируем все каталоги:

umount /mnt/dev
umount /mnt/proc
umount /mnt

Если вылазят процессы, которые используют эти каталоги, убиваем их используя fuser.

Все, поехали. Грузимся с жесткого диска:

reboot

Здесь статья должна была закончиться, но у меня возникли проблемы с подключением к интернету. Сервер видит сеть, видит компьютеры в ней, но в интернет не ходит… а это как бы важно для телефонии.

5. Тестирование и устранение неполадок.

ifconfig -a

Показывет интерфейсы eth1 и lo, гугление сказало, что gateway можно прописать только подключению eth0, остальные рассчитаны только на работу внутри сети.

Похоже, отсутствие eth0 вызвано способом переноса системы. Находим файл, который отвечает за нумерацию интерфейсов, смотрим туда:

nano /etc/udev/rules.d/70-persistent-net.rules

Действительно, там два активных интерфейса, определенных MAC’ами. Комментируем первый, второму прописываем eth0.

Перезапуск /etс/init.d/networking не помог, поэтому перезагружаемся:

reboot

Подключаем донглы, проверяем, все работает.
Спасибо за внимание.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 23

    +3
    Читать маны в интернете полезно, один раз собрать gentoo из stage1 — бесценно.
      0
      не хочет грузится с HDD при подключенных USB 3G модемах

      Cам когда-то ковырял Huawei'ный свисток E1550 и точно помню, что у него есть встроенная память память, на которой лежит софт + autorun.inf (домохозяйка edition)

      Так вот, если у Вас подобная ситуация, то отключив этот раздел, возможно, решите проблему.

      З.Ы.: в /etc/fstab монтируемые разделы прописаны UUID'ами или как "/dev/sdX" (ну мало-ли...)?
        0
        В моем случае проблема была именно в USB или BIOS (не стал разбираться), т.к. даже при подключенной флэшке он не грузился с диска.

        ЗЫ. По идее можно задать и в формате "/dev/sdX", но учитывая, что у меня подключено еще уйма устройств, не стал такого делать UUID надежнее.
          0
          По идее можно задать и в формате "/dev/sdX"

          Вы немного не поняли / я неточно выразился: я говорил про необходимость прописывать UUID'ами, а раз а вас именно так и прописано, то проблема не в этом.
        +5
        хабр уже не торт.
          +3
          Второй способ требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем. Да и что с ним потом делать, непонятно, хранить на полочке?

          читать тогда уж маны внимательней. Потом из образа накатывать на новый сервер. А вообще лучше использовать LVM. А может вообще ещё проще «старый» диск поставить в новый сервер? Там вообще возможно ничего не придётся перенастраивать.
            0
            Старый винт поставить в новую железяку — вариант, но т.к. была вторая задача, сделать бэкап и иметь возможность оперативно развернуть его на новом железе (используются обычные PC и вероятность отказа достаточно высока), я решил их совместить.
              +2
              Тогда уж лучше dd использовать. И загрузочный сектор сохраниться. И гемора меньше чем с tar (ИМХО). Ну и LVM соответственно, что бы можно было расширить разделы до размеров нового диска.
              Да и как правильно ниже написал товарищ ntfs1984 либо напишите скрипт для развёртывания, либо используйте системы управления конфигурациями (puppet, ansible, chef).
          • UFO just landed and posted this here
              0
              Я с вами абсолютно согласен по поводу раздела в 490 Гб, но т.к. все уже было настроено и запущено, времени переделывать не было.
              • UFO just landed and posted this here
              +6
              Вручную переписываем их в fstab переключаясь между Alt+F1 и Alt+F2. Да, муторно, но попытки копировать занимали у меня больше времени, чем переписывание.

              так жалко вас стало, попробуйте хотя бы так:
              # blkid /dev/sda1 | cut -f 2 -d '"' >> /etc/fstab
                0
                ну как бы ещё есть терминальные мультиплексоры. Я пользуюсь tmux — две панели вывел на экран и перепечатывай без шаманских действий с функциональными клавишами если не догадался по другому получить uuid.
                +1
                А отчего изначально не поднимали сервер в виртуальной машине? Это ж радикальное решение проблем с бэкапом и переносом на другое железо.
                • UFO just landed and posted this here
                    –1
                    Бэкап-ресторе для переезда на другое железо это виндовый подход, винда по другому не умеет.
                    В линухе/фре всё проще — можно подключить диск, разметить его, создать фс, смонтировать и скопировать туда все файлы.

                    Это проще, по-вашему? А по-моему, проще склонировать диск через любой аналог Акрониса, и в 90% случаев в венде все заработает само.
                    • UFO just landed and posted this here
                    0
                    Прочитал и поностальгировал…
                    Года 4 назад я переносил OpenBSD на новый винт похожим способом…
                      0
                      Извините, а Вы не пробовали для dd сделать такое (жмём вывод dd):
                      sudo dd if=/dev/sdXY bs=1M conv=noerror | gzip -c > /mnt/backup/root.dd.gz
                      

                      Одной строчкой Ваша фраза про «требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем»
                      нивелируется=) На практике итоговый размер не превышал реально занятого в ФС.

                      Лично я не раз так перезаливал готовую систему на абсолютно разные по железу платформы (в рамках одной архитектуры, разумеется).
                      А вопрос размера итогового раздела решается просто — никогда не монтируйте  /  на весь диск, создайте себе привычку для основных  (хотя бы /, /boot и /home) разделов использовать разные точки монтирования.

                      Согласен — для серьёзных бекапов dd — слишком уж решение в лоб, зато даёт точную копию диска, это важно в случае глобальной настройки grub, да и нельзя же его просто так вот отмести по надуманной причине.
                        0
                        а как же www.fsarchiver.org?

                      Only users with full accounts can post comments. Log in, please.