клонирование физического сервера на горячую - что-то типа standby

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

DRBD

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

без остановки боевых серверов.

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

Создание архива системы Linux c помощью cоздание Squashfs образа

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

sudo mksquashfs / /root-backup.sqsh -e root-backup.sqsh home media dev run mnt proc sys tmp –создание Squashfs образа

sudo mount /root-backup.sqsh /mnt/ -t squashfs -o loop –примонтировать Squashfs образ

…ext4 устарел заранее прошу не начинать.

Ну, для клонирования на уровне ФС выбор явно не верный.

Какого-то универсального способа нет и у всего есть свои особенности и недостатки, поэтому всё зависит от твоих потребностей. Какую-нибудь файлопомойку часто можно и rsync-ом синхронизировать, бд репликацией, обновления ОС лучше просто параллельно делать и т.п.

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

Чтобы работа сервиса не прерывалась при аппаратных проблемах, необходима соответствующая архитектура.

Привет, про проект знаю давно, но не вижу что бы его использовали: если будет желание и время посмотреть сообщи. https://github.com/ClusterLabs/hawk

DRDB -> HeartBeat -> Corosync/Pacemaker -> maybe Hawk?

В любом случае, вопрос будет в сторону арбитража и stonith, где HA не тоже самое, что HL

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

Если от клона нужна работа одновременно с оригиналом — то же самое + изменение hostname и /etc/machine-id .

Если используется lvm, то скорее всего можно сделать snapshot. Превратить в виртуальный volume и примонтировать. А дальше rsync’ом перенести все данные с него на другой сервер.

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

в свое время был любопытный эксперимент по этому поводу.
На старом сервере все кроватки под диски - были заняты, USB был старый и медленный, поэтому был выбран вариант синхронизации по iSCSI.

Создается iSCSI target из диска(ов) на новом сервере. Полученные iSCSI диски подключаешь на старом сервере. Из старых и новых делаешь программный raid1(зеркало). Ждешь окончания синхронизации raid. А уже после снова ждешь момента «Ж» - и выключаешь старый сервер а новый сервер запускаешь с новыми дисками но уже с развалившимся raid, который спокойно разруливаешь.
Под программным raid использовалась LVM, но ничто не мешает обычный MDADM .

Эксперимент был признан вполне удачным, особенно когда объемы дисков большие.

1. rsync / rsyncd — будет работать на текущей системе.

2. ZFS / zrepl — если делать заново асинхронную реплику с инкрементом без головной боли.

Всё остальное добавит больше проблем.

С базами данных такое точно случится.

Ну это слишком грубо, с современными базами такого не должно случится, даже с sqlite. Произойдет откат до последнего чекпоинта.

Можно рассматривать снапшоты, как потерю питания. И потеря питания не должна приводить к неконсистентности данных.

LVM snapshot + rsync

Ох, господи, стандартная задача, с таким же стандартным решением - кластер proxmox + linstor(DRDB). А в комментах как обычно.

По деталям: zfs не советую - на вашем месте лучше lvm/lvm-thin, будет проще. Сеть отдельную организовать обязательно, либо основную сделать 10G и быстрее, а в идеале отдельную 10G+. Надо понимать ваши задачи,обязательно тестовый стенд собрать и проверить на нем, что бы понимать, не упираетесь ли вы в сеть.

Репликация будет в реальном времени, узла нужно минимум 3, но один из них может быть маломощным, нагрузку и зрвнилище на себя он брать не будет, в случае экономии, с 2-мя узлами, часто 3-й узел делают на proxmox backup server.

Да, жить все переедет в vm, так что вашу centos 7 можно не трогать. Потери не такие значительные, но зависит от сценария и настроек (очень).

Еще можно упростить схему, убрав realtime репликацию, испольюзуя zfs и встпоенную репликацию по расписанию. Выключать vm при этом не нужно.

Как-то так.

Centos 7 - ей 10 лет

Не могу утверждать, но по моему во времена CentOS 7 - ZFS ещё была совсем не готова.
Посему все предлагающие zfs - отвечают не по существу.

Как по мне, самое правильное клонировать не диск, а сервисы. Например, если БД Postgres, то pg_dump или поднять реплику. У Minio добавить второй сервер в кластер. И так далее.

Во-первых, будет трафик меньше, во-вторых, будет выполняться вся логика сервисов про транзакции и т. д. Многие сервисы используют низкоуровневый доступ к ФС, ручные кеши и неизвестно как они себя поведут при зеркалировании всей ФС.

А не данные клонировать вообще не надо. Лучше иметь скрипт развёртывания, ставящий все пакеты и запускающий все сервисы на чистой ОС (и периодически его проверять на работоспособность, особенно после изменений конфигурации или мажорных обновлений).

Смешались Бэкапы, кластеры HighA и скейфолд (кому «нравится», DevOps оркестрация)… еще средств доставки (intelfx, придерживаюсь твоего мнения о Docker) Docker-like ждём в треде

Посмотри вот это - https://www.redhat.com/en/blog/rear-backup-and-recover

Здесь смысл в том, что снапшот - это все равно что питание рубануть.

И не должна БД превращатся в тыкву после внештатного отключения питания. Ни современная БД, ни БД 20-летней джавности =)

А значит, и восстановление из снапшота БД должна пережить, просто при старте накатит redo/WAL/transaction/whatever-логи.

Ладно. Убедил. Если нет данных в разных базах, которые по разному восстанавливаются, то да. Переживет. Мне просто сама практика такого претит.

Btw: Тут чувак на форуме был, который рассказывал как перенести mysql не останавливая. Он просто rsync-ком копировал файлы, не останавливая и не лоча таблицы. У меня тогда знатно пригорело.

И не должна БД превращатся в тыкву после внештатного отключения питания.

Именно БД ещё как превращается. Вот субд бывает что позволяют принудительно записывать на диск изменения в независимости от кэша, но и это не всегда спасает.

Btw: Тут чувак на форуме был, который рассказывал как перенести mysql не останавливая. Он просто rsync-ком копировал файлы, не останавливая и не лоча таблицы. У меня тогда знатно пригорело.

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

почитал тему. поржал.

ТС, начать надо с ответ ана вопрос - у вас что там работает, на этой самой CentOS7 ? какое прикладное ПО? как установлена и настроена система? ext4 - это ни о чём не говорит.

ибо standby для Оракла - это совсем не одно и тоже что для Postgres. кстати, у СУБД обычно есть штатные варианты как standby сделать.

поэтому я бы начал просто с переноса образа уже работающей системы. если / у вас отдельно от данных, на относительно небольшом разделе, то с помощью live-cd/usb загрузил ЛЮБОЙ подходящий дистр на целевом сервере, с помощью него скопировал бы разбивку; потом залил бы базовую систему (без базы данных), по dump"|ssg restore xf; потом grub-install если там использовался GRUB2; потом пробно бы загрузился бы в single level (там надо выбирать загрузку не по умолчанию в GRUB menu), проверил бы что всё соотвествует, потом стал бы думать как сделать репликацию уже самих рабочих данных. а это уже очень сильно зависит где, что и как.

не должна БД превращатся в тыкву после внештатного отключения питания.

Ага, а также БД не должна биться. Еще внештатное отключение питания не должно портить ФС. Когда подобная фигня случится, нужно грозно читать мораль всем этим сущностям не менее 15 минут, тыкая пальцем в монитор)