вот тут ссылка

!warn

Aleksandr U. has warned Deface (1/3)

раз не понимает сам, то придётся помочь.

прежде чем бэкап делать - вы уже ответили себе на вопрос: облачный провайдер даст вам сделать образ ВМ более 100Гб?

в aws даст,в do нет, в aws будет чуть дороже и не апрувил еще. пока с DO разюираюсь

Ну так удаляй

#вопрос а можно ли как нибудь сделать reduce disk on proxmox? с увеличением понятно

А чем именно? Способом запуска? Может быть я неудачно выразился. Репликацией я назвал миграцию. Ну это свчзано с тем, что сейчас я миграцию делаю через zfs send, оставляя старые данные на старой ноде вместе со снимком и потом через zfs send -i, то есть инкрементальный send я возвращаю машину назад. По этому я назвал это репликацией.

Миграция средсвами проксмокс делается из web-интерыейса и идёт очень медленно. Я не знаю почему.

cp внутри ВМ на другой диск меньшего размера

Ну т.е аыключил машину и сказал проксмоксу мигрировать на жругую ноду. Другая нода в германии, связь через l2-vpn (tinc). Данняе и тут и там на zfs. Судя по логам, проксмокс в таком режиме тоже zfs send использует, но работает это медленно.

Ещё медленее работает online миграция. Там вообще сотни килобайт в секунду и это проксмокс делает через репликацию диска  средствами qemu.

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

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

Возьмите и сделайте:
dd if=/образ_текущей_ВМ of=/образ_новой_ВМ count=50%_от_размера_текущего_образа_для_ВМ.
А потом запустите ВМ с новым образом и посмотрите что осталось целым

gparted может собрать данные и передвинуть границы файловой системы. Это деструктивная операция, перед её выполнением, нужно сделать снимок или бакап. Но после успешного завершения, снимок можно удалить.

Кстати, gparted - это графический фронтэнд к набору cli-утилит. но, лично я им пользуюсь через X11 и Xming на винде или напрямую на linux

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

root@bal-vm:~# truncate --help
Использование: truncate КЛЮЧ… ФАЙЛ…
Урезает или увеличивает размер каждого ФАЙЛА до заданного размера

Если ФАЙЛ не существует, то он создаётся.

Если ФАЙЛ больше заданного размера, все лишние данные будут потеряны.
Если ФАЙЛ короче, то он расширяется, и это место
читается как нулевые байты.

Аргументы, обязательные для длинных ключей, обязательны и для коротких.
  -c, --no-create        не создавать файлов
  -o, --io-blocks        считать РАЗМЕР числом блоков вв/вывода, а не байтов
  -r, --reference=RФАЙЛ  базовый размер RФАЙЛА
  -s, --size=РАЗМЕР      установить или подогнать размер файла
                         под РАЗМЕР байт
      --help     показать эту справку и выйти
      --version  показать информацию о версии и выйти


РАЗМЕР задаётся целым числом и необязательной единицей изменения
(пример: 10K это 10*1024). Единицы изменения:
K, M, G, T, P, E, Z, Y (степень 1024) или KB, MB, … (степень 1000).

Перед РАЗМЕРОМ может быть один из следующих символов:
«+» — расширить на, «-» — сократить на, «<» — не более,
«>» — не менее, «/» — округлить с сторону уменьшения,
«%» — округлить в сторону увеличения.

Оперативная справка GNU coreutils: <https://www.gnu.org/software/coreutils/>
Об ошибках в переводе сообщений «truncate» сообщайте по адресу <gnu@d07.ru>
Полная документация: <https://www.gnu.org/software/coreutils/truncate>
или доступная локально: info '(coreutils) truncate invocation'

root@bal-vm:~# truncate --help
Использование: truncate КЛЮЧ… ФАЙЛ…
Урезает или увеличивает размер каждого ФАЙЛА до заданного размера

Если ФАЙЛ не существует, то он создаётся.

Если ФАЙЛ больше заданного размера, все лишние данные будут потеряны.
Если ФАЙЛ короче, то он расширяется, и это место
читается как нулевые байты.

Аргументы, обязательные для длинных ключей, обязательны и для коротких.
  -c, --no-create        не создавать файлов
  -o, --io-blocks        считать РАЗМЕР числом блоков вв/вывода, а не байтов
  -r, --reference=RФАЙЛ  базовый размер RФАЙЛА
  -s, --size=РАЗМЕР      установить или подогнать размер файла
                         под РАЗМЕР байт
      --help     показать эту справку и выйти
      --version  показать информацию о версии и выйти


РАЗМЕР задаётся целым числом и необязательной единицей изменения
(пример: 10K это 10*1024). Единицы изменения:
K, M, G, T, P, E, Z, Y (степень 1024) или KB, MB, … (степень 1000).

Перед РАЗМЕРОМ может быть один из следующих символов:
«+» — расширить на, «-» — сократить на, «<» — не более,
«>» — не менее, «/» — округлить с сторону уменьшения,
«%» — округлить в сторону увеличения.

Оперативная справка GNU coreutils: <https://www.gnu.org/software/coreutils/>
Об ошибках в переводе сообщений «truncate» сообщайте по адресу <gnu@d07.ru>
Полная документация: <https://www.gnu.org/software/coreutils/truncate>
или доступная локально: info '(coreutils) truncate invocation'

Чем он лучше?

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

Тем что не занимается повторно место. У меня иногда возникает ситуация, когда надо усечь виртуальную машину, диск которой объемом, например 2ТБ. А высвободить надо всего 200-300ГБ. Соответственно, делается снимок, проводятся все манипуляции, но в случае   zfs там конечно не файл а zvol и команда другая, проверяется работоспособность и снимок можно удалить. Кроме того, в беэкап у вас не уедет повторно весь образ, если вы делаете блочное диференциальное (инкрементальное) резервное копирование, т.к. большую часть блоков вы не трогаете.

Этот способ мне представляется более аккуратным и он намного быстрее.