LINUX.ORG.RU

Перенос данных между жесткими дисками

 , ,


0

1

Есть домашний компьютер на Rocky Linux 9, который используется как файловый сервер, в нем 2 жестких диска по 512 Гб, объединенные с помощью lvm в 1 логический том в режиме RAID0, файловая система - XFS. Логический том монтируется в корень / и на нем лежит всё вместе: и ОС и данные.

Хочу изменить конфигурацию системы: саму систему установить на SSD на 512 Гб, смонтировать её в корень, а два диска по 10 Тб объединить в RAID 1 с помощью LVM и смонтировать полученный раздел в /var.

Как лучше провернуть такое?

Вижу такой план:

  • подключаю новые диски в систему;
  • на SSD с помощью fdisk создаю 2 раздела: основной и раздел для /boot/efi
  • с помощью LVM создаю физический том на основном разделе SSD, создаю отдельный логический том LVM;
  • с помощью LVM создаю по одному физическому тому на 10 Тб HDD и объединяю их в логический том RAID1;
  • на новых разделах инициализирую файловую систему XFS;
  • загружаюсь через Live USB;
  • монтирую разделы:
    • старый корень в /mnt/old_root;
    • старый efi в /mnt/old_root/boot/efi;
    • SDD в /mnt/new_root;
    • новый efi в /mnt/new_root/boot/efi;
    • новые HDD в /mnt/new_root/var;
  • копирую все файлы из /mnt/old_root в /mnt/new_root с помощью cp;
  • правлю /mnt/new_root/etc/fstab, чтобы он отражал новую конфигурацию дисков;
  • устанавливаю загрузчик на SSD;
  • выключаю комп;
  • отключаю старые диски;
  • загружаюсь в новую систему.

Подскажите, что мог упустить?

★★

Последнее исправление: Goganchic (всего исправлений: 1)
Ответ на: комментарий от Goganchic

Скопируется всё через cp, чтобы на логическом, а не на блочном уровне?

cp -ax переносит всё в большинстве случаев (cp -ax /mnt/old_root/* /mnt/new_root/). Мне кажется, что только установленные через chattr параметры не переносились, но не помню уже точно.

После копирования правишь fstab, монтируешь всё как надо в /mnt/new_root/, chroot-ишся туда и ставишь загрузчик.

p.s.: raid 1 под домашнюю файлопомойку - практически всегда плохая идея и деньги на ветер. Лучше использовать один из дисков под бэкап, например с btrfs с периодическим созданием снапшотов.

altwazar ★★★★★
()
Последнее исправление: altwazar (всего исправлений: 4)
Ответ на: комментарий от Goganchic

У тебя два диска постоянно включены, постоянно работают на чтение-запись, постоянно изнашиваются. Если нет цели поднять скорость чтения — в большинстве случаев горячий бекап раз в сутки вполне достаточно для персональных данных, а ресурс HDD продлевает очень намного.

Но дело твоё, разумеется.

Aceler ★★★★★
()

10 Тб объединить в RAID 1 с помощью LVM и смонтировать полученный раздел в /var

не надо в /var. Там пишется и читается всё подряд, а диски тебе явно не для этого. Смонтируй куда-нибудь в /mnt или /srv и явно указывай для хранения/делай симлинки.

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

Понял, спасибо!

Правильно ли я понимаю, что горячий бекап на уровне файловой системы поддерживается только в btrfs и zfs? Если использовать что-то более традиционное, типа ext4 или xfs, можно ли как-то организовать горячий бекап?

Goganchic ★★
() автор топика

man pvmove

перенесешь систему online (live USB не нужен), установишь загрузчик на ssd, избавишься от старых дисков

потом можно спокойно переместить /var на новый raid-1

futurama ★★★★★
()
Последнее исправление: futurama (всего исправлений: 2)
Ответ на: комментарий от futurama

Текущие диски у меня по 512 Гб в режиме RAID0, данных там примерно 900 Гб (то есть они размазаны по обоим дискам). Новый SSD будет максимум на 512 Гб (может быть 256 Гб, ибо он только под систему, а ей и 256 Гб за глаза). Если я правильно понял задумку, то у меня не получится перенести старый LVM на SSD с помощью pvmove.

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

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

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

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

В том-то и дело, что это файловый сервер в широком смысле слова: там запущены в Docker-ах различные домашние сервисы типа Gitea, Open Project и т.п. которым как раз нужна БД. Поэтому просто так взять и скопировать файлы rsync-ом не всегда получится.

Goganchic ★★
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

Прочитал 3 раза, но остались вопросы: нигде не нашел информации о том, можно ли делать live-бекап или нет? Т.е. Нужно ли мне остановить все активности (типа торрентов или запущенных БД) до того, как я смогу сделать бекап? Вроде бы xfsdump - это не про снапшоты (или про них?) и тогда непонятно даже в теории как может работать live-бекап в этом случае.

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

Толку тебе с твоего ssd, если все данные будут лежать на hdd?

IO будет ограничено быстродействием hdd, а то что система чуть быстрее загрузится с ssd это мелочь

Поэтому можно без ssd добавить 2 новых hdd в VG и при помощи pvmove мигрировать.

Можно и ssd туда же добавить, команды LVM позволяют указать какие LV на каких физических дисках будут расположены. Так что сможешь на ssd расположить всякое требующее большого iops

futurama ★★★★★
()
Последнее исправление: futurama (всего исправлений: 2)
Ответ на: комментарий от Goganchic

В том-то и дело, что это файловый сервер в широком смысле слова: там запущены в Docker-ах различные домашние сервисы типа Gitea, Open Project и т.п. которым как раз нужна БД. Поэтому просто так взять и скопировать файлы rsync-ом не всегда получится.

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

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

А с бекапами через LVM снапшоты какая схема?

  • оставляем какое-то количество неразмеченного пространства в LVM (в зависимости от того, насколько большая нагрузка на запись на системе, на домашнем сервере, думаю, хватит 10 Гб)
  • для бекапа делаем LVM-снапшот
  • копируем данные на бекапный HDD с помощью rsync --link-dest для получения инкрементальных бекапов
  • удаляем LVM-снапшот

Так?

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

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

То, что ты написал — один из вариантов, но если у тебя там СУБД в докере, то снапшоты тебе не подойдут, надо как-то морозить БД.

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

Не понял, почему не подойдут? Если я делаю snapshot, то у меня консистентное состояние на определенное время, максимум что будет - потеряются данные, которые из WAL не успели записаться на диск, но при старте базы WAL донакатится и всё будет хорошо. Какой-нибудь PgBackRest примерно так же работает, не? Что я упускаю из виду?

Goganchic ★★
() автор топика