Клонирование LVM-раздела

не затрётся ли что-то важное на диске случайно?

Нет. Попытка записи за границы устройства приведет к ошибке, перезаписано ничего не будет. dd напишет что-то вроде I/O error, insyfficient space, input N+1 records, output N records

Понял. Спасибо.

Выводи размер 4K блоками (по размеру сектора на винте, новые почти все 4K) и создавай (для уверенности) новый LV на 2 блока больше.

Писец просто! А зачем тогда нужны снимки LVM?!

У тебя все хорошо?

Снимки нужны, чтобы можно было делать консистентные бэкапы на живой системе.

А помещать снимки на чистый подготовленный LVM нельзя разве? Что? dd всё ещё необходимая утилита по работе с LVM?

>А помещать снимки на чистый подготовленный LVM нельзя разве?

Снимки не для этого. Я не знаю, что ты подразумеваешь под «чистым» LVM (и сомневаюсь, что ты знаком с его терминологией), но данные с одного PV можно мигрировать на другой с помощью pvmove.

А, понял, что ты имел ввиду. Да, нужен dd.

Только не говори, что ты сможешь вот так просто взять слайс, сделать с него снимок и без поблочного копирования создать клон этого снимка на другом слайсе 8)

Только не говори, что ты сможешь вот так просто взять слайс, сделать с него снимок и без поблочного копирования создать клон этого снимка на другом слайсе 8)

Утилита с параметром «dump -L» разве перестала работать? Не знал.

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

# xfs_freeze -f /mountpoint; lvcreate -L592M -s -n dbbackup /dev/ops/databases; xfs_freeze -u /mountpoint
# mkdir /mnt/ops/dbbackup && mount -o nouuid,ro /dev/ops/dbbackup /mnt/ops/dbbackup
# tar -cf /dev/rmt0 /mnt/ops/dbbackup
# umount /mnt/ops/dbbackup && rm -r /mnt/ops/dbbackup
# lvremove /dev/ops/dbbackup

и без поблочного копирования

1) lvcreate -s -L 1G -n lv1_snap /dev/vg1/lv1
2) dd if=/dev/vg1/lv1 of=<тут ставим, куда. это может быть файл или блочное устройство, в т.ч. и LV>
3) lvremove /dev/vg1/lv1_snap

При поблочном копировании снимки в принципе не нужны. Достаточно на время поблочного копирования размонтировать файловую систему.

Термин «поблочное копирование» я отношу к копированию всей информации с доступного блочного устройства и/или логического тома, представимого в иерархии /dev и имеющем определённый/фиксированный размер в байтах.

>Достаточно на время поблочного копирования размонтировать файловую систему.

Дык вот если сделать снимок LVM, то размонтировать не нужно (правда, перед его созданием неплохо бы sync сделать). Это ж неприкольно, на боевом сервере размонтировать корень, правда?)

btw, я уже писал о pvmove, этой утилитой можно физически перемещать данные между носителями (или разделами) без каких-либо телодвижений (разве что с проседанием производительности на время работы).

На шаге 2, я так думаю, логический том с активно используемой Ext4 повысит своё IOWait раз в десять, да?

сарказм защитан. понятное дело, что повысит.

Тогда топикстартеру может стоит использовать такую методику:

1) Создать снапшот логического тома;
2) Примонтировать снимок;
3) Сделать dump(8) файловой системы примонтированного снимка;
4) Отмонтировать снимок;
5) Уничтожить снапшот;
6) Сделать restore(8) из образа дампа в новый логический том.

По-моему, это будет гораздо эффективнее и экономичнее dd, так как dump/restore не занимаются сохранением/восстановлением незанятых данными блоков.

Тогда уж проще смонтировать и копировать втупую. Хотя тут уже дело личных предпочтений.

Тогда уж проще смонтировать и копировать втупую.

Что быстрее: cp или dump?

ок, твоя взяла :)

Спасибо, учту, но не в этот раз.

В моём случае копируются разделы с виртуальными машинами, так что, смысла в dump/restore не вижу.