[РЕШЕНО]dd и изменение размера раздела

[lnx]

Коллеги, dd прекрасен своей лаконичностью и работоспособностью. Формально он полностью клонирует разделы. Команда вида dd bs=16M if=/dev/sdb ssh root@serverB "dd bs=16M of=/dev/sda" позволяет через ssh сделать это удаленно. Однако sdb почти никогда не бывает такого же размера, что и hda и потому после копирования приходится лечить проблему запуском проверки диска. И хорошо, если hda больше, чем hdb.
С учетом ограниченной возможности для экспериментов, как тыщами километров дистанций, так и ассортиментов наличных дисков, хотелось бы авторитетной подсказки по проблеме - создать образ от hdb и корректно уменьшить размер именно уже в образе? разбивка всегда такая: раздел 1=20гб (условно), раздел 2=20гб, остальное - неразмеченное пространство, которого из-за отсутствия малых форм и размеров от 210гб и более.
В итоге пошел таким путем -

0. подготовка - со второго раздела, где хомовник, содержимое перенес на первый, в fstab строку хомовника закоментил, второй раздел удалил, соотв. отсалься один, загрузочный. Создал эталонный образ.
1. клонирую нужным способом этот образ (в процессе добился его облегчения в разы) - напрямую ли, через ssh, со сжатием или без
2. после конирования штатная проверка раздела e2fsck -f /dev/sd...
3. затем fdisk /dev/sd... и на свободном месте создаю новый раздел, форматирую его в нужную фс, правлю fstab и прописываю хомовник по новому разделу (фактически раскомментирую).

[x230w]

dd круть конечно же.
но в в "здравый смысл въезжать иногода нуна" ... 16 мег для bs курто же более чем! ... вопрос...
Удалённый доступ к утилите меня вообще смуитл... К чему это?.. Но видимо Т.С. виднее...

[ALiEN]

Это вряд ли. Лучше используйте tar или squashfs.

[lnx]

Действительно ТС виднее и так нужно. Мизансцена такая - в одной стране одни козлы, в другой стране другие козлы и гадят друг другу, мешая братским народам и не читавши многовариантные истории про Иванов Никифрычей. Мать природа и няньки позаботились о разнообразии и выживаемости видов. В этой связи прямой связи нет ни по ip, ни по доменными именам, только через сервер посредник ssh, туннели. Образ диска весит 80гиг. Сервер-посредник такое себе не примет по размеру для проброса в виде файла. Следовательно, только он-лайн транзит....
Инструмент dd через ssh прекрасно работает, "стендовые испытания" проведены, отлажено. Другое дело, что учетом размера проброс даже 80гб, из которых полезных лишь 9 (и даже сжатый образ диска весит 20гб), это вес и время бесперебойной связи, что в целях учета потенциально разных по размерам sda and sdb второй раздел урезал до 1гб. и встает вопрос о пуленепробиваемом варианте изменения второго раздела до максимальной емкости диска без физического доступа с моей стороны и ограниченных компетенциях на "той" стороне при отсутствии голосовой связи.
Решение должно быть условно коробочное - взял диск + подключил проводами к работающему компу с удаленным доступом - подождал - выключил по команде - вынул - вставил в другой - включил = работать.

В опасениях перебдеть или недобдеть вроде запускаешь e2fsck -f и проходит без ошибок. Но мы-то знаем, что из-за разных рамзеров операция однозначно проходит не в полной мере корректно и сейчас это выражается в некорректности указания общего размера диска. Тот же fdisk красными буковками пишет про некорректность указания неразмеченного пространства. Чем чревато - пока не понял. Как лечить "в одно касание" - тоже. Уже пару раз суперблоки повреждал. Каждая итерация занимает около часа. Отрабатываю упражнениями.

[lnx]

Иллюстрирую ситуацию Целевой диск меньше исходного -

dd bs=16M if=/home/hetz/linuxcnc.img | ssh root@cnc "dd bs=16M of=/dev/sdc"
dd: ошибка записи '/dev/sdc': На устройстве не осталось свободного места
0+494506 записей получено
0+494505 записей отправлено
16231956480 байт (16 GB, 15 GiB) скопирован, 11592,3 s, 1,4 MB/s

