ZFS инкрементальный бэкап

send / recv очевидно.

https://github.com/Jehops/zap

Не сравнивали ли Вы это случайно с znapzend и syncoid?

Нет.

Преимущество zap перед альтернативами в том, что у него нет конфига, всё хранится в пропах самой ZFS, скрипт лишь ищет zap:snap на предмет что снапшотить и zap:rep на предмет куда реплицировать снапшоты. Всё, никаких изысков, ничего лишнего, просто репликация.

Я пользуюсь zfs-autobackup. Там нет конфига, выборка датасетов идет из атрибутов zfs. Что для меня важно: автомтически продолжает прерванные передачи.

Спасибо. А нет ли в дикой природе уже готово скрипта, который к примеру делает полный бэкап раз в месяц и допустим раз в неделю инкрементальный, держит к примеру 4 копии полного бэкапа и по кругу их удаляет.

Чет мой гуглеж особо ничего не нашёл.

Можно конечно и самому написать, но думаю это уже кто то решал.

Я юзаю zfstools, который делает снимки с нужной мне периодичностью. А бекап на внешний сторедж делается по разному, так как не всегда инкрементальный бекап при помощи ZFS снимков является оптимальным вариантом. Некоторые проги изменяют блоки ФС но при этом пишут минимум данных. В таким случаях, эффективнее делать инкрементальный бекап файлов при помощи restic или borgbackup.

дык iron все и написал :) там у него аккурат отдельные абзацы про полный и дифференциальный бекап (хотя я приверженец инкрементального).
а дальше небольшие движения с zfs rename для ротирования бекапов…
вариант2: паковать поток zfs в сжатый файл.

Да, я про ротацию и говорю :) Не охото свой велик писать, думал может уже готовые скрипты есть

есть :) но выкладывать ротацию в виде, образно говоря, набора простых команд

zfs destroy pool1@data_3old
zfs rename  pool1@data_2old pool1@data_3old
zfs rename  pool1@data_1old pool1@data_2old
zfs rename  pool1@data pool1@data_1old
zfs send pool0/data@init | zfs recv pool1@data

сам понимаш… :)
п.с. все вышенаписаное написано от балды корявыми пальтцами, без рихтовки по месту не применять :)
п.п.с: я записывал поток в сжатый файл - имхо прощеее

я записывал поток в сжатый файл - имхо прощеее

Пробовал когда-нибудь восстанавливать?

Я однажды занимался рискованной переделкой пула, из зеркала достал один диск, скинул на него zfs send пула, который как раз еле влезал (без сжатия), переделал пул и… На этапе zfs recv выяснилось, что поток битый. Дальше меня ждали три незабываемые ночи с патчингом ядра фрибсд дабы он игнорировал ошибки в определённых местах потока. Когда файловые системы были восстановлены, прошёлся scrub-ом, и там всего пара десятков битых файлов нашлась, и те не важные были. Грешу на оперативку, т.к. все ошибки были в один бит в одной и той же структуре данных.

хех, про такое чет не подумал :) да, согласен. в таком случае ошибка была б выявлена сразу. а файл есть файл…
~но думаю допилют когданибудь чекер потока zfs-stream. имхо это базовое требование к любому архиву.~
ну еще был интересен модуль монтирования zfs-stream, хотя бы в режиме ro. потому ушел в squashfs (ну и zfs мне как атомным микроскопом по обойному гвоздю…)

миль пардон устареваю. так понял ужо есть: zstream dump без опции -C Suppress the validation of checksums. должон проверить чексуммы потока ??

zfs snapshot - это избыточно, они же место на диске занимают. Достаточно zfs bookmark

Единственное, с ним есть нюанс - в утилите zfs сломаны рекурсивные bookmarks

zfs snapshot - это избыточно

Снапшот, при необходимости, можно примонтировать в отличие от букмарка.

У zfs-autobackup по умолчанию хранятся: 10 последних 7 ежедневных 4 недельных 12 месячных

Ротирует сам

Политика настраивается через командный аргумент

Пока понравился borgbackup, во всю тестю, жаль что однопоточный =(

Вроде есть borgbackup2 многопоточный, но пишут что нестабилен.

В моем сценарии гашу сервисы, делаю снапшот, а с него уже снимаю бэкап borg'om на другой диск.