В нашем справочнике есть руководство, в котором мы подробно рассматриваем, как создать образ жёсткого диска виртуального сервера, скопировать его на локальную рабочую станцию и там развернуть копию своего VDS. В той статье речь идёт о сервере, работающем под управлением операционной системы Windows Server 2019. Теперь же мы попробуем сделать копию VPS и восстановить её на другой виртуалке. Но в данном случае мы будем работать с Linux-серверами.
Предварительные условия
В рассматриваемом примере мы будем использовать сразу три виртуальных сервера. Средствами операционной системы мы создадим образ VDS, который назовём server1, и восстановим его на другом сервере, который будет называться server2. Размер диска на данных серверах составляет 20Гб, поэтому нам понадобится третья виртуальная машина, которую мы будем использовать в качестве файлового сервера для сохранения образа диска первой виртуалки – server1.img. Для третьего VPS, который мы назовём exchange-server, мы закажем HDD объёмом 50Гб. Это необходимо для того, чтобы на нём поместился двадцатигигабайтный образ сервера server1. С помощью серверного приложения Samba на exchange-server мы создадим общедоступный каталог share_access и подключим его к server1 и server2. В качестве узла доступа к каталогу share_access на server1 и server2 мы будем использовать директорию /mnt.
Настройка файлового сервера
Для начала нужно будет настроить общедоступный ресурс на сервере exchange-server. В качестве операционной системы мы применим для этой виртуальной машины Ubuntu 20.04. Естественно, на данном сервере должна быть произведена предварительная настройка, по крайней мере, в части добавления пользователя, имеющего полномочия администратора, вместо учётной записи root, а также активации и первоначальной настройки брандмауэра UFW.
Чтобы превратить exchange-server в полноценный файловый сервер, необходимо установить на него и настроить серверное приложение Samba в соответствии с посвящённой этому статьей нашего справочника. Чтобы у вас была возможность сохранить образ сервера в расшаренный каталог на exchange-server, воспользуйтесь разделом “Настройка каталога для доступа авторизованного пользователя” в упомянутом уже руководстве. Проверку доступности созданного каталога после его настройки можно осуществить подключившись к нему, например, с локального Windows-компьютера. На скриншоте ниже, 10.10.10.10 – IP-адрес виртуальной машины exchange-server.
Настройка server1 и server2
Сервера server1 и server2 в нашем примере будут работать под управлением операционной системы Debian 12. На этих виртуальных машинах после предварительной настройки необходимо установить пакет инструментов cifs-utils для организации возможности подключения к сетевому диску на exchange-server, а также набор программ net-tools, который может понадобиться для внесения изменений в сетевые настройки.
$ sudo apt update
$ sudo apt install cifs-utils
$ sudo apt install net-toolsПосле этого вы уже сможете подмонтировать организованный на exchange-server общий каталог к директории /mnt. Проделать это нужно как на server1, так и на server2.
$ sudo mount -t cifs //10.10.10.10/share_access /mnt -o user="samba-user"Здесь, 10.10.10.10 – IP-адрес виртуальной машины exchange-server, а samba-user – учётная запись, созданная при настройке общего каталога. Для успешного подключения расшаренного ресурса необходимо будет ввести пароль пользователя samba-user.
Создание образа сервера server1
Перед тем, как начать процедуру восстановления образа, необходимо узнать и сохранить для себя сетевые настройки сервера server2. Данные настройки понадобятся после того, как в результате восстановления образа server2 станет точной копией сервера server1. Чтобы увидеть настройки сетевого подключения, наберите в командной строке server2:
$ ip -c rЗдесь мы видим, что наш server2 имеет сетевой интерфейс eth0, на котором настроен IP-адрес 195.58.52.23 и шлюз по умолчанию 195.58.52.1. А также, запись 195.58.52.0/24 говорит нам о том, что в сетевых настройках установлена маска подсети 255.255.255.0.
На следующем шаге подключитесь к server1. Следующая команда позволяет узнать имя диска, копию которого мы и будем создавать с использованием файлового ресурса exchange-server:
$ sudo fdisk -lВ нашем примере имя диска на сервере server1 – это /dev/sda.
Создание образа раздела /dev/sda мы будем производить используя режим аварийного доступа к серверу. Для чего кликните на изображение экрана сервера server1 в личном кабинете RuVDS. Такое решение не является обязательным к исполнению, вы можете запустить процедуру и из SSH-сессии. Мы же используем аварийную консоль исходя из того, что в процессе создания образа, которое, как правило, занимает довольно продолжительное время, соединение по SSH может быть потеряно по каким-либо причинам. Это не прервёт процесс создания образа, но мы не сможем увидеть его окончание. Несмотря на то, что аварийный режим имеет ограничение своей работы по времени, его можно закрыть, после чего открыть повторно, и при этом ваш консольный сеанс не будет прерван. Таким образом у вас сохранится возможность контролировать состояние процесса.
Для создания копии сервера и последующего восстановления её на другом VPS мы будем использовать утилиту dd. Для запуска процедуры создания образа диска авторизуйтесь на server1 при помощи учётной записи, имеющей полномочия администратора, после чего переключитесь в режим суперпользователя с помощью команды sudo su и наберите следующую команду:
# dd if=/dev/sda of=/mnt/server1.img bs=4M oflag=syncВ данном случае:
/dev/sda– раздел, образ которого мы создаём;/mnt/server1.img– имя файла создаваемого образа (файлserver1.imgв директории/mnt).
Спустя какое-то время процесс создания образа завершится. Об этом будет свидетельствовать появление приглашения для ввода команд в режиме суперпользователя – символа #.
Восстановление созданного образа на server2
Теперь можно переходить к развёртыванию образа сервера server1 на сервере server2. Чтобы не потерять связь с командной строкой и видеть, что происходит в терминале, процедуру восстановления созданной ранее копии на server2 мы также будем производить в консоли аварийного доступа к серверу. Для этого откройте окно аварийной консоли, подключитесь к системе под именем вашей административной учётной записи и затем перейдите в режим суперпользователя с помощью команды sudo su. Запуск процесса восстановления образа на сервере server2 производится командой:
# dd if=/mnt/server1.img of=/dev/sda bs=4M oflag=syncЗдесь:
/mnt/server1.img– имя файла, из которого производится восстановление образа;/dev/sda– раздел, в который данный образ восстанавливается.
Так же, как и при проведении процедуры создания образа, об окончании процесса будет говорить появление символа # в качестве приглашения для ввода дальнейших команд. Чтобы завершить восстановление, закройте окно аварийного режима и перезагрузите виртуальный сервер при помощи соответствующей кнопки в личном кабинете. Гарантированный перезапуск осуществляется путём активации опции Аварийная перезагрузка.
После перезагрузки VPS система может может сообщить нам о наличии ошибок в файловой системе раздела /dev/sda1. При этом, в данном выводе содержится рекомендация запуска проверки файловой системы при помощи команды fsck.
Строка (initramfs) представляет собой приглашение для ввода команд, где нужно будет запустить проверку файловой системы. Соответственно, здесь необходимо ввести команду, которая и запустит данную проверку:
fsck -y /dev/sda1После завершения процедуры проверки нужно закрыть данный режим. Для чего наберите команду:
exitВ результате произведённых действий server2 будет представлять из себя уже не виртуальную машину server2, а точную копию сервера server1. Наряду с этим, поскольку путём восстановления полной копии сервера server1 виртуальная машина server2 теперь содержит все настройки сервера server1, server2 больше не доступен для подключения по SSH, так как настройки сетевого подключения также изменились. Значит, подключиться к server2 теперь можно только через консоль аварийного режима.
Восстановление доступа к server2
Для внесения изменений в сетевые настройки откройте окно аварийного доступа server2 и подключитесь к системе при помощи вашей учётной записи, обладающей полномочиями администратора.
Чтобы убедиться в том, что сетевые настройки на server2 заменены сетевыми настройками сервера server1, вы можете использовать команду:
$ sudo ifconfig
Здесь мы видим, что IP-адрес, настроенный на сетевом интерфейсе eth0 не соответствует IP-адресу, который присутствовал там ранее. Таким образом, необходимо будет удалить данный IP-адрес из сетевых настроек сервера:
$ sudo ip addr del 194.87.213.97/24 dev eth0В данном примере:
194.87.213.97/24– это IP-адрес сервераserver1, указанный с количеством единичных разрядов в маске подсети;eth0– название сетевого интерфейса нашего сервера.
Чтобы восстановить доступ к server2, добавьте в интерфейс eth0 его прежний IP-адрес с маской подсети, а также соответствующий ему шлюз. Это можно сделать при помощи следующих команд:
$ sudo ip addr add 195.58.52.23/24 dev eth0
$ sudo ip route add default via 195.58.52.1Здесь:
195.58.52.23/24– IP-адрес и маска подсети255.255.255.0сервераserver2;195.58.52.1– IP-адрес шлюза для виртуальной машиныserver2.
Для проверки изменений, внесённых в сетевые настройки сервера, можно использовать команду:
$ ip -c rВывод команды говорит нам о том, что сетевые настройки сервера server2, восстановленного из образа сервера server1, в данный момент соответствуют тому, как это было до восстановления.
Таким образом, теперь у нас есть точная копия виртуальной машины server1, доступная по IP-адресу сервера server2. Другими словами, мы имеем два экземпляра server1: один – это непосредственно сервер server1, второй же в настоящее время заменил собой виртуалку server2. При этом оба сервера доступны для подключения по SSH с использованием соответствующих им IP-адресов. Следует иметь ввиду, что изменения, внесённые с настройки сетевого подключения, будут действовать на восстановленной копии сервера до его перезагрузки. После перезапуска server2 доступ к нему по SSH будет потерян.
Заключение
Использовать копию работающего сервера полезно в случаях, когда необходимо попробовать применить какое-либо критически важное изменение настроек, которое может привести к потере работоспособности VPS или приложений, работающих на нём. В данном руководстве мы описали примерный сценарий, позволяющий создать копию виртуальной машины. Во время многочисленных повторений производимых действий мы столкнулись с тем, что не каждая итерация приводит к стопроцентному повторению результата, достигнутому ранее. Тем не менее, описанная последовательность действий является работоспособной и должна помочь в достижении поставленной цели.
