Хранение файлов и бэкапы с контролем целостности

Или нет ничего лучше/надёжнее баш-портянки на хэши всех файлов и последующего рсунка?

А чем, собсна, не устраивает? Я хотел это посоветовать, но ты и сам себе неплохо посоветовал)

У тя алгоритм в три действия, реализуется чуть ли не в три строчки

Расскажи что за стратегия 3-2-1 раз пошла такая пьянка…

Можно ли в условных Borg настроить подобный алгоритм работы?

нет

Или нет ничего лучше/надёжнее баш-портянки на хэши всех файлов и последующего рсунка?

https://github.com/rfjakob/cshatag?tab=readme-ov-file#similar-tools

А чем, собсна, не устраивает?

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

Расскажи что за стратегия 3-2-1 раз пошла такая пьянка

3 копии, на 2 типах накопителей, из которых 1 далеко.

Собственно, одноплатник будет «жить» у родителей, а «кладовочный» системник с жёсткими дисками останется со мной.

1. BackupPC — проверенный временем софт из времён без systemd и файловых систем CoW. Очень надёжный софт, есть механизмы контроля целостности пула. В сочетании с ext4 под пулом достанется археологам будущего без изменений.

2. ZFS с send/receive и контрольными суммами — кондовый и надёжный вариант, данные в безопасности. Но держать это внешнее для ядра хозяйство может быть муторно. Есть хороший инструмент для инкрементальных реплик zrepl, где предусмотрели обход многих подводных граблей копирования.

3. Btrfs с send/receive, контрольными суммами, возможностями менять уровни RAID и количество накопителей в файловой системе онлайн, RAID1 любом количестве накопителей — отличный вариант. Проблемы с ней вы вряд ли встретите, а при наличии двух независимых реплик про отказ одной ФС можно даже не переживать.

избежать подсчёта хэшей всех файлов на моломощной железке с соответствующей скоростью

Вот бы это надо было делать раз в полгода)

Зачем портянки, у меня вот такие шорты, можно еще укоротить, если хочется

cat ~/bin/create-md5sum

#!/bin/bash

if [ -f md5sum.txt ]; then
    echo md5sum.txt already exists
    exit 1
fi

find -type f ! -wholename ./md5sum.txt -exec md5sum '{}' \; > md5sum.txt
echo md5sum.txt has been created

cat ~/bin/check-md5sum

#!/bin/bash

set -e

if [ $# -eq 0 ]
then
    md5sum --check --ignore-missing --quiet md5sum.txt
else
    grep "$1" md5sum.txt | md5sum --check --ignore-missing --quiet
fi

echo All files are correct

либо способы избежать подсчёта хэшей всех файлов

А как иначе вы собираетесь silent data corruption находить?

Вы планируете хранить одну копию? Если да, то это не бэкап, а не более чем копия данных по состоянию на dd.mm.yyyy.

Или нет ничего лучше/надёжнее баш-портянки на хэши всех файлов и последующего рсунка?

rsync сам умеет в подсчет чексумм.

BTRFS с send/receive

У зфс, которую я так понял ты уже используешь, тоже ведь есть сенд-ресив.

Тоже послушаю посижу, вариантов я так понимаю много.

Я для себя пока примерно наметил так - в зеркало добавить третий диск такого же размера, синкнуть, сделать ему детач. Подключить в условно-удаленном месте и добавить еще диск (получится клон первого зеркала) - и дальше гнать туда ресив снапшотов с некоторой периодичностью.

Насчёт как именно - пока сам ищу, есть вопросики. Например нужен ли обязательно канал связи или как-то можно снапшоты перетаскивать например на съёмном носителе?

А чем, собсна, не устраивает? Я хотел это посоветовать, но ты и сам себе неплохо посоветовал)

Если изменение файла было несакнционированное (сам попортил или оборудование сбойнуло) то рсинк с удовольствием затянет попорченный файл и в бэкап.

Насколько понимаю тут как раз удобны снапшоты и архивное хранение на некоторую глубину версий «назад» - при проверке можно откатиться на не испорченную версию.

Я для себя пока примерно наметил так - в зеркало добавить третий диск такого же размера, синкнуть, сделать ему детач. Подключить в условно-удаленном месте и добавить еще диск (получится клон первого зеркала) - и дальше гнать туда ресив снапшотов с некоторой периодичностью.

Это родит больше ошибок и граблей. Лучше:

1. Создать новую ФС для копий
2. Сделать ro снапшот исходной ФС
3. send <снапшот исходной ФС> | receive <новая ФС>

Справедливо и для одного хоста, и для разнесённых; и для ZFS, и для Btrfs. Так будут работать инкрементальные копии — для них нужен общий снапшот на источнике и получателе.

