>>206529
Записываю резервные копии данных на DVD-диски по мере их поступления. Иногда, достаю их и сравниваю хеш-суммы файлов с помощью программы HashMyFiles.
Особо важные файлы храню на "облаках" в зашифрованных архивах.
Данных не очень много, поэтому этот способ вполне себя оправдывает.

Обычно все проблемы бэкапов сводятся лишь к двум: деньгам и лени. И если лень преодолеть поможет софт, то покупать болванки и жёсткие диски со временем всё-таки придётся. Вот у меня текстовые документы уже лет десять переехали с дискет. Коллекция картинок со временем переехала на терабайтник. А есть ведь ещё музыка, и видео. Про снимки системного диска вообще молчу. Их никакой носитель информации не вместит при всём сжатии и оптимизации за счёт пропуса повторяющихся файлов. Только на болванки. Причём многоразовые не подойдут, ведь ты не знаешь снимок какой давности тебе понадобится.

Borg + rclone. Одна локальная копия, несколько на халявные облака (за тем rclone). Трафа и места в таком раскладе меньше всего потому на нем остановился.

>>206534

>Данных не очень много

Это критический момент - десяток гигабайт несложно держать на телефоне, в бесплатных облаках, можно держать всегда в архиве и обновлять на месте. А вот с большим количеством интенсивно используемого так не сделаешь.
>>206567

>покупать болванки и жёсткие диски со временем всё-таки придётся

У меня на 2ТБ данных суммарно уже по 9 и 11 ТБ бекапов в снапшотах (один - вручную копированием и дедупликацией при помощи hardlink, второй borgbackup-ом), один отдельный холодный архив с томами четности, и он же залит в облако.
Это все откладывает, а не решает проблему: сама рабочая копия данных в непонятно каком состоянии, все контрольные суммы бекапов покрывают лишь бекапы. Нет никакого контроля за тем что диск или флешка возвращает то что на него записано кроме той что в самом контроллере, но даже если принять что он всегда фейлится в случае если считать данные невозможно, все инструменты для бекапов позволяют лишь развернуть копию, но никак не облегчают задачу слияния копий.

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

>>206567

>снимки системного диска
>ты не знаешь снимок какой давности тебе понадобится.

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

>>206572

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

Ычую.
Я думаю, что при упаковке данных в архив можно давать ему имя с указанием типа хранимых данных, их тематики, даты создания, номер копии (бекап же не на один носитель), подсказку для пароля, и прочих атрибутов, по которому вы ищете файлы в папках — всему этому можно присвоить буквенные обозначения.
Далее, вы просто будете знать, где искать требуемый файл.
Чем-то похож на систему хранения книг в библиотеке.
Хотя, да, требует доработки.
>>206573

>Иметь только локальный бекап небезопасно, пожары и т.п.

Если есть возможность, то можно увезти копии бекапов на дачу — записанные диски с зашифрованными файлами никто воровать не будет. При должной организации именования копий можно будет легко найти замену утерянным.

rsync с разных компьютеров друг на друга. На проблему silent data corruption забил. И без нее лезть в бекапы приходится пару раз в год.

>>206579
Вполне могут, нарики и алкашня в голоде неразбочивы. В остальном согласен, значительно повышает сохранность данных разнос хотя бы в два разных места.

>>206582
Надо закопать на пустыре, может вырастет Бакапное Дерево.

>>206574
Ни разу не встречался с ситуацией когда последние снимки не подходят? Ну надо же. А я знаю людей, которым ни разу бэкапы вовсе не понадобились. Они всех кто их делает тоже люто презирают. Тебя в том числе. Так что не надо так уничижительно-пренебрежительно.
В истории браузера за прошедшие месяцы, я к слову, тоже нередко копаюсь. И история адресной строки у меня по максимальной. Закладок оver9000, вкладок около сотни открытых. Всем активно пользуюсь. Так что плохой пример.

>>206574

> Нахрена мне вообще другие снимки системного диска?

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

> бесплатно уже никак.

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

Интересно, а есть ли нечто, позволяющее проверять целостность медиафайлов хотя бы? Под картинки например можно свелосипедить э find / -name *.jpg -exec jpeginfo {} и ловить сообщения об ошибках, но нет ли чего-то подобного под все основные типы медиафайлов, архивов и прочего поддающегося проверкам?

Mediainfo помечает битые (на моем опыте ошибки интернетов или банальная недокачка) видеофайлы как truncated. Насчет аудио не знаю, не попадалось.

>>206529

>как поступать в типичном случае (бекап не первой свежести

Избегать такой ситуации. Автоматизировать бэкапы, не делать каждый раз полную копию. Бэкапов должно быть больше одного, и при этом как минимум один должен быть свежим, а второй - наоборот, постарше.
Нормальная бэкапилка (тот же виим) будет записывать чексуммы для сбэкапленного и сможет потом по ним проверять целостность.

Бесплатный вариант - бэкапить рсинком на zfs, делать снапшоты, со снапшотов потом можно писать на ленту. Всё это элементарно автоматизируется руками.

>>206771
О, добавлю в копилку к jpeginfo. Было бы здорово интегрировать в один скрипт чекеры сразу всех распространенных типов медиа и архивов...
>>206778
Это все очевидно и не то.

>Бэкапов должно быть больше одного,

Уже.

>будет записывать чексуммы для сбэкапленного

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

>Всё это элементарно автоматизируется руками.

Это, увы garbage in - garbage out, так как rsync по-умолчанию будет смотреть на даты изменения файлов и размер, но не изменение содержимого. Распаковка автосгенерированного архива с фиксированной датой в 1.01.1980, например, но с разным содержимым останется незамеченной, а это типичный случай для прошивок андроида.
А честное отслеживание изменений не делается быстрее чем чтение содержимого всех файлов на диске.
В идеале видится нечто вроде zfs, но интегрированное в систему из коробки и могущее плавно деградировать на повреждении единственного диска, zfs все же больше про бесперебойность 24/7, чем на типичный сценарий где компьютер ежедневно выключается, или кривое действие пользователя может выжрать доступную память. Ближе всего видится к желаемому dm-verity, но он работает только ридонли.

>>206779
Тогда я наверно не очень понимаю задачу. Если данные настолько важны, что есть 2 бэкапа + облако, то зачем держать их на одиночном диске, который рано или поздно побьётся а затем сдохнет? Почему сразу не положить их в хранилище, которое из коробки умеет проверять целостность данных при каждом доступе к ним?

>>206782

>зачем держать их на одиночном диске

С хранилищем на zfs на отдельном железе попросту неудобно работать, с риском внести ошибки сбоями сети, и насколько я знаю, ее в десктопобельных линуксах не завезли из коробки, не говоря уже про винду. Ещё смущает наличие отдельного кеша, и его потенциального поведения если сработает OOM.

>>206782

>Если данные настолько важны,

Важность измеряется не только допустимой вероятностью потери всех данных, но и допустимой давностью потерянных изменений.