Можно ли перенести старый линукс с разделами LVM с хоста на виртуалку без перезагрузки и выключения хоста?

Я исправил это генерацией initrd-ядра в загрузчике

WAT?

Я сделал копирование диска dd на живую с хоста на другой диск.

Не надо наживую. С livecd/liveusb

Или через специальные инструменты вроде vmware converter

Время от времени базы данных выдают ошибки.

Что, и базы копировал наживую?

Извиняюсь за неточность. Пришлось сгенерировать новый файл ядра initrd в /boot

Ошибка была такой

Mounting root filesystem.
mount: could not find filesystem '/dev/root'
Setting up other filesystems.
Setting up new root fs
setuproot: moving /dev failed: No such file or directory
no fstab.sys, mounting internal defaults
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
switchroot: mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!

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

Просто сервер постоянно в работе и не хотелось бы сильно даунтаймить ..

Просто сервер постоянно в работе и не хотелось бы сильно даунтаймить ..

А перенести мусор вместо консистентной базы хочется?

нормальное решение.

нанять сисадмина

нанять сисадмина

Мы не можем себе позволить такую роскошь!

Тоже не хочется. Неужели придётся выбирать из зол меньшее?

не можем себе позволить

тогда нужно решить сначала эту проблему

Тебе надо заморозить диски. Чтобы скинулись все кеши и не писались после этого никакие данные. Вот в таком состоянии и можно через dd копировать диски. По крайней мере они будут хоть как-то консистентны. lvm fsfreeze вроде что-то из этого рода. Сам я так не делал, поэтому не факт, что всё будет адекватно. Ошибки при загрузке всё равно будут, т.к. это не полноценное отмонтирование, но это хотя бы что-то.

Основная проблема, когда ты просто копируешь наживую в том, что на дисках появятся данные «из будущего». Файловые системы и базы устойчивы к потере питания, но при этом подразумевается, что на диске записаны данные не поздней какого-то момента, более ранние данные могут быть записаны, могут быть не записаны, что через fsync синхронизировалось - тоже долно быть записано. Но на твой юз-кейс код никто не расчитывал и не мог расчитывать, когда ранние секторы в диске будут иметь ранние данные, а поздние секторы - поздние данные.

Именно для этого и нужна заморозка диска - чтобы, начиная с какого-то момента, никакие записи на него не проходили.

Возможно тебе могут помочь lvm snapshots, если ты заставишь их работать. Тогда, вероятно, это можно будет сделать вообще без прерывания работы.

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

Спасибо за подробный ответ

Вариант 1.
1. Создаем диск виртуалки.
2. Разбиваем, создаем fs на диске VM полностью аналогично живому.
3. На живой создаем снапшот
4. Копируем (dd) снапшот на vm
5. Грузим VM с бутового носителя и устанавливаем загрузчик.

Вариант 2.
1. Создаем диск виртуалки.
2. Разбиваем, создаем fs на диске VM полностью аналогично живому.
3. Монтируем в отдельный каталог разделы VM.
4. rsync с живого на VM.
5. Если работает что-то, что меняет критичные данные, например субд, блокируем доступ к субд для всего (если вам VM на поиграться, то можно и не блокировать), бэкапим родными средствами и копируем бэкапы на диск VM.
6. Грузим VM с бутового носителя и устанавливаем загрузчик.
7. Загружаемся и если есть бэкапы из пункта 4, разворачиваем их.
profit.

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

Пункты можно видоизменять, в зависимости от...

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

Что может быть проще - создать виртуалку, настроить сервис, перенести данные сервиса с хостовой машины на виртуалку. Давно бы уже закончили переезд.

Второй вариант прямо очень плохой. Не надо так. Данные точно будут неконсистентны. Потом это где-нибудь боком вылезет. А у современных баз данных, даже если к ним нет доступа снаружи, очень много процессов происходит внутри и ты так можешь побить в ней данные.

Не совсем понял. Хочу уточнить пару вопросов.

3. Монтируем в отдельный каталог разделы VM.

отдельный каталог это /mnt?

4. rsync с живого на VM.

Это rsync всего диска в виртуалку? Почему он перед «блокируем доступ к субд для всего» ?

6. Грузим VM с бутового носителя и устанавливаем загрузчик.

Но ведь пункт 2/3 «создание и монтирование fs» делается уже загрузившись в загрузачный образ. Это делается там же или я что-то неправильно понял?

бэкапим родными средствами

Что значит родными средствами? Это lvm snapshots?

Принимается. Исправление для пункта 5
«например субд, блокируем доступ к субд для всего, рестартуем субд».

отдельный каталог это /mnt?

Например он.

Это rsync всего диска в виртуалку? Почему он перед «блокируем доступ к субд для всего» ?

Потому что копирование всего займет какое-то время и в это время субд вполне может продолжать работать. Или говоря другими словами «чтобы сократить downtime».