Нормальная и правильная реакция. В обратном случае на исходной машине пишет ОК.

Касательно козликов - запускаем mtr до шлюза, потеря пакетов 0. Запускаем браузер и тыркаем хотябы гугломыло через ssh - почти моментально начинаются потери пакетов до 45% и продолжается даже после прекращения такого трафика. Проверено на нескольких в разных странах находящихся шлюзах. Аналогично с тлг и ВАпом - бульканье, отдельные слова.

[lnx]

Из непонятного - вот имеем сжатый образ диска, созданный силами dd. Сжатый весит 20гб, несжатый весит 80гб, разница есть. Хрестоматийно распаковка задается как -
в случае локальном -
gzip -dc linuxcnc.img.gz| dd of=/dev/sdc bs=4M status=progress

не описано в документации, но по аналогии удаленно через ssh рисуется так -
gzip -dc linuxcnc.img.gz | ssh root@cnc "dd of=/dev/sdс bs=4M status=progress"

есть подозрение, что это (предварительная упаковка) бессмысленно, потому как в ssh я передаю уже распакованный поток. Как бы исхитриться передать упакованный?

[ALiEN]

dd if=linuxcnc.img.gz | ssh root@cnc "gzip -dc | dd of=/dev/sdс bs=4M status=progress"

[lnx]

dd if=linuxcnc.img.gz | ssh root@cnc "gzip -dc | dd of=/dev/sdс bs=4M status=progress"

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

77667696640 bytes (78 GB, 72 GiB) copied, 4687 s, 16.6 MB/s30857016+1 records in
30857016+1 records out
15798792479 bytes (16 GB, 15 GiB) copied, 4688.8 s, 3.4 MB/s
80025616384 bytes (80 GB, 75 GiB) copied, 4708 s, 17.0 MB/s
0+2423813 records in
0+2423813 records out
80026361856 bytes (80 GB, 75 GiB) copied, 4719.74 s, 17.0 MB/s

при том, что размер зипованного образа был 14гб. Т.е. на время выполнения операции не повлияло. Вероятно потому, что на том конце обычный винчестер и мы упирались в скорость его записи. В самом начале выполнения текущую скорость показывало под 25мб\с.

[ALiEN]

Думаю, упирается не в винчестер, а в архиватор.
gzip однопоточный. Смотрите в сторону zstd, xz или lz4

[lnx]

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

[ALiEN]

И вопрос корректного и безопасного дорасширения

https://archlinux.com.ru/forum/viewtopi ... 9679#p9679

[vasek]

Однако sdb почти никогда не бывает такого же размера, что и hda

Если разделы/диски разного размера то нужно использовать не dd а файловый метод копирования.

[Arhei]

вопрос корректного и безопасного дорасширения последнего раздела до максимально возможного размера нового диска пока остался не решенным

ну а что там его решать, если у вас стандартная файловая система ext4 то всё довольно просто
!! Ограничение: принимающий диск всегда должен быть равен или большего размера чем отдающий
Если принимающий диск больше то после клонирования нужно
1-е изменить таблицу разделов вписав новые размеры
2-е изменить размер файловой системы

Таблицу разделов можно изменить, например, с помощью утилиты sfdisk
допустим у нас есть диск sdc с двумя разделами(sdс1,sdс2), где после второго раздела идёт свободное место до конца диска

echo ", +" | sudo sfdisk -N 2 /dev/sdc

данная команда расширит второй раздел до конца диска, вернее пропишет изменения в таблицу разделов диска sdc
проверка на возможные ошибки

sfdisk -V /dev/sdс

Теперь что касается увеличения файловой системы
для этого существует простая команда

sudo resize2fs /dev/sdс2

где sdс2 по аналогии с примером выше
ну и делаем проверки до и после

e2fsck -f /dev/sdс2

Сжатый весит 20гб, несжатый весит 80гб

Другое дело, что учетом размера проброс даже 80гб, из которых полезных лишь 9 (и даже сжатый образ диска весит 20гб)