Создать новую ФС для копий

Вот этот вариант с подключением диска в зеркало читал оф. доке - только немного неправильно написал, не детач, а split. Вот источник: Creating a New Pool By Splitting a Mirrored ZFS Storage Pool

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

например я же могу в склонированный таким образом пул слать ресивом снепшоты

Можно, но инкремент без пересылки всей ФС целиком будет только если заранее создать снапшот, который потом окажется на всех копиях.

Мне не нравятся около-деструктивные операции с подключением-разделением накопителей. Send на новую ФС даст тот же результат без риска отстрелить ногу. Ещё и сразу uuid будут разные — можно будет подключать все ФС на один хост безопасно.

с помощью par2 дополнить файлами восстановления.
в диру к имеющимся файлам докидывает свои файлики, в которых не только хеш-подпись файла для проверки целостности, но и коды Рида-Соломона для восстановления целостности в случае потери байтиков (проценты восстановимых потерь регулируется).
тестировать и восстанавливать через него же.
можно сделать поверх любой системы. хранить в любом виде на любой фс - это просто исчо файлики.
идеально для архивов фоток.

если планируется упаковка системы в один сжатый файл холодного архива, то использовать rar5, там есть и сжатие и коды восстановления и поддержка прав и юзеров unix.
если бекапится планируется корневая фс то паковать в squashfs и дополнять par2.

ССД для бекапов не использовать. не для ентого дела он создан…

Можно, но инкремент без пересылки всей ФС целиком будет только если заранее создать снапшот, который потом окажется на всех копиях.

Ну вроде понятно, спасибо. Надо такие вещи руками пару раз сделать, тогда будет полное понимание. Я пока что со снепшотами только в самых простых случаях сталкивался (просто на том же пуле без пересылки).

Мне не нравятся около-деструктивные операции с подключением-разделением накопителей.

Это да. Меня немного успокаивает что описано в доке, а не просто где-то на просторах. Так же знаю (и тут тоже читал) что у некоторых админов популярно «бэкапить» перетыкая диск в зеркало - т.е. циклически менять диски, держа один на полке отключенным. Но это, кмк, перебор уже - считаю состояние массива в ребилде суб-аварийной и лучше в него лишний раз без надобности систему не вводить)

сделать копию на внешний диск, проверить её и успокоиться на месяц. Пару раз в год залить данные на «кладовочный» системник.

А restic не подходит для этого? https://restic.readthedocs.io/en/latest/045_working_with_repos.html#checking-integrity-and-consistency

проверить целостность данных на внутреннем диске

Целостность относительно чего? Файловая система с чексуммами нужна? Она ж, вроде, не спасёт от того, что твой Photoshop побьёт файл при сохранении. А ты и не узнаешь об этом, пока не откроешь картинку.

Restic шикарен (borg, наверное, тоже, но я использую restic). Рекомендую добавить его в схему, как один из элементов 3-2-1.

Restic шикарен

Go 99.8%

🔥

Есть ещё Rustic. Угадай на чём написан

Если изменение файла было несакнционированное (сам попортил или оборудование сбойнуло) то рсинк с удовольствием затянет попорченный файл и в бэкап

rsync очень тонко настраивается на очень много какое поведение. А рсинк под управлением баша легко настраивается на ВООБЩЕ ЛЮБОЕ поведение. Подозреваю, что ни одно готовое решение для бекапов даже рядом не стояло в этом смысле

rsync очень

хорошо загружает процы на источнике и получателе, обсчитывая на обоих контрольные суммы каждый проход! Зато patrol read для всей реплики бесплатно сверху.

Вы планируете хранить одну копию? Если да, то это не бэкап, а не более чем копия данных по состоянию на dd.mm.yyyy

Да, планирую хранить текущий срез файлов на двух географически разнесенных машинах и внешнем диске

У зфс, которую я так понял ты уже используешь, тоже ведь есть сенд-ресив.

Есть, но нет желания заталкивать на арм-одноплатник

Идея с архивами интересная, спасибо.

ССД для бекапов не использовать. не для ентого дела он создан…

Знаю, но они на руках уже есть. Внешний буду подключать сильно чаще саморазряда ячеек.

Знаю, но они на руках уже есть. Внешний буду подключать сильно чаще саморазряда ячеек.

Дело не в саморазряде, а в мгновенной непредсказуемой смерти. У HDD такое тоже случается, но реже.

Дело не в саморазряде, а в мгновенной непредсказуемой смерти.

Из-за этого у меня почти все старые SSD от интела и микрона - они хоть в рид-онли уходят, если верить людям в интернете (сам, к счастью, ещё не проверял).

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

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

Может и не считать, смотря как тебе надо. Странная претензия