Инкрементальный бэкап устройства

Я вот думаю просто заполнить себе, в будущем, raid 1, и не париться.

Для этого нужно держать пылесборник неподалёку, во времена когда технологии сквозного шифрования доступны даже первокласснику а холодные хранилища стоят тысячных центов за гигабайт вкусно выглядит именно инкрементальный бэкап по сети.

Проприетарное или как вариант с помощью borg backup бекапить целый раздел, он может в дедупликацию блоков (https://borgbackup.readthedocs.io/en/stable/usage/create.html#examples)

Примерно так

#!/bin/bash
export BORG_RSH="ssh -i /tmp/borg_id_rsa"
export BORG_REPO="user@192.168.1.2:/media/storage/borg-alt"
export BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK="yes"
cd /run/archiso/img_dev/
cp borg_id_rsa /tmp/
chmod 600 /tmp/borg_id_rsa

if [[ $(id -u) -ne 0 ]] 
then 
  echo "You need ROOT access" 
  exit 1
fi

borg info ::

for i in "lnx=04fdec1d-ed25-411c-bed8-32b40160e54a" "win10=DC78892D7889080A"
do
  name=$(echo $i | cut -f 1 -d "=")
  raw=$(blkid -o value --uuid $(echo $i | cut -f 2 -d "=")) 
  dd if=$raw bs=4M | borg create -s --progress --chunker-params 10,20,15,4095 --compression zstd,9 --stdin-name $name.img ::$name-{now} -
done

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

Ясен-красен. Идея настолько плохая, что отсутствие реализаций закономерно.

Вот где собак покопался, мне как-то внушило надежду наличие снэпшотов в lvm и прочих поделках уровня fs, но они же эти поделки и дефрагментируют постоянно диск…

Не знаю про LVM, но у меня на работе заводной пчелкой трудится велосипед, где эволюция дискового образа виртуалки, аки контейнера, хранится «послойно»; дедупликация при этом сделана средствами CoW наружней файловой системы. Так вот, ФС внутри виртуалки никто не сказал, что писать надо с расчетом на снапшоттинг, и она пишет с упором на надежность, скорость, дефрагментацию, что угодно, но не экономию write-ов. Места это в итоге жрет будь здоров. Так было бы и у тебя.

Это те хранилища которые стоят тысячные цента только если из них ничего не извлекать или что-то более интересное?

Те, те.

Идея совсем не плохая, в коммерческом софте реализована давно (в VMware уже лет 10 как).

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

Файловый сервер, на котором лежат образы пользовательских профилей цитриксового VDI. Образ - это VHDX-файл размером около 10 Гб в среднем.

Пользователь меняет один крошечный файл в своем профиле, и это приводит к бэкапу всего огромного VHDX-файла. Большинство СРК не умеют делать дельты между файлами, и бэкапят файл целиком. А те, кто умеют в subfile backup, говорят, что лучше это не включать :)

Полный бэкап этого сервера на файловом уровне занимал 1TB, инкрементальный - 600-800GB.

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

А те, кто умеют в subfile backup, говорят, что лучше это не включать

А сочетать с https://github.com/schnaader/precomp-cpp не пробовал?

Да там проприетарная СРК, к которой ничего не прикрутить. А компрессию с дедупликацией она и сама умела.

Да там

Значит не пробовал.

Большинство СРК не умеют делать дельты между файлами, и бэкапят файл целиком.

Ну ты понял.