Страница пересобрана: 05:11 27.02.2019
[d | an-b-bro-fr-hr-l-m-med-mi-mu-ne-o-ph-r-s-sci-sp-tran-tv-x | bg-vg | au-tr | a-aa-c-fi-jp-rm-tan-to-vn | gf | azu-dn-hau-ls-ma-maid-me-mo-p-sos-t-w | misc-vnd | stat ]
[Burichan] [Futaba] [Gurochan] - [Архив - Каталог] [Главная]

[Назад]
Ответ
Файл: 1547562249394.png -(400 KB, 425x567, B6063obv.png)
400 No.206529  

Чии, ты наверное встречала людей, утверждающих что бекапы делать надо, но которые при вопросах как именно это делают тут же предлагают их не делать (определиться с тем что важно и не париться про остальное), доверяют сторонним ресурсам (все фотографии в соцсетях, а документы в почте), и вообще они все потеряли когда винт умер и не огорчились.
А есть ли тут те, кто ценит память о том, в чем проводит заметную часть своей жизни, кто понимает, что именно это будет заменой бабушкиным фотоальбомам/документам/наградам для себя и внуков? Как вы, сделав бекапы, удостоверяетесь, что все цело в рабочей сейчас копии? Никто нигде внятно не описывает как поступать в типичном случае (бекап не первой свежести (а свежесть при скорости честного чтения обычного жёсткого диска с много терабайт никак не может быть быстрее чем за сутки)+ копия данных, спасённая из умирающего диска с непонятными состояниями повреждений и изменений), существуют ли автоматические инструменты для слияния бекапов, скажем, интегрирующие в себе автоматическую проверку валидности основных форматов медиа? Оптимален ли такой подход (основная копия, пара лежащих на полке и хранящихся в запакованном виде в сети), с периодическим ручным восстановлением раз в 5 лет после сбоев, или есть более эффективные до деньгам и усилиям на условный терабайт подходы?

>> No.206534  

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

>> No.206567  

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

>> No.206569  
Файл: 1547640075096.jpg -(23 KB, 650x371, bankoboev.ru_oblako_na_nebe-650x371.jpg)
23
>> No.206570  

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

>> No.206572  

>>206534

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

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

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

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

>> No.206573  

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

>> No.206574  

>>206567

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

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

>> No.206579  

>>206572

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

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

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

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

>> No.206581  

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

>> No.206582  

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

>> No.206583  

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

>> No.206600  

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

>> No.206614  

>>206574

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

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

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

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

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

>> No.206771  

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

>> No.206778  

>>206529

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

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

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

>> No.206779  

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

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

Уже.

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

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

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

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

>> No.206782  

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

>> No.206783  

>>206782

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

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

>> No.207168  

>>206782

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

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



Удалить сообщение []
Пароль
[d | an-b-bro-fr-hr-l-m-med-mi-mu-ne-o-ph-r-s-sci-sp-tran-tv-x | bg-vg | au-tr | a-aa-c-fi-jp-rm-tan-to-vn | gf | azu-dn-hau-ls-ma-maid-me-mo-p-sos-t-w | misc-vnd | stat ]
[Burichan] [Futaba] [Gurochan] - [Архив - Каталог] [Главная]