>и с контролем версий

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

>>191114
Для защиты от повреждений можно par2 использовать, оно просто рядом создает файлы с данными для восстановления, если что побилось, так что систему контроля версий можно любую использовать.

>>191115
Ты часто модифицируешь фильмы и образы с играми?
>>191117
Par2 это не совсем подходящий вариант для архивирования просто потому что диск может навернуться целиком. Следовательно, нужно иметь несколько дисков.

>>191120
Тогда тебе просто нужно распихать все файлы, включая файлы с данными для восстановления, по разным дискм так, чтобы при потери одного или нескольких дисков данные все равно можно было восстановить за счет избыточности на других дисках.

>>191121
Зачем данные для восстановления, если есть несколько копий это уже избыточные данные из которых можно восстанавливать?

>>191122
Данных для восстановления может быть меньше чем исходных данных. Но если тебе нужен только факт изменения файлов то почему бы не воспользоваться каким-нибудь md5sum?

Есть диск А и диск Б. Если диск А упал с полки и закатился в микроволновку, то все данные что на нем были можно считать потерянными, избыточность тут не поможет. А если его только немного покорраптило, то данные можно восстановить с диска Б. Если оба диска покорраптило, то оба диска можно использовать как избыточные данные для восстановления друг-друга. Значит, хранить данные для восстановления на самих дисках это уже избыточная избыточность.

>>191125
par2 со 100% избыточностью будет работать именно так. Но если у тебя дисков 3 и больше, то можно обойтись меньшей избыточностью.

В студенческие годы, для архивации мультимедийных данных в моём окружении был популярен метод «записать на болванки и раздарить друзьям». У кого-нибудь копия да останется.

>>191127
Сейчас для этого, кажется, есть IPFS. Я не уверен как именно там все работает, но вроде идея в том что ты заливаешь файл, считаешь его хеши и получаешь список других нод где есть такие же хеши.

>>191130
Там каждый чанк индексируется отдельно и если у кого-то есть заголовок это еще не значит что у него есть все.

Для файлов - RAID 1+0. Просто, эффективно по IO и легко скейлится в любую топологию избыточности и партитированности, знай только докидывай спейры по мере задействования существующих и выбивании умерших.

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

Хочу сконвертировать все картинки и фотографии в webp c -lossless и -q 100, а все короткие видео сохраненные с ютуба в webm с ffmpeg -i filename.old -c:v libvpx-vp9 -b:v 0 filename.webm. Какие подводные камни?

>>191136
CPU боттлнек. Но ты сам скоро заметишь.

>>191136
Не мелочись, съешь сникерс AV1.
>>191137
Про Vp9 не уверен, но h265/4 и другие вполне можно на gpu перекодировать, и подобрав флаги, это даже будет иметь смысл.

В принципе таким же хочу уже пару лет заняться, но руки не доходят.
Новерь-сама, ты ведь поддержишь меня webp?

>>191114
У меня есть "горячее" хранилище на ссд и "холодное" на рейде из hdd. Когда приходит время добавить новые файлы в горячее и сделать бэкап, я запускаю скрипт на питуне, который считает хэши(xxhash64), сверяет их со списком, ищет дубликаты и т.д. После, я добавляю новые файлы в горячее хранилище и заново генерирую список хэшей. После этого архивирую 7зипом и перемещаю в холодное хранилище.

>>191136
Занимаемое место.

>>191136

> ffmpeg -i filename.old -c:v libvpx-vp9 -b:v 0 filename.webm

Размер, скорость и качество. Если хочешь размер заметно меньше и качество больше, чем у закодированного бы с libx264, вполне возможно придётся кодировать куда дольше, написав больше разных параметров и пойдя в два прохода. И деградация качества будет всё равно, что той libой кодируй, что этой.

> Хочу сконвертировать все картинки и фотографии в webp c -lossless и -q 100

Во-первых, стоит подумать об AVIF и JPEG XL, дающих заметно меньший размером результат. Во-вторых, добавить в параметры -m 6 -z 9. В-третьих, фотографии и картинки, которые конвертировать, они в PNG? — Если да, то оно эффект возымеет. Если в околоlossless JPEG, то не факт, может получиться больше размером. Не говоря уж о JPEGах, пожатых сильно с потерями.

>>191138
На чаны H.265 совсем не запостишь, оно не поддерживается популярными браузерами.

> webp

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

>>191141

>На чаны H.265 совсем не запостишь, оно не поддерживается популярными браузерами.

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

>В остальном, есть более эффективное, готовящееся ему на замену.
>WebP

И это учитывая, что этот же самый webp до конца не поддерживается?
AVIF выглядит интересно, хотя бы из-за своего родственника AV1. И более интересно, как у него со временем перекодирования - один час или три будет одна картинка обрабатываться? Возможно и JPEX XL не достоин шакальной предвзятости.

>>191143
WebP не поддерживается кучей сайтов для публикации.
Современные браузеры поддерживают WebP. Paint позволяет сохранять картинки в WebP, Винда позволяет из коробки их читать, если они переименованы в .жыпег, не говоря уж о других системах. C современным софтом серьёзных проблем нет.

> Возможно и JPEG XL не достоин шакальной предвзятости

Название не нравится?

>>191139
Паковать в 7z имеет смысл только текстовые файлы, ведь архивирование добавляет угрозу того что малейшее повреждение может покорраптить все содержимое, так?

>>191148
Да, наверное. Я пакую ради шифрования и удобства. Это глупо конечно, я потом откажусь от этой практики.

Если хочется https://en.wikipedia.org/wiki/Generation_loss избѣжать, то тогда:

① PNG надо перегонять в lossless WebP без внесения потерь (а затѣмъ можно перегнать и въ lossless JPEG XL, когда тот начнёт широко поддерживаться; но лучше дѣлать это только для тѣхъ случаевъ, когда результатъ окажется реально меньше по объёму, чѣмъ въ WebP, а это случается не всегда).

② JPEG надо перегонять в JPEG XL без внесения потерь (у кодировщика есть такой режим).

③ Использовать lossy WebP (сейчас), использовать AVIF или сжатие в JPEG XL с потерями (когда то и другое начнёт поддерживаться) слѣдуетъ только как конечный шаг публикации въ тѣхъ случаяхъ, когда без доужатия файл по объёму не подходит. (Напримѣръ, прилагаемый файл не помѣстится на имиджбордах с маломегабайтным ограничением объёма файлов даже послѣ переужатия в lossless WebP, так как его представление https://014chan.org/d/src/161971048169.webp всё ещё будет близко к восьми мегабайтам по объёму.) И чѣмъ сильнѣе сжимается файл, тѣмъ лучше использовать AVIF вмѣсто JPEG XL (особенно когда в файле ужé битов меньше, чѣмъ пикселов).

>>191136
для снятого на камеру лучше подходит hevc, для всего остального - av1. с артинками проблема. если место есть, то лучше обычный жпег, если печешься про место то шебп либо жпег 2000. насчёт бекапа то я по старинке раз в три месяца копирую все полезности на три диска и сую их в тёмный ящик