Но ведь пункт 2/3 «создание и монтирование fs» делается уже загрузившись в загрузачный образ. Это делается там же или я что-то неправильно понял?

Ещё раз перечитайте:
1. Создаем диск виртуалки.
2. Разбиваем, создаем fs на диске VM полностью аналогично живому.
3. Монтируем в отдельный каталог разделы VM.

про загрузку нет не слова, она появляется только в пункте:
7. Загружаемся и если есть бэкапы из пункта 4, разворачиваем их.

Что значит родными средствами? Это lvm snapshots?

Родные средства это например для муски mysqldump

Лучше остановить ее все-таки

А бэкап как делать будем?

Со слейва чаще всего. И смотря какая база. Обычно у них у всех имеются утилиты для бэкапирования на лету в целостном состоянии на определенный момент времени. xtrabackup от percona для mysql баз, pg_basebackup для postgres.

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

Родные средства это например для муски mysqldump

mysqldump не является утилитой для бэкапа. Он не обеспечивает тебе консистентность данных на момент времени (point-in-time)

Со слейва чаще всего.

Я намекал на то, что на остановленном сервере бэкап родными средствами сделать не получится.

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

Можно, но расписывать это ТС не было никакого желания, ибо в зависимости от сервера субд и вариантов сборок этого сервера, указать точно какие директории надо скопировать, невозможно.
Как пример, у меня крутится firebird, я знаю в какой директории лежат базы, но сторонний человек вынужден будет искать. Ладно, рабочие базы fb можно хоть по владельцу найти, а если это interbase то будет однозначно сложнее.
PS Но вариант бэкап/рестор тоже может оказаться сложным :) Я как-то столкнулся со случаем когда у двух таблиц были foreign key друг на друга.

mysqldump не является утилитой для бэкапа.

офф. документация с вами не согласна.

Making Backups with mysqldump

The mysqldump program can make backups. It can back up all kinds of tables. (See Section 7.4, “Using mysqldump for Backups”.)

For InnoDB tables, it is possible to perform an online backup that takes no locks on tables using the --single-transaction option to mysqldump. See Section 7.3.1, “Establishing a Backup Policy”.

Надо ещё уточнить что то, что нужно автору - это не бекап, а всё-таки работающий снапшот. К нему требования выше. Бекап это аварийная копия, которая в 99.99% случаев окажется не нужна, и он вполне может быть не совсем консистентным, если это упрощает его снятие и не сильно задерживает починку (приведение к рабочему состоянию) и развёртывание в тех редких случаях когда он всё-таки окажется нужен.

Бекап это аварийная копия, которая в 99.99% случаев окажется не нужна,

Бэкап БД, и не только БД, бывает востребован не только в случае аварии. Это я про случаи «Пользователь сам накосячил, сознался, надо наковырять тот вариант который был до того как пользак накосячил».
Два случая этого года:
1. Месяц назад. СУБД - накосячили с данными, поднимал из бэкапа и правил на основе этой копии данные в рабочей БД.
2. Февраль. Пользователь «попортил» данные в файле excel, он думал что работает с другим похожим по данным, тоже самое, находим в бэкапе копию за нужную дату, восстанавливаем.

и он вполне может быть не совсем консистентным

Не консистентый бэкап? Вы конечно шутите мистер firkax.

в лвм атомарные снапшоты. зачем наживую копировать?!

//тред не читал

Твоё «правил данные в рабочей БД на основе бекапа» скорее вполне прокатило бы и с неконсистетным. Потому как нужно было не полное состояние за старую дату, а обрывочные данные оттуда.

И вообще я затрудняюсь сходу представить ситуацию, когда тот факт, что данные из бекапа устаревшие, не страшен, а вот неконсистентность фатальна и неисправима. Хотя наверно такие ситуации бывают, но они довольно редки. Может, какие-то замкнутые финансовые системы (потому что в незамкнутых устаревшая копия автоматически оказывается неконсистентной к окружающему миру).

я rsync’ом делал бекапы живой системы, и они работали

скорее вполне прокатило бы и с неконсистетным.

Неконсистентность в БД это в первую очередь ошибка проектирования самой БД.

И вообще я затрудняюсь сходу представить ситуацию, когда тот факт, что данные из бекапа устаревшие, не страшен,

Вы внимательно прочитали то, что я написал? «и правил на основе этой копии данные в рабочей БД», я знал какие записи нужно исправить.

а вот неконсистентность фатальна и неисправима.

Спасибо КЭП.

А теперь прочти ещё раз моё сообщение (с учётом предыдущей беседы), ты его понял в полностью перевранном виде.

я rsync’ом делал бекапы живой системы, и они работали

Живая система, живой системе рознь, если у вас нет критически важных изменяемых данных, то почему бы и нет? Я например тоже бэкапы полной системы, после внесения серьезных изменений делаю на живой, только перед началом останавливаю все то, что может писать на диск. В принципе можно и не парится с остановкой, т.к. нужные данные и так бэкапятся ежедневно, но мне так спокойнее.