такими темпами вы скоро переплюнете объёмы порнотрафика в принимаемой стране ))
проще взять выжимку из файловой системы(сколько там 9 гиг?) -> сжать -> передать, подготовить диск, распаковать на диск, подправить загрузчик и fstab, профит.
ну и конечно же делать это не руками а подготовить скрипт
проблему передачи больших объёмов и преодоления разных преград можно решить с помощью того же торрента, пусть качает.
Скачал, закинул на флешку, туда же скрипт, загрузился, запустил скрипт, пошел пить чай.

[ALiEN]

Бекап по удалёнке я так делаю:

ssh user@host "tar -C /mnt -c . | lz4 -c" | lz4 -cd | sqfstar backup.sqashfs

Прокладка с lz4 тут исключительно для экономии канала и траффика.

Огромный плюс squashfs в том, что образ можно подмонтировать без дополнительных телодвижений - не требует распаковки образа, как в случае с пожатым разделом, сделанным dd.

полезных лишь 9 (и даже сжатый образ диска весит 20гб),

Дык вы ВСЮ ФС сжимаете, а не только файлы на ней. Естественно, будет оверхед.

Cкрытый текст

$: du -h backup.sqashfs
2,0G    backup.sqashfs

$: ssh host df -h | grep /mnt
/dev/vda2       8.0G  3.7G  4.3G  46% /mnt

[vasek]

Очень, очень редкий способ клонирования разделов диска - cat .... цитата
Существует множество способов резервного копирования или клонирования разделов диска для обеспечения сохранности данных или их переноса на новое устройство хранения. Одним из нетрадиционных, но эффективных методов является использование команды cat. Обычно для клонирования дисковых накопителей применяется инструмент dd, но в случаях, когда эту операцию нужно провести быстро, утилита cat является отличным выбором.
Синтаксис команды cat для клонирования раздела имеет следующий вид:
cat /dev/source_partition > /dev/destination_partition
/dev/source_partition — исходный раздел диска
/dev/destination_partition — раздел диска, куда будут скопированы данные с исходного раздела

[lnx]

cat .... цитата

Лихо. А вариации из ранее сделанного iso или iso.gz, да еще и через ssh? вида -

cat /dev/sda  | ssh u@s "> /dev/destination_partition"  
cat d.iso > ...

прокатит?
ибо dd довольно долго -

80026361856 bytes (80 GB, 75 GiB) copied, 56064.6 s, 1.4 MB/s

[ALiEN]

dd довольно долго -

Да что вы так вцепились в этот dd? Он вообще вам не нужен.

Cкрытый текст

Синдром утёнка?

[vasek]

Мне больше нравится mc (Midnight Commander) - все видно

Кому то нравится rsync:
Вы можете скопировать все файлы с сервера A на сервер B, сохранив их права и пользователей: rsync — пожалуй, лучший инструмент для этого.

[ALiEN]

Очень, очень редкий способ клонирования разделов диска - cat .... цитата

И еще реже. Даже cat не нужен

command < file

[vasek]

Мне больше нравится mc (Midnight Commander) - все видно

Алиса ... MC + SSH
Инструкция
Чтобы подключиться к серверу по SSH через MC, нужно:
1. Запустить MC на удалённом сервере.
2. Нажать F9, выбрать «Правая панель — Shell-соединение».
3. В появившемся окне ввести логин@ваш_ip:порт_ssh (например, user@123.123.123.123:22).
4. Подтвердить желание подключиться и ввести пароль пользователя.
После подключения в MC слева будет файловая система сервера, а справа — файловая система локального ПК.

Ошибки
По умолчанию подключение через MC невозможно, если авторизация к серверу настроена через публичный ssh-ключ с указанием его нестандартного расположения через параметр -i
Решение: использовать для подключения отдельный конфигурационный файл в стандартном каталоге расположения ssh-ключей в профиле пользователя. По умолчанию этого файла нет, его нужно создать: mcedit ~/.ssh/config
В файл записать расположение личного ssh-ключа, username на сервере (login) и hostname (адрес сервера), порт, если нужно, и алиас этого подключения.

Важно: если нужно сразу после логина перейти в какой-то каталог, можно сделать alias для подключения в .bashrc или при подключении полностью указать каталог, куда надо зайти.

PS - google 1 .... 2