Чии, ты наверное встречала людей, утверждающих что бекапы делать надо, но которые при вопросах как именно это делают тут же предлагают их не делать (определиться с тем что важно и не париться про остальное), доверяют сторонним ресурсам (все фотографии в соцсетях, а документы в почте), и вообще они все потеряли когда винт умер и не огорчились.А есть ли тут те, кто ценит память о том, в чем проводит заметную часть своей жизни, кто понимает, что именно это будет заменой бабушкиным фотоальбомам/документам/наградам для себя и внуков? Как вы, сделав бекапы, удостоверяетесь, что все цело в рабочей сейчас копии? Никто нигде внятно не описывает как поступать в типичном случае (бекап не первой свежести (а свежесть при скорости честного чтения обычного жёсткого диска с много терабайт никак не может быть быстрее чем за сутки)+ копия данных, спасённая из умирающего диска с непонятными состояниями повреждений и изменений), существуют ли автоматические инструменты для слияния бекапов, скажем, интегрирующие в себе автоматическую проверку валидности основных форматов медиа? Оптимален ли такой подход (основная копия, пара лежащих на полке и хранящихся в запакованном виде в сети), с периодическим ручным восстановлением раз в 5 лет после сбоев, или есть более эффективные до деньгам и усилиям на условный терабайт подходы?
>>206529Записываю резервные копии данных на DVD-диски по мере их поступления. Иногда, достаю их и сравниваю хеш-суммы файлов с помощью программы HashMyFiles.Особо важные файлы храню на "облаках" в зашифрованных архивах.Данных не очень много, поэтому этот способ вполне себя оправдывает.
Обычно все проблемы бэкапов сводятся лишь к двум: деньгам и лени. И если лень преодолеть поможет софт, то покупать болванки и жёсткие диски со временем всё-таки придётся. Вот у меня текстовые документы уже лет десять переехали с дискет. Коллекция картинок со временем переехала на терабайтник. А есть ведь ещё музыка, и видео. Про снимки системного диска вообще молчу. Их никакой носитель информации не вместит при всём сжатии и оптимизации за счёт пропуса повторяющихся файлов. Только на болванки. Причём многоразовые не подойдут, ведь ты не знаешь снимок какой давности тебе понадобится.
Borg + rclone. Одна локальная копия, несколько на халявные облака (за тем rclone). Трафа и места в таком раскладе меньше всего потому на нем остановился.
>>206534>Данных не очень многоЭто критический момент - десяток гигабайт несложно держать на телефоне, в бесплатных облаках, можно держать всегда в архиве и обновлять на месте. А вот с большим количеством интенсивно используемого так не сделаешь.>>206567>покупать болванки и жёсткие диски со временем всё-таки придётсяУ меня на 2ТБ данных суммарно уже по 9 и 11 ТБ бекапов в снапшотах (один - вручную копированием и дедупликацией при помощи hardlink, второй borgbackup-ом), один отдельный холодный архив с томами четности, и он же залит в облако.Это все откладывает, а не решает проблему: сама рабочая копия данных в непонятно каком состоянии, все контрольные суммы бекапов покрывают лишь бекапы. Нет никакого контроля за тем что диск или флешка возвращает то что на него записано кроме той что в самом контроллере, но даже если принять что он всегда фейлится в случае если считать данные невозможно, все инструменты для бекапов позволяют лишь развернуть копию, но никак не облегчают задачу слияния копий.
>>206534
>Данных не очень много
Это критический момент - десяток гигабайт несложно держать на телефоне, в бесплатных облаках, можно держать всегда в архиве и обновлять на месте. А вот с большим количеством интенсивно используемого так не сделаешь.>>206567
>покупать болванки и жёсткие диски со временем всё-таки придётся
У меня на 2ТБ данных суммарно уже по 9 и 11 ТБ бекапов в снапшотах (один - вручную копированием и дедупликацией при помощи hardlink, второй borgbackup-ом), один отдельный холодный архив с томами четности, и он же залит в облако.Это все откладывает, а не решает проблему: сама рабочая копия данных в непонятно каком состоянии, все контрольные суммы бекапов покрывают лишь бекапы. Нет никакого контроля за тем что диск или флешка возвращает то что на него записано кроме той что в самом контроллере, но даже если принять что он всегда фейлится в случае если считать данные невозможно, все инструменты для бекапов позволяют лишь развернуть копию, но никак не облегчают задачу слияния копий.
С большим, по настоящему большим количеством ценных данных бесплатно уже никак. Иметь только локальный бекап небезопасно, пожары и т.п.
>>206567>снимки системного диска>ты не знаешь снимок какой давности тебе понадобится.Последений записанный. Нахрена мне вообще другие снимки системного диска? В кэше браузера за второй квартал прошлого года покопаться?
>>206567
>снимки системного диска>ты не знаешь снимок какой давности тебе понадобится.
Последений записанный. Нахрена мне вообще другие снимки системного диска? В кэше браузера за второй квартал прошлого года покопаться?
>>206572>все инструменты для бекапов позволяют лишь развернуть копию, но никак не облегчают задачу слияния копий.Ычую.Я думаю, что при упаковке данных в архив можно давать ему имя с указанием типа хранимых данных, их тематики, даты создания, номер копии (бекап же не на один носитель), подсказку для пароля, и прочих атрибутов, по которому вы ищете файлы в папках — всему этому можно присвоить буквенные обозначения.Далее, вы просто будете знать, где искать требуемый файл.Чем-то похож на систему хранения книг в библиотеке.Хотя, да, требует доработки.>>206573>Иметь только локальный бекап небезопасно, пожары и т.п.Если есть возможность, то можно увезти копии бекапов на дачу — записанные диски с зашифрованными файлами никто воровать не будет. При должной организации именования копий можно будет легко найти замену утерянным.
>>206572
>все инструменты для бекапов позволяют лишь развернуть копию, но никак не облегчают задачу слияния копий.
Ычую.Я думаю, что при упаковке данных в архив можно давать ему имя с указанием типа хранимых данных, их тематики, даты создания, номер копии (бекап же не на один носитель), подсказку для пароля, и прочих атрибутов, по которому вы ищете файлы в папках — всему этому можно присвоить буквенные обозначения.Далее, вы просто будете знать, где искать требуемый файл.Чем-то похож на систему хранения книг в библиотеке.Хотя, да, требует доработки.>>206573
>Иметь только локальный бекап небезопасно, пожары и т.п.
Если есть возможность, то можно увезти копии бекапов на дачу — записанные диски с зашифрованными файлами никто воровать не будет. При должной организации именования копий можно будет легко найти замену утерянным.
rsync с разных компьютеров друг на друга. На проблему silent data corruption забил. И без нее лезть в бекапы приходится пару раз в год.
>>206579Вполне могут, нарики и алкашня в голоде неразбочивы. В остальном согласен, значительно повышает сохранность данных разнос хотя бы в два разных места.
>>206582Надо закопать на пустыре, может вырастет Бакапное Дерево.
>>206574Ни разу не встречался с ситуацией когда последние снимки не подходят? Ну надо же. А я знаю людей, которым ни разу бэкапы вовсе не понадобились. Они всех кто их делает тоже люто презирают. Тебя в том числе. Так что не надо так уничижительно-пренебрежительно.В истории браузера за прошедшие месяцы, я к слову, тоже нередко копаюсь. И история адресной строки у меня по максимальной. Закладок оver9000, вкладок около сотни открытых. Всем активно пользуюсь. Так что плохой пример.
>>206574> Нахрена мне вообще другие снимки системного диска? Потому что в лучшем случае повреждение будет замечено в момент когда этот самый последний снапшот делается, в худшем - не будет замечено вообще. Это если не брать случайного затирания или удаления важных файлов.>>206573> бесплатно уже никак. Ну диски денег стоят в любом случае. Но даже для неизменного количества места со временем снапшоты будут только увеличиваться, если нет возможности контролировать их целостность.Интересно, а есть ли нечто, позволяющее проверять целостность медиафайлов хотя бы? Под картинки например можно свелосипедить э find / -name *.jpg -exec jpeginfo {} и ловить сообщения об ошибках, но нет ли чего-то подобного под все основные типы медиафайлов, архивов и прочего поддающегося проверкам?
>>206574
> Нахрена мне вообще другие снимки системного диска?
Потому что в лучшем случае повреждение будет замечено в момент когда этот самый последний снапшот делается, в худшем - не будет замечено вообще. Это если не брать случайного затирания или удаления важных файлов.>>206573
> бесплатно уже никак.
Ну диски денег стоят в любом случае. Но даже для неизменного количества места со временем снапшоты будут только увеличиваться, если нет возможности контролировать их целостность.
Интересно, а есть ли нечто, позволяющее проверять целостность медиафайлов хотя бы? Под картинки например можно свелосипедить э find / -name *.jpg -exec jpeginfo {} и ловить сообщения об ошибках, но нет ли чего-то подобного под все основные типы медиафайлов, архивов и прочего поддающегося проверкам?
Mediainfo помечает битые (на моем опыте ошибки интернетов или банальная недокачка) видеофайлы как truncated. Насчет аудио не знаю, не попадалось.
>>206529>как поступать в типичном случае (бекап не первой свежестиИзбегать такой ситуации. Автоматизировать бэкапы, не делать каждый раз полную копию. Бэкапов должно быть больше одного, и при этом как минимум один должен быть свежим, а второй - наоборот, постарше. Нормальная бэкапилка (тот же виим) будет записывать чексуммы для сбэкапленного и сможет потом по ним проверять целостность.Бесплатный вариант - бэкапить рсинком на zfs, делать снапшоты, со снапшотов потом можно писать на ленту. Всё это элементарно автоматизируется руками.
>>206529
>как поступать в типичном случае (бекап не первой свежести
Избегать такой ситуации. Автоматизировать бэкапы, не делать каждый раз полную копию. Бэкапов должно быть больше одного, и при этом как минимум один должен быть свежим, а второй - наоборот, постарше. Нормальная бэкапилка (тот же виим) будет записывать чексуммы для сбэкапленного и сможет потом по ним проверять целостность.
Бесплатный вариант - бэкапить рсинком на zfs, делать снапшоты, со снапшотов потом можно писать на ленту. Всё это элементарно автоматизируется руками.
>>206771О, добавлю в копилку к jpeginfo. Было бы здорово интегрировать в один скрипт чекеры сразу всех распространенных типов медиа и архивов...>>206778Это все очевидно и не то.>Бэкапов должно быть больше одного, Уже.>будет записывать чексуммы для сбэкапленногоДа, для сбекапленного. Но не для рабочей копии, в которой она не сможет отличить изменения чексумм от повреждений от валидных изменений.>Всё это элементарно автоматизируется руками.Это, увы garbage in - garbage out, так как rsync по-умолчанию будет смотреть на даты изменения файлов и размер, но не изменение содержимого. Распаковка автосгенерированного архива с фиксированной датой в 1.01.1980, например, но с разным содержимым останется незамеченной, а это типичный случай для прошивок андроида.А честное отслеживание изменений не делается быстрее чем чтение содержимого всех файлов на диске.В идеале видится нечто вроде zfs, но интегрированное в систему из коробки и могущее плавно деградировать на повреждении единственного диска, zfs все же больше про бесперебойность 24/7, чем на типичный сценарий где компьютер ежедневно выключается, или кривое действие пользователя может выжрать доступную память. Ближе всего видится к желаемому dm-verity, но он работает только ридонли.
>>206771О, добавлю в копилку к jpeginfo. Было бы здорово интегрировать в один скрипт чекеры сразу всех распространенных типов медиа и архивов...>>206778Это все очевидно и не то.
>Бэкапов должно быть больше одного,
Уже.
>будет записывать чексуммы для сбэкапленного
Да, для сбекапленного. Но не для рабочей копии, в которой она не сможет отличить изменения чексумм от повреждений от валидных изменений.
>Всё это элементарно автоматизируется руками.
Это, увы garbage in - garbage out, так как rsync по-умолчанию будет смотреть на даты изменения файлов и размер, но не изменение содержимого. Распаковка автосгенерированного архива с фиксированной датой в 1.01.1980, например, но с разным содержимым останется незамеченной, а это типичный случай для прошивок андроида.А честное отслеживание изменений не делается быстрее чем чтение содержимого всех файлов на диске.В идеале видится нечто вроде zfs, но интегрированное в систему из коробки и могущее плавно деградировать на повреждении единственного диска, zfs все же больше про бесперебойность 24/7, чем на типичный сценарий где компьютер ежедневно выключается, или кривое действие пользователя может выжрать доступную память. Ближе всего видится к желаемому dm-verity, но он работает только ридонли.
>>206779Тогда я наверно не очень понимаю задачу. Если данные настолько важны, что есть 2 бэкапа + облако, то зачем держать их на одиночном диске, который рано или поздно побьётся а затем сдохнет? Почему сразу не положить их в хранилище, которое из коробки умеет проверять целостность данных при каждом доступе к ним?
>>206782>зачем держать их на одиночном дискеС хранилищем на zfs на отдельном железе попросту неудобно работать, с риском внести ошибки сбоями сети, и насколько я знаю, ее в десктопобельных линуксах не завезли из коробки, не говоря уже про винду. Ещё смущает наличие отдельного кеша, и его потенциального поведения если сработает OOM.
>>206782
>зачем держать их на одиночном диске
С хранилищем на zfs на отдельном железе попросту неудобно работать, с риском внести ошибки сбоями сети, и насколько я знаю, ее в десктопобельных линуксах не завезли из коробки, не говоря уже про винду. Ещё смущает наличие отдельного кеша, и его потенциального поведения если сработает OOM.
>>206782>Если данные настолько важны,Важность измеряется не только допустимой вероятностью потери всех данных, но и допустимой давностью потерянных изменений.
>Если данные настолько важны,
Важность измеряется не только допустимой вероятностью потери всех данных, но и допустимой давностью потерянных изменений.
- wakaba + futaba + futallaby -
