самое простое это посмотреть где файлуха начинается. Ну или методом тыка постепенно увеличивая offset :)

самое простое это посмотреть где файлуха начинается.

А способ как и чем смотреть и что искать не подскажите?

Конец кусочка файла (первые 10 Mb)

$@^@^@^@

Вот только что искать?

Наверное не зря такая схема распространена

LVM+DRBD+LVM

Как оказалось задачка не из простых

((

Вот я упустил

Дело-о в том что этот диск DRBD отдан виртуальной машине. А значит смонтировать даже со смещением не получится. Там нет файловой системы. Но вопрос остается. Есть бэкап LVM на котором DRBD. Надо развернуть образ и отдеть вирт.машине на которой нет DRBD Опять же dd но как офсет вычислить. Судя по тому что поверх DRBD делают LVM (значит структура данных не меняется) то офсет должен прокатить.

http://www.drbd.org/users-guide-emb/ch-internals.html, не?

Вы имеете в виду рассчитать по формуле и такой offset сделать?

только как у меня файл, как получить неизвестные для формулы? думаю не тот способ!

Вообще, меня смущает это:

> It does so by setting aside an area at the end of the device

Т.е. вроде как данные идут с начала файла/устройства.

Значит теоретически

При развертывании на новом месте без DRBD мешаться не должны.

Создание бэкапа:
Есть LVM том
Поверх него DRBD (диск для KVM)
Затем снапшотом LVM снял образ

Восстановление:
Развернул снапшот на файл.
Запустил машину и все работает
fdisk даже не ругается.
Фантастика!

Почему fdisk не ругается??????

Видимо

эта часть, где метаданные просто теряется. По хорошему её бы все таки отсечь. и вот интересно если на DRBD восстановить метаданные найдутся. В связи с чем у меня мысль что снапшот LVM не снимает метаданные DRBD. Такое может Быть?

Не я не прав

Посмотрел на один из дисков LVM

Диск /dev/dm-1: 115.3 ГБ, 115343360000 байт
255 heads, 63 sectors/track, 14023 cylinders, всего 225280000 секторов
Units = секторы of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0005055f

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/dm-1p1   *        2048    19531775     9764864   83  Linux
/dev/dm-1p2        19531776    22071295     1269760   82  Linux своп / Solaris
/dev/dm-1p3        22071296   225263429   101596067   83  Linux

Это легко понять (если я правильно понял) когда диск dev, а когда он еще бэкап.

P.S.: Лучше вынести метаданные во вне?!

> P.S.: Лучше вынести метаданные во вне?!

Зависит от. Очень часто (это такой эвфемизм к «всегда») от метаданных без самих данных проку мало. Выносят отдельно для ускорения.

Вот я и на распутьи

Не знаю как? очень не хочется кусок метаданных старых за собой тащить

А что, 8 мегабайт погоду сделают?

а если потом еще раз бэкап снять и еще раз восстановить уже 16 )))

Это почему это? Размер ФС фиксированный, метаданных DRBD тоже. С чего это они должны увеличиваться?

ну как

Снимаю образ тома кторый под DRBD в образ попадают и данные и метаданные. Затем разворачиваю образ на диск DRBD. Вот потеря 8 MB. Если это повторять то кратно будут увеличиваться потери.

P.S. В случае если развернуть образ на том под DRBD метаданные не находятся почему то (я предпологал что найдутся)