базы были и им по боку. но да так делать нельзя. я обычно бекапы из снапшотов делаю

Извините.

базы были и им по боку

Повезло... просто повезло, что в это время ничего не писалось в них.

Только даунтайм и dd. Без вариантов.

Что может быть проще - создать виртуалку, настроить сервис, перенести данные сервиса с хостовой машины на виртуалку.

Админ локалхоста? Такое возможно в простых случаях. Когда детально известна работа всех установленных приложений, сохранились дистрибутивы, лицензии

Холодная миграция (в выключенном состоянии) на порядок проще

Бекап это аварийная копия, которая в 99.99% случаев окажется не нужна

В такой формулировке нельзя не добавить - «но она обязана быть»

ТС наживую копировал файлы БД. Какие снапшоты lvm, ты о чем? Успешный перенос с даунтаймом уже будет шагом вперед

Админ локалхоста?

Так скажем, админством не зарабатываю, так что скорее да чем нет.

Холодная миграция (в выключенном состоянии) на порядок проще

Мы как раз эту простоту в треде и наблюдаем или ещё проще будет?

Подробно писать лень, поэтому тезисно:

1. Создаем ФАЙЛ с вирт. диском на сетевой шаре (NFS)
2. Заводим этот вирт. диск в систему через losetup
3. Разбиваем на разделы /boot, ?EFI? и раздел для PV
4. Добавляем PV в LVM
5. Миррорим все LV (ждем окончания синхронизации)
6. Выключаем систему (на минутку), чтобы привести все фс в консистентное состояние
7. Вирт. диск забираем в виртуалку
8. Включаем старую систему, избавляемся от зеркала
9. Вкл. виртуалку

Выключаем систему (на минутку), чтобы привести все фс в консистентное состояние

Это-то зачем? Выполнить sync и этого будет достаточно.

Ну да, но я про то что логика такая: с вероятностью 0.01% всё потерять мы не хотим, однако потерять с этой вероятностью например сутки (на починку неконсистентного бекапа до консистентного вида) вполне допустимо, если мы взамен получим например отсутствие гарантированных ежедневных лагов прода на время снятия заранее консистентного бекапа. Если мы можем снять идеальный консистентный бекап и при этом не лагать прод - это конечно лучше всего, но не везде возможно.

В смысле? Если ты останавливаешь базу данных и копируешь все файлы системы, то ты скопируешь и файлы db. Исключение только oracle, который умеет сам под себя размечать раздел на диске.

Я как-то столкнулся со случаем когда у двух таблиц были foreign key друг на друга.

И? Какую проблему это создало?

Насколько я помню, mysqldump не умеет блочить всю базу, а только таблицу. Но даже если умеет, то восстановление из бэкапа, представляющего собой последовательность insert’ов для базы всего-лишь на терабайт займет целый рабочий день.

Неконсистентность в БД это в первую очередь ошибка проектирования самой БД.

Есть только единственный способ спроектировать db которая всегда консистентентна - это одна таблица в базе с кучей колонок. Во всех остальных случаях ты получаешь ссылки на несуществующие данные. И это практически всегда очень плохо.

Умеет. Опция --single-transaction.

Но даже если умеет, то восстановление из бэкапа, представляющего собой последовательность insert’ов для базы всего-лишь на терабайт займет целый рабочий день.

Проводили тест? Но ещё раз повторюсь, я написал про родные средства только по причине:
«Можно, но расписывать это ТС не было никакого желания, ибо в зависимости от сервера субд и вариантов сборок этого сервера, указать точно какие директории надо скопировать, невозможно. »
Раз уж вы стали приводить примеры, могу другой вариант дать. Была у вас БД на 2ТБ, потом её почистили и сейчас данных в ней на 100Мб, трансфернуть и развернуть бэкап на 100Мб будет всяк быстрее чем 2Тб трансферить.

В смысле? Если ты останавливаешь базу данных и копируешь все файлы системы, то ты скопируешь и файлы db.

Да, всё верно, такой вариант вполне годится. Я разделил изменяемые данные и не изменяемые на две части только для того что бы сократить время простоя. Сначала все готовим, копируем не изменяемые и останавливаем сервер только на время трансфера изменяемых данных.

Я как-то столкнулся со случаем когда у двух таблиц были foreign key друг на друга.

И? Какую проблему это создало?

Этап восстановления данных. В таблицу T1 нельзя добавить запись потому, что таблица T2 ещё пустая и наоборот.

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

Ну не только оракл так умеет, но этот вариант рассматривается отдельно.

Есть только единственный способ спроектировать db которая всегда консистентентна - это одна таблица в базе с кучей колонок. Во всех остальных случаях ты получаешь ссылки на несуществующие данные. И это практически всегда очень плохо.

Что за бред мы прочитали? T1( id_t2 foreign key(id) references T2 (id)) теперь попробуйте добавить что-то в t1 со ссылкой на несуществующее в t2.