LINUX.ORG.RU
Форум — Admin  

Полная и удобная синхронизация двух компьютеров

 , , , ,


1

6

Привет всем!

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

На данный момент стоит Ubuntu 21.10 с KDE, обновление до 22.04 планируется. В обоих компьютерах стоят SSD, размеры которых одинаковые до байта. Накопители имеют GPT таблицу разделов и два раздела: ESP на гибибайт и LVM PE на всё остальное. Внутри LVM: /, /home и swap. Файловые системы везде ext4. Шифрования на уровне блочного устройства или самих ext4 не применяется.

Первую синхронизацию я сделал просто через DD, физически переставив один накопитель в другой компьютер. Естественно, дальше это было неприменимо. Поэтому я написал скрипт, который с использованием ключей SSH делает синхронизацию с помощью rsync. А кроме этого предварительно применяет нужные настройки, поднимает нужные сервисы (сеть, SSH). Запускаю я его из rescue режима, чтобы система в это время ничего не делала. В принципе rescue вполне достаточно, только лишь systemd успевает накидать несколько каких-то незначительных файлов. journald при этом остановлен. Хотя, конечно, загрузка с отдельного носителя или какой-то специальный initramfs подошли бы больше. Но, в общем, работает в обе стороны. Однако недостаточно быстро.

А недавно возникла необходимость изменить логические тома на LVM. И после такого изменения один rsync уже не поможет, т.к. размеры томов изменились. Мало того, что изменения размеров томов так не синхронизируются (естественно), так и на одном места для данных не хватит теперь. Конечно, можно синхронизировать опять через dd, но разбирать не хочется, а через сеть медленно. Да и перезаписывать накопитель целиком ещё раз тоже идея так себе. Можно и руками изменить размеры на целевой системе, но муторно. Надо будет сначала удалить ненужные файлы, чтобы освободилось место, потом поменять размеры, потом синхронизировать. А если понадобиться изменить размеры ещё раз, то опять? Морока...

И я подумал, нет ли какого-то решения, чтобы синхронизировать два PV или VG, но только те экстенты, что изменились? Погуглил, но ничего не нашёл. Не знаю, хранят ли экстенты время последнего изменения, чтобы это было в принципе возможно. Хотя тут хватило бы даже не времени, а просто некоторого идентификатора компьютера. Например, когда ОС записывает что-то, то в метаданных экстента записывается хеш от названия материнской платы или т.п. Но это я уже фантазирую. Так существует ли что-то подобное? Может быть как некое дополнение к обычному LVM?

Если ничего такого нет, что тогда? Я нагуглил штуку под названием Distributed Replicated Block Device. Но пока не разобрался по поводу загрузки с неё. Кроме того, она должна же быть под LVM, т.е. это надо всё переустановить. Точнее, скопировать куда-то, потом переразбить носитель и скопировать всё обратно.

Какие есть другие варианты, если без переделывания всего не получится обойтись? У меня такие мысли:
* Один LV просто на весь объём накопителя, тогда не надо будет менять его размер. Но мне это решение не очень нравится, т.к. я хотел завести себе LXC контейнеры и под них создавать отдельные LV. Кроме того, деление на LV и для бекапов полезно. Да, бекапы у меня отдельно, это не на другой компьютер.
* Какие-то иные файловые системы, вроде ZFS и BTRFS могут мне что-то предложить? Думаю, что subvolume (или что-то такое) вполне заменят отдельные LV как для LXC, так и для бекапов. Правда у меня память что там, что там без ECC. А она вроде как очень рекомендована для таких файловых систем.

Кто что думает?

P.S.: Написал в администрирование т.к. думаю, что вопрос больше подходит сюда, т.к. выходит за рамки повседневного использования, хоть это и для личных нужд и «администрирую» я локальные свои системы.

★★★★★

Последнее исправление: ls-h (всего исправлений: 2)

Разделы и файловые системы… В большинстве случаев ты не можешь просто взять и всё переразметить из работающей системы ничего не останавливая, а остановив, систему можно считать не работающей (полноценно).

Раз уж ты меня скастовал тегом ZFS, то я буду рассказывать про ZFS…

Думаю, что subvolume (или что-то такое) вполне заменят отдельные LV.

  1. Не имеет совершенно никакого смысла делать более одного пула (раздела на диске), если диски не будут регулярно мигрировать между машинами:
    • Нужно больше пространства — RAID-0;
    • Нужен запас отказоустойчивости — RAID-1;
    • Ну и помимо 1, 0, 10 ещё есть альтернатива 5 и 6, которые также могут быть 50 и 60 (про уровни RAID сам загуглишь, если не в теме).
  2. Все возможные юзкейсы решаются созданием датасета (логического подраздела внутри пула) и изменением его настроек на лету (некоторые крутилки доступны только при создании, но их и крутить регулярно не имеет смысла):
    • Нужно ограничить пространство — есть quota;
    • Нужно скормить виртуалке блочное устройство — создаёшь raw zvol…

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

Совершенно не обязательно. У меня на десктопе ZFS крутится уже очень давно (даже миграцию Linux→FreeBSD пережила, но потом всё было переразмечено из-за изменения дисковой конфигурации), естественно ни о каком ECC речи не идёт, но проблем из-за памяти не было ни разу, а аптайм у меня обычно очень большой. И из-за внезапной потери питания тоже проблем никогда не было (актуально для ноутов). Да, ECC лишним не будет, и не только для ZFS, а вообще для любого софта, работающего сутками.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Раз уж ты меня скастовал тегом ZFS

Это всё занятно. А как синхронизировать то, если это возможно? Чтобы гонять только изменения.

и всё переразметить из работающей системы ничего не останавливая

В один момент времени полноценно работающая только одна.

ls-h ★★★★★
() автор топика

Помню раньше энтузиасты занимались чем-то подобным, только там идея была держать систему в ОЗУ, а перед выключением записывать изменения на диск (и диск сберегает и работает быстрее).

Exmor_RS ★★★
()
Ответ на: комментарий от theurs

а какое rsync-у дело до разных размеров томов?

Вот именно, что никакого. Поэтому сначала надо будет на целевой системе изменить размеры томов, чтобы места хватило.

ls-h ★★★★★
() автор топика
Ответ на: комментарий от ls-h

А как синхронизировать то, если это возможно? Чтобы гонять только изменения. 

zfs send

умеет в инкрементальные изменения:

You can send incremental data by using the zfs send -i option.
Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от ls-h

Факт загруженности с устройства не имеет значения, загрузитесь с tmpfs поверх примонтируете через overlayfs. А блочность и не нужна, файловости достаточно.

Shushundr ★★★
()
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от ls-h

Это всё занятно. А как синхронизировать то, если это возможно? Чтобы гонять только изменения.

zfs send/recv. Перегонит всё, что ты скажешь перегнать, можно целиком пул гонять туда-обратно (оно работает на уровне датасетов, но корень пула — тоже датасет). Единственное, что нужно будет шатать лапками — PMBR/UEFI, но это можно обновлять кроном при загрузке.

mord0d ★★★★★
()

DRBD вряд ли под твоё описание подходит. Только там наоборот. На низком уровне drbd, а поверх него lvm. Когда я с ним работал, у меня были два сервера, система на каждом из них ставилась на обычный раздел, остальные диски в сервере отдавали под кправление drbd, который уде предоставлял обычные блочные устройства, который можно использовать как угодно. В моём случае - lvm. Синхронизация полная. Причём можно было часть разделов назначить мастером на первом сервере, часть на втором. Но есть один момент. У меня сервера почти всегда были на связи. Поэтому практически всегд было однозначно определно, где мастер, где слейв. Суть в том, что если drbd-раздел в режиме слейва, его нельзя использовать. Таким образом, если ты разъединишь компы, поработаешь на стационарнике, параллельно поработаешь на ноуте, у тебя появятся два мастера, каждый из которых в своём состоянии. И при последующей попытке синхронизации в любом случае один из них придётся объявиться слейвом и все изменения на нём будут утеряны.

shell-script ★★★★★
()
Ответ на: комментарий от Harliff

После создания пула у тебя сразу имеется корневой датасет, а если у тебя есть датасет, значит можно сделать снапшот и перегнать его с send/recv.

Не рекомендую гонять датасет с корневой файловой системой на рабочей системе, могут вылезти неожиданные грабли в неожиданных местах (@Clockwork уже сталкивался, хоть и достиг этого другими изменениями — откатом на рабочей системе; но значения не имеет — любые изменения юзерспейса на рабочей системе могут привести к проблемам).

Но можно выкрутиться с помощью клонов — на одном работаешь, второй обновляешь, перезагружаешься, первый под обновления и так по кругу… но тут нужно понимать как это всё работает. В FreeBSD есть ZFS Boot Environments, можешь раскурить и применять эти знания где угодно с ZFS (или другой файловой системой, которая позволит делать так же).

mord0d ★★★★★
()
Admin