Получить инкрементный поток ZFS клонирования и перезаписать источник

tldr; Я пытаюсь получить поток ZFS, созданный как реплика (-R) из клонированной файловой системы. Использование zfs recv -o origin=[clone-origin] просто дает cannot receive: local origin for clone [...] does not exist.

Предварительное условие

У меня есть файловая система ZFS зоны SmartOS, которая клонирована из определенного образа. (IMAGE-uuid и ZONE-uuid заменены для удобства чтения)

$ zfs list -r -o name,origin zones/[ZONE]
NAME          ORIGIN              
zones/[ZONE]  zones/[IMAGE]@[ZONE]

Файловая система зоны имеет серверные снимки:

$ zfs list -r -t all -o name, origin zones/[ZONE]
NAME                  ORIGIN              
zones/[ZONE]          zones/[IMAGE]@[ZONE]
zones/[ZONE]@[SNAP0]  -
zones/[ZONE]@[SNAP1]  -
zones/[ZONE]@[SNAP2]  -
[...]

Что касается базового образа, то SmartOS (лучше vmadm) создает снимок образа для только что созданной зоны. Корень зоны создается как клон на основе этого моментального снимка (здесь с guid 11194422825011190557).

$ zfs list -r -o name,origin,guid zones/[IMAGE]
NAME                        ORIGIN  GUID
zones/[IMAGE]               -       5616748063181666458
zones/[IMAGE]@[OTHER-ZONE]  -       11174377117517693115
zones/[IMAGE]@[OTHER-ZONE]  -       5587104570997150836
zones/[IMAGE]@[OTHER-ZONE]  -       535244446308996462
zones/[IMAGE]@[OTHER-ZONE]  -       12527420623439849960
zones/[IMAGE]@[ZONE]        -       11194422825011190557
zones/[IMAGE]@[OTHER-ZONE]  -       18143527942366063753
zones/[IMAGE]@[OTHER-ZONE]  -       15066902894708043304
zones/[IMAGE]@[OTHER-ZONE]  -       16574922393629090803
zones/[IMAGE]@[OTHER-ZONE]  -       818178725388359655
zones/[IMAGE]@[OTHER-ZONE]  -       11867824093224114226
zones/[IMAGE]@[OTHER-ZONE]  -       9357513766021831186

Резервное копирование

Чтобы создать резервную копию корня моей зоны, я создал моментальный снимок и реплицированный поток.

zfs snapshot zones/[ZONE]@[DATE]
zfs send -R zones/[ZONE]@[DATE] > [ZONE]_[DATE].zfs

Проверка с помощью zstreamdump показывает ожидаемое происхождение. Он в шестнадцатеричном формате, но 0x9b5a943fae511b1d равен 11194422825011190557:

$ zstreamdump < [ZONE]_[DATE].zfs
BEGIN record
        hdrtype = 2
        features = 4
        magic = 2f5bacbac
        creation_time = 0
        type = 0
        flags = 0x0
        toguid = 0
        fromguid = 0
        toname = zones/[ZONE]@[DATE]
nvlist version: 0
        tosnap = [DATE]
        fss = (embedded nvlist)
        nvlist version: 0
                0xf19ec8c66f3ca037 = (embedded nvlist)
                nvlist version: 0
                        name = zones/[ZONE]
                        parentfromsnap = 0x0
                        origin = 0x9b5a943fae511b1d
                        props = (embedded nvlist)
                        nvlist version: 0
                                devices = 0x0
                                compression = 0x2
                                quota = 0x500000000
                        (end props)
[...]

Восстановить

Для восстановления дезастера пересоздаю зону по vmadm create с бэкапом описания vm (сохраняется ZONE-uuid). vmadm извлекает образ и создает соответствующую файловую систему zfs zones/[IMAGE] со снимком в качестве источника клона для воссозданной файловой системы зоны zones/[ZONE].

Итак, структура та же, что и до краха:

$ zfs list -r -o name,origin zones/[ZONE]
NAME          ORIGIN              
zones/[ZONE]  zones/[IMAGE]@[ZONE]

Однако руководство моментального снимка изображения (созданного vmadm) отличается - как и ожидалось. Поток ожидает 0x9b5a943fae511b1d (или 11194422825011190557), но на самом деле 12464070312561851369:

: zfs list -r -o name,guid zones/[IMAGE]
NAME                  GUID
zones/[IMAGE]         5616748063181666458
[...]
zones/[IMAGE]@[ZONE]  12464070312561851369
[...]

Вот где, подумал я, появляется параметр -o origin= для zfs recv.

Проблема

Восстановление реальных данных путем получения потока zfs заканчивается ошибкой:

$ zfs recv -vF zones/[ZONE] < [ZONE]_[DATE].zfs
cannot receive: local origin for clone zones/[ZONE]@[SNAP0] does not exist

(где SNAP0 – это первый снимок резервной копии файловой системы, см. "Предварительное условие" выше)

Это ожидаемо, так как руководство изменилось. Итак, я принудительно установил происхождение снимка изображения с новым guid (12464070312561851369), но ошибка остается прежней:

$ zfs recv -vF -o origin=zones/[IMAGE]@[ZONE] zones/[ZONE] < [ZONE]_[DATE].zfs
cannot receive: local origin for clone zones/[ZONE]@[SNAP0] does not exist

Вопрос

Верна ли моя интерпретация параметра -o origin=?

Почему не работает, как ожидалось?

Если это неправильный путь, как я могу создать резервную копию и восстановить клонированную файловую систему zfs?

Большое спасибо, что читаете и помогаете!


person Jonas    schedule 15.08.2018    source источник


Ответы (1)


Кажется, вы наткнулись на ошибку ZFS, которая только сейчас привлекла к себе внимание.

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

Флаг -R пытается сохранить все виды отношений, которые часто могут не иметь значения, такие как родительские клоны и т. д. Нет удобной альтернативы, которая отправляла бы только все инкременты до этого. Вместо этого вы должны сделать два прохода. Это не относится конкретно к vdadm, поэтому для ZFS в целом логика следующая:

zfs send zones/[ZONE]@[EARLIESTDATE] > [ZONE]_[EARLIESTDATE].zfs
zfs send -I zones/[ZONE]@[EARLIESTDATE] zones/[ZONE]@[DATE] > [ZONE]_[EARLIESTDATE]-[DATE].zfs
zfs recv -vF zones/[ZONE] < [ZONE]_[EARLIESTDATE].zfs
zfs recv -vF zones/[ZONE] < [ZONE]_[EARLIESTDATE]-[DATE].zfs

После этого необходимы только проходы -I между последним снимком из резервной копии и самым новым в источнике.

Если вам нужно восстановить уже созданный поток

Одним из предлагаемых решений является использование модифицированного варианта zfs, описанного здесь:

https://github.com/openzfs/zfs/issues/10135

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

FQ_OVERRIDE_GTND=1 .zfs recv vF -o origin=zones/[IMAGE]@[ZONE] zones/[ZONE] < [ZONE]_[DATE].zfs

Другой отчет об ошибке находится здесь:

https://github.com/openzfs/zfs/issues/10935

person Johan Ehnberg    schedule 08.01.2021