Как создать и перенести (клонировать) резервную копию системного накопителя linux с одного VDS на другой?

Приветствую всех.
На сервере системном разделе диска расположен интернет магазин Битрикс с большой посещаемостью. Встал вопрос о резервном клонировании системного накопителя linux с одного VDS на другой и последующим обновлением системы на сервере доноре (php, mysql, веб-окружение Битрикс). Сервер используем от компании TimeWeb, у которой нет функций клонирования VDS, загрузки системы с live CD, загрузки резервной копии накопителя.
Как лучше и с минимальным простоем для сайта создать и перенести (клонировать) резервную копию системного накопителя linux с одного VDS на другой?
  • Вопрос задан
  • 868 просмотров
Пригласить эксперта
Ответы на вопрос 7
opium
@opium
Просто люблю качественно работать
Слава богу это Линукс и можно просто рсинк без системных файлов и все будет точь в точь
Ответ написан
Комментировать
CityCat4
@CityCat4
Внимание! Изменился адрес почты!
dump/restore
топорный способ - tar всего на свете от корня. Тупо, прожорливо, много лишнего, но уж точно ничего не упустишь...
Ответ написан
Sanes
@Sanes
Проще и дешевле обратиться в поддержку TimeWeb.
Правда можно напороться на типичную для крупных компаний неповоротливость. Бюрократия, регламент и т.д.
Ответ написан
babarun
@babarun Куратор тега 1С-Битрикс
Безумный план моих идей в руках больных людей
https://toster.ru/answer?answer_id=426823
Продублирую,
Чтобы выбрать верную стратегию миграции сайта на другой сервер, прежде всего нужно определиться - допускается ли отлючение операций записи/обновления в БД на время переноса ресурса, т.е. фактический простой? Предположим что мы начали перенос нагруженного интернет-магазина, где каждые три минуты происходит заказ. Если тупо снять дамп БД, сделать архив файлов, перегнать на другой сервак, развернуть всё это дело, то лаг по времени будет минимум минут 30, даже при условии что новая железка будет находиться в той же стойке. Пока будет происходить перенос, в старую базу уже буду записаны новый заказы. Как вариант можно на время миграции запретить создание заказов и пользователей, но простой в 30 минут (а реально 2 часа) бизнес не устраивает, поэтому на крупных проектах практикуется бесшовный переезд - сначала устанавливается балансировщик, на него переписывается DNS, а он в свою очередь проксирует трафик на старый сервер, далее поднимается второй сервак, на нём разворачивается БД, которая подлючается к БД на старом сервере как slave, скрипты синхронизируются rsync/csync, файлы выносятся в облако. В итоге получаем классическую master-slave модель. В завершении меняем роли в БД, новую делаем мастером, а старую слейвом. Тушим старый сервер.
Ответ написан
t_q_l
@t_q_l
Интересная личность
@lycifep Автор вопроса
В общем 2 варианта:
1. Арендуем резервный VDS. Бэкапим tarом диск, по ssh переносим на новый сервер, восстанавливаем. Домен настраиваем на новый сервер. Когда переезд состоится синхронизируем БД через SQLyog. Простой сайта около 30 мин. На старом сервере все обновляем, тестируем. Повторяем переезд. Затраты: аренда нового сервера + дополнительные диски (на месяц). Риск минимален
2. Бэкапим средствами хостинга диск. Накатываем обновления, тестируем. При появлении критичных проблем откатываемся. Простой при проблемах больше чем в 1 варианте и риск больше

Вскоре напишу что из этого вышло...
Ответ написан
Комментировать
Добрый день.
Ранее, чтобы перенести всё содержимое сервера, мы выполняли операцию клонирования таким образом:
1) Монтируем в пу резервную копию.
2) Далее нужно создать VDS с таким же размером диска (или больше), как на передающем сервере (в нашем случае соразмерно резервной копии).
3) Загрузить принимающий сервер с Livecd. На передающем можно выполнять команды напрямую в ОС.
В режиме livecd на принимающем сервере выполнить:

nc -l -v -p 39999 | pv --size 35g > /dev/vda

# 35g — размер диска на передающем сервере
(pv нужен, чтобы вывести прогресс-бар)

5) На передающем сервере выполнить:
cat /dev/vda | nc timeweb_ip 39999

вместо timeweb_ip должен быть ip-адрес принимающего сервера
вместо /dev/vda путь до блочного устройства (примонтированная рез.копия)

По сути эти команды берут все содержимое жесткого диска одного сервера и записывают его на другой сервер.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы