И это правильно, по моему.

На ночь у меня возникло пару вопросов по proxmox backup server:

1. Если сервера забирает бекапы дифференциально с ноды кластера, а потом виртуалка переехала на другую ноду. Он её найдет сам самостоятельно? Или начнет заново, как будто она новая, полный бекап делать вместо дифференциального?

2. А если она переехала на другую ноду да ещё и в другое хранилище: была в ssd zfs пуле, а перехала на hdd zfs pool или, на lvm, или, проси хоспаде, в файл qcow2 в хранилище local. Тоже сделает дифференциальную копию или заново начнёт все тянуть?

3. Внутри PBS имеет смысл ради консистентности и надёжности хранить данные на zfs или там свой велосипед на файловых архивах? В какой степени он может использовать преимущества zfs?

4. Ни кто не сравнивал, насколько бекапы pbz отличаются по размеру от бекапов с помощью zfs send/receive?

Дело в том что я пилю свою реализацию zfs backup на bash. Пилю как умею, через быдлокод и такуюто матерь. И вот я думаю надо ли продолжать. Очевидно поддерживаемое решению лучше? Но у меня, часто выдает машинки переезжают из хранилища в хранилище и между нодами мигрируют. Бакапы забираются через интернет ssh-ом, для чего используется мощное сжатие. Всё на zfs лежит само собой, она к этому располагает.

Не PBS забирает бэкапы, а сам прокс делает бэкап и отправляет на PBS
1. в кластере у каждой ВМ свой уникальный номер. Бэкап привязывается к ID, поэтому на какой ноде запущена ВМ - не важно. Дифференциальный бэкап работает по механизму qemu diry pages - поэтому если ВМ была остановлена и запущена заново, то скорее всего будет сделан полный бэкап
2. Не имеет значения - сравниваются страницы памяти/образа и отправляются только изменившиеся
3. Преимущества zfs не используются, кроме тех которые позволяют собрать большие пулы из большого кол-ва устройств
4. используется zstd для сжатия

По моему, это fail.

Всё ясно, пилю дальше свой велосипед.

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

Да, верно. Но я обобщил свой опыт и находу данный подход отимальным.

После ряда историй с шифровальщиками, я считаю, что push для бекапов - очень плохая идея. По этому у меня не бекапном сервере ключи другие, пароли другие, сами ключи зашифрованы. И я надеюсь, что если когда-нибудь появится зловред и как-то заразит ноду в кластере, это предотвратит уничтожение бекапов.

И потом, а как ещё сделать раз в сутки бекам с 6 нод, на каждой из которых в районе 2-3ТБ горячих данных? А я делаю не раз в сутки, а раз в час! PBS вообще, как я понял, не вариант.

так в PBS можно сделать роль с доступом только для бэкапа и рестора. Чистить не сможет.

а как ваше приложение будет бэкапить запущенную ВМ и её состояние памяти? Или вы тоже будете использовать 'dirty bitmap'?

p.s. Хотя нет - это относится только к block device

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

а вы попробуйте всё же механизм встроенный в PBS и последние версии PVE:
https://github.com/qemu/qemu/blob/master/docs/interop/bitmaps.rst

вдруг окажется что у вас данных на блочных устройствах меняется не так много

Это правильно. Хорошо что они это предусмотрели. Но остальное слабое, хоть и более универсальное решение. Я постоянно нахожусь в поисках оптимального бакап решения для тех или иных ситуация. И технологии уже есть и вроде осталось все связать в единый механизм, но почему-то все пилят бекапы на своих велосипедах, вместо zfs (btrfs тоже как концепт подошел бы) - это правильно.

Вы же понимаете, что ntfs shadow в сочетании с zvol и zfs nsapshot позволяет делать тоже самое что и zfs send-recive только с винды.

Спасибо! Изучаю.

Рад что не я один так думаю. Есть в этом что-то правильное. Например, можно фаерволом запретить доступ к бекап серверу.

Это бэст практис, когда сервер бэкапов вообще не виден в сети и доступ к нему сильно ограничен.

Блин, по опыту работы с другими бекап решениями и предыдущей попытке написать ведосипед на rdiff, я пришел к выводу, что либо должны быть снепшоты и fs должна сама знать что поменялось, либо, я могу это математически доказать, придется произвести полное чтение source и что самое плохое, полное чтение destenation. Т.е. бекап-сервер будет постоянно занят.

Обратите внимание, даже ntfs может делать тоже самое что zfs - снимки (теневые копии) и поблочно их экспортировать (zfs send / receive), там правдfа все через api.

Нет альтернативы. Если состояние сбрасывается при выключении VM, то производительность будет маленькая, никаких raidz под бекапы и копирование только ночью с сильнейшей просадкой производительности. А у меня просто не успеет столько прочитаться с диска за ночь, сколько нужно проверить блоков будет на относительно медленном бекап сервере.

Чтобы не быть голословным, тем кто любит bash и pipe-ы я покажу zfs send на rdiff-е:

Usage: rdiff [OPTIONS] signature [BASIS [SIGNATURE]]
             [OPTIONS] delta SIGNATURE [NEWFILE [DELTA]]
             [OPTIONS] patch BASIS [DELTA [NEWFILE]]

Options:
  -v, --verbose             Trace internal processing
  -V, --version             Show program version
  -?, --help                Show this help message
  -s, --statistics          Show performance statistics
Delta-encoding options:
  -b, --block-size=BYTES    Signature block size
  -S, --sum-size=BYTES      Set signature strength
      --paranoia            Verify all rolling checksums
IO options:
  -I, --input-size=BYTES    Input buffer size
  -O, --output-size=BYTES   Output buffer size

Usage: rdiff [OPTIONS] signature [BASIS [SIGNATURE]]
             [OPTIONS] delta SIGNATURE [NEWFILE [DELTA]]
             [OPTIONS] patch BASIS [DELTA [NEWFILE]]

Options:
  -v, --verbose             Trace internal processing
  -V, --version             Show program version
  -?, --help                Show this help message
  -s, --statistics          Show performance statistics
Delta-encoding options:
  -b, --block-size=BYTES    Signature block size
  -S, --sum-size=BYTES      Set signature strength
      --paranoia            Verify all rolling checksums
IO options:
  -I, --input-size=BYTES    Input buffer size
  -O, --output-size=BYTES   Output buffer size

проверка идёт не на PBS, а на ноде где запущена ВМ.  qemu сам определяет какие страницы изменились и отправляет на PBS только изменившиеся страницы

Образ 2ТБ, как он определяет, что именно там изменилось? Либо эту информацию нужно где-то хранить: привет запись метаданных в zil и мы получаем zfs только в профиль, либо эту информацию должен предоставить бекап сервере в виде списка контрольных сумм блоков. А локально вычисляя эти же контрольные суммы и сравнивая, можно сказать что поменялось.

вот здесь описано, как именно это делает QEMU:
https://github.com/qemu/qemu/blob/master/docs/interop/bitmaps.rst