Адрес для входа в РФ: exler.world
Никогда такого не было, и вот опять!
21.05.2024 10:00
15147
Комментарии (116)
История из серии "Никогда такого, и вот опять, или Зачем мне бэкапы, я все храню в облаке".
Австралийский пенсионный фонд UniSuper, управляющий средствами на сумму 135 миллиардов долларов и насчитывающий 647 000 членов, держал свой аккаунт в Google Cloud.
2 мая аккаунт UniSuper в Google Cloud был непонятным образом удален. Причем, чтобы уж для гарантии, удален вместе со всеми резервными копиями, которые хранились там же. Не осталось ничего. К счастью, в UniSuper работают грамотные админы, и они держали резервные копии у других провайдеров. Но при этом процесс полного восстановления всех сервисов компании занял аж две недели - только с 15 мая все заработало в полном объеме.
8 мая на сайте компании было опубликовано "Совместное заявление генерального директора UniSuper Питера Чуна и генерального директора Google Cloud Томаса Куриана". Томас Куриан подтвердил, что никогда такого не было, и вот опять!
Генеральный директор Google Cloud Томас Куриан подтвердил, что сбой возник в результате беспрецедентной последовательности событий, когда непреднамеренная неправильная конфигурация во время предоставления услуг UniSuper Private Cloud в конечном итоге привела к удалению подписки UniSuper Private Cloud. Это единичный, "единственный в своем роде" случай, который никогда ранее не происходил ни с одним из клиентов Google Cloud по всему миру. Этого не должно было произойти. Google Cloud выявила события, которые привели к сбою, и приняла меры, чтобы подобное не повторилось".
Причем выяснилось, что UniSuper хранили свои данные в Private Cloud Google в двух разных географических регионах, и это не помогло. Также не сработали средства защиты Google Cloud, не позволяющие удалить аккаунт.
Ну, в общем, хорошо то, что хорошо заканчивается, но это лишнее напоминание о том, что не стоит рассматривать хранение данных в облаке как панацею. Даже если вы имеете дело с такими крупняками, как Google, Amazon или Microsoft. Сбои бывают всегда и везде.
Лично я, например, еженедельно всю мою терабайтную папку основного облачного сервиса копирую на NAS. Также она периодически копируется на отдельные диски через док-станцию.
Войдите, чтобы оставить комментарий.
Отлично зная, как работают в Австралии, вообще не удивлюсь, если 10 дней из этих 14 соответствующие инженеры ожидали какого-нить подтверджения от уехавшего отдыхать менеджера. Маньяна здесь в целом такая, что, возможно, и Испании фору даст. No worries mate, take it easy.
Была с бэкапами прикольная история лет 25 назад.
Я тогда работал в израильском отделении Интела, и для бэкапов у нас использовали магнитные ленты. Кассеты с этими лентами лежали в герметично закрытом хранилище, а когда надо было бекап прочитать или записать, специальный робот (не человекообразный, а автомат такой) приносил кассету со стеллажа и ставил в устройство, к которому можно было подключиться извне.
Бэкапы делались регулярно, все отлично.
И вот как-то раз соседняя с моей группа получила баг, относящийся к версии программы двухлетней давности (на более поздних версиях соответствующая фича уже не существовала). Естественно, группа заказала восстановление этой версии с бекапа. Получили подтверждение, соединились с устройством чтения... И тут вдруг с этого устройства пошел не бэкап, а поток бессмысленный байтов. Что за нафиг?!
Попробовали другой бекап - опять мусор идет.
Обратились в саппорт. Те соответственно распечатали хранилище, и - обана! - оказалось, что робот, который носит кассеты, давно поломался, и все бекапы уже неизвестно сколько лет записываются на одну и ту же кассету, которая в момент поломки имела несчастье оказаться в устройстве доступа.
Думаете, саппорт прошляпил сигнал о поломке? А вот и нет! При любой неполадке на специальной панели загорается красная лампочка. Только эта лампочка, как выяснилось, перегорела тоже неизвестно сколько лет назад...
Ну, в общем, был большой скандал, систему бекапов то ли починили, то ли заменили на что-то другое, за давностью лет не помню. А что с багом двухлетней давности, спросите?
Все решилось просто. Один из разработчиков в той группе оказался очень ленивый и не очень производительный, и у него на лаптопе случайно оказалась среди прочего никогда не чистившегося мусора версия исходников примерно тех самых времен. Ее собрали, попробовали баг воспроизвести - и получилось! Баг починили, как-то скомпоновали рабочую версию, СДЕЛАЛИ БЭКАП по ново-утвержденной технологии, и передали версию заказчику.
Группа получила конфеты и плюшки, саппорт получил... ну... плюху.
А вы - облако-шмоблако. Только хардкор!
А кроме шуток - бекапы и вообще любые долго хранимые данные надо скрабить. То есть регулярно считывать и проверять, хотя бы контрольную сумму. И при несовпадении делать новую реплику с исправной (и поэтому реплик одних и тех же данных всегда должно быть хотя бы три, а лучше больше). Потому что кроме горелых роботов бывают еще альфа-частицы и прочая дрянь, из-за которой записанные данные через несколько месяцев непременно оказываются испорчены.
Это хорошо знают все, кто пишут код облаков. Как любил повторять мой босс, на твоем домашнем компьютере бит может флипнуться раз в пять лет, а в нашем дата-центре, где счет серверов идет на сотни и тысячи, биты флипаются каждый день, и далеко не по одному.
Я тогда работал в израильском отделении Интела, и для бэкапов у нас использовали магнитные ленты. Кассеты с этими лентами лежали в герметично закрытом хранилище, а когда надо было бекап прочитать или записать, специальный робот (не человекообразный, а автомат такой) приносил кассету со стеллажа и ставил в устройство, к которому можно было подключиться извне.
Бэкапы делались регулярно, все отлично.
И вот как-то раз соседняя с моей группа получила баг, относящийся к версии программы двухлетней давности (на более поздних версиях соответствующая фича уже не существовала). Естественно, группа заказала восстановление этой версии с бекапа. Получили подтверждение, соединились с устройством чтения... И тут вдруг с этого устройства пошел не бэкап, а поток бессмысленный байтов. Что за нафиг?!
Попробовали другой бекап - опять мусор идет.
Обратились в саппорт. Те соответственно распечатали хранилище, и - обана! - оказалось, что робот, который носит кассеты, давно поломался, и все бекапы уже неизвестно сколько лет записываются на одну и ту же кассету, которая в момент поломки имела несчастье оказаться в устройстве доступа.
Думаете, саппорт прошляпил сигнал о поломке? А вот и нет! При любой неполадке на специальной панели загорается красная лампочка. Только эта лампочка, как выяснилось, перегорела тоже неизвестно сколько лет назад...
Ну, в общем, был большой скандал, систему бекапов то ли починили, то ли заменили на что-то другое, за давностью лет не помню. А что с багом двухлетней давности, спросите?
Все решилось просто. Один из разработчиков в той группе оказался очень ленивый и не очень производительный, и у него на лаптопе случайно оказалась среди прочего никогда не чистившегося мусора версия исходников примерно тех самых времен. Ее собрали, попробовали баг воспроизвести - и получилось! Баг починили, как-то скомпоновали рабочую версию, СДЕЛАЛИ БЭКАП по ново-утвержденной технологии, и передали версию заказчику.
Группа получила конфеты и плюшки, саппорт получил... ну... плюху.
А вы - облако-шмоблако. Только хардкор!
А кроме шуток - бекапы и вообще любые долго хранимые данные надо скрабить. То есть регулярно считывать и проверять, хотя бы контрольную сумму. И при несовпадении делать новую реплику с исправной (и поэтому реплик одних и тех же данных всегда должно быть хотя бы три, а лучше больше). Потому что кроме горелых роботов бывают еще альфа-частицы и прочая дрянь, из-за которой записанные данные через несколько месяцев непременно оказываются испорчены.
Это хорошо знают все, кто пишут код облаков. Как любил повторять мой босс, на твоем домашнем компьютере бит может флипнуться раз в пять лет, а в нашем дата-центре, где счет серверов идет на сотни и тысячи, биты флипаются каждый день, и далеко не по одному.
В IT в области Disaster Recovery есть понятия RTO и RPO. И любая организация выстраивает свою DR стратегию исходя из этих параметров. И у серьезных организаций (например у банков) она исходит не просто из того что облако ляжет на какое-то время, а что оно вообще перестанет существовать (хотя имхо если это произойдет - отсутсвие бекапов будет наименьшей из проблем)
К чему я это - если у компании процесс восстановления занял 2 недели, то у них точно что-то не так с DR стратегией или 2 недели - это их RTO 😄
К чему я это - если у компании процесс восстановления занял 2 недели, то у них точно что-то не так с DR стратегией или 2 недели - это их RTO 😄
Кстати, про облака (или "хозяйке на заметку"). Тоже "никогда такого не было, и вот опять"... ))
Я всё храню в облаке и вполне доволен. Но я не австрийский пенсионный фонд...
Но я не австрийский пенсионный фонд
По большому счету крупняка только два - гугл и амазон. Почти случайно несколько недель назад мы копнули трэйс майкрософтовского облака - а там амазон.
Да, крупняка 2 - AWS и Azure, и только потом с большим отставанием гугл и все остальные
Почти случайно несколько недель назад мы копнули трэйс майкрософтовского облака - а там амазон.
Вы что-то напутали. Майкрософт гораздо более серьезный игрок на этом рынке.
Понанимали по квотам всякое... В наше время такого не было...
"Цепочка событий...". Какой-нибудь мелкий "Unosuper" Гомера Лопеса, семейной компании из двух человек, подал заявку на удаление аккаунта. Оператор, работающий за $16 долларов час, ошибся в одном символе, создавая внутренний workflow на удаление. Контроллер, подтверждающий такие таски, застукал в этот день жену с любовником и в прострации кликал все подряд - и пошло-поехало.
Да, один из крупнейших сбоев в Amazon S3 был вызван тем что интерн набрал неправильную команду
At 9:37AM PST, an authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended.
СЕПУЛЕНИЕ - вот выход!
А вот как проблему бэкапов решали создатели хранилища ядерных отходов. 10 тыщ лет, не хрен собачий.
Тыц
Тыц
сейсмологию, бомбардировки это решение не предусматривает
сейсмологию, бомбардировки это решение не предусматривает
сейсмологию, бомбардировки это решение не предусматривает
"Если в Гугле дать поиск по слову Гугл, то интернет сломается" (сериал "Техподдержка")
до сих пор есть сайт с кнопкой "Сделать все хорошо"
Помнится в 90-е была программа "Взлом интернета".
В облаках с аккоунтами может произойти случайная блокировка и ничего с этим не сделаешь. И никто не поможет (ну если только ты не размером с UniSuper). Новоявленный AI распознает там чего-то не того на свежезакаченной фотографии - и пермантеный бан обеспечен.
Я, не смотря на платный office 365, еще имею свой собственный облачный (ну как облачный - vps на линуксе у провайдера) сервис. С Nextcloud & Email. Ну и бэкапы, да...
Я, не смотря на платный office 365, еще имею свой собственный облачный (ну как облачный - vps на линуксе у провайдера) сервис. С Nextcloud & Email. Ну и бэкапы, да...
"В облаках с аккаунтами может произойти случайная блокировка, и ничего с этим не сделаешь. И никто не поможет (ну если только ты не размером с UniSuper). Новоявленный AI распознает там чего-то не того на свежезакачанной фотографии - и перманентный бан обеспечен.
Я, несмотря на платный Office 365, еще имею свой собственный облачный (ну как облачный - vps на линуксе у провайдера) сервис. С Nextcloud & Email. Ну и бэкапы, да…"
Я, несмотря на платный Office 365, еще имею свой собственный облачный (ну как облачный - vps на линуксе у провайдера) сервис. С Nextcloud & Email. Ну и бэкапы, да…"
А чё, сберегательная касса уже не надёжно?
Храню личный архив в двух разных облаках. Доброе шифрование и хорошие методы аутентификации сводят вероятность утечки данных в пределы статистической погрешности.
Держать что-то дома не вижу ни малейшего смысла, это мало того, что затратно всё, так ещё и ваша квартира - примерно самое ненадежное место на планете. От банальных бытовых неприятностей, пожаров и потопов, до медвежатников и обысков по желанию левой пятки какого-нибудь чинуши.
Идеальный вариант, это облако, которое ещё и никак нельзя связать с вашей личностью. Непросто, но можно сбацать и такое.
Варианты на случай ядерной войны, перфокарты и ленты не рассматриваются принципинально, т.к. будет не до фотографий из отпуска.
Держать что-то дома не вижу ни малейшего смысла, это мало того, что затратно всё, так ещё и ваша квартира - примерно самое ненадежное место на планете. От банальных бытовых неприятностей, пожаров и потопов, до медвежатников и обысков по желанию левой пятки какого-нибудь чинуши.
Идеальный вариант, это облако, которое ещё и никак нельзя связать с вашей личностью. Непросто, но можно сбацать и такое.
Варианты на случай ядерной войны, перфокарты и ленты не рассматриваются принципинально, т.к. будет не до фотографий из отпуска.
Вас будут пытать, но вы не выдадите военной тайны. Потому что вы не не знаете.
- Скажите, что Вы, с Вашим уникальным опытом, можете посоветовать сослуживцам?
- Ребята, учите матчасть! Там спрашивают и очень больно бьют".
Варианты на случай ядерной войны, перфокарты и ленты не рассматриваются принципинально, т.к. будет не до фотографий из отпуска.
Чтобы эффективно применить терморектальный криптоанализ, товарищ майор должен знать о том, что такое хранилище есть
Которая как раз наш слушай.
"Которая как раз наш, слюшай!"
Коммит должен быть
а для остальных с неродным что "грузите апельсины бочках", что "9CsvKL2ZYcjPuNtsJDgMa9mMChYZHF9q" - одного поля ягоды.
я ведь о чем - я предлагаю раскручивать клубок с начала а не с конца: у провайдера должен появится зачем-то интерес к вашим данным, вот давайте копать от этого - с чего он заинтересуется именно моим архивом 9CsvKL2ZYcjPuNtsJDgMa9mMChYZHF9q.zip а не вашим "грузите апельсины бочках.rar"? т.е. ему должен кто-то подсказать, что этот архив интересен. и вот тут моя ниточка не то, чтобы рвется, а становится совсем тонкой и даже немного эфемерной - попробуйте построить логическую цепочку от чего угодно к архиву "грузите апельсины бочках.rar" где-то на амазоне?
архивы с шифрованием... аккаунт ggg12453-backup@zzzzzmail.com - и?
Если инфа через пять лет будет маловажной, то шифрование ок. А если нет?
Облако есть? А если найду?
Идеальный вариант,
Примерно. Ну и никто не запрещает честно сдать облако с фотографиями кота Бублика, газового счетчика и учебником по статистике из студенческих лет. А чувствительную информацию оставить на каком-нибудь другом, о котором никто не знает. В английском языке есть очень хорошее понятие "plausible deniability", то бишь убедительная отрицаемость. Которая как раз наш слушай.
Да нет никакой философии. Идея в том, чтобы по данным аккаунта и тому, что там хранится, нельзя было однозначно сказать, что это манатки конкретно вот этого Васи Пупкина, а не Себастьян Перейры или ещё кого-нибудь
Вас будут пытать, но вы не выдадите военной тайны. Потому что вы не не знаете.
товарищ майор должен знать о том, что такое хранилище есть
Не-а.
Чтобы эффективно применить терморектальный криптоанализ, товарищ майор должен знать о том, что такое хранилище есть, а вы артачитесь и не хотите делиться доступом. Если он про него не в курсе, то и анализировать нечего. Выпадает переменная из уравнения с паяльником.
Чтобы эффективно применить терморектальный криптоанализ, товарищ майор должен знать о том, что такое хранилище есть, а вы артачитесь и не хотите делиться доступом. Если он про него не в курсе, то и анализировать нечего. Выпадает переменная из уравнения с паяльником.
Да нет никакой философии. Идея в том, чтобы по данным аккаунта и тому, что там хранится, нельзя было однозначно сказать, что это манатки конкретно вот этого Васи Пупкина, а не Себастьян Перейры или ещё кого-нибудь. И не суть важно, кто там будет интересоваться содержимым, хорошие люди, нехорошие, бывшая любовница, нынешняя жена, следователь и т.д. - если это не я, значит добра мне вряд ли желают.
Достичь можно шифрованием с некоторой обфускацией данных, плюс следовать определенным правилам создания аккаунта и последующих заходов на него. В целом, хранение данных уже давно не про надежность этого самого хранения, она по теории надежности давно уже высоченная у любого провайдера, а про защищенность этих данных от третьих лиц. Вот, что сейчас важно.
Достичь можно шифрованием с некоторой обфускацией данных, плюс следовать определенным правилам создания аккаунта и последующих заходов на него. В целом, хранение данных уже давно не про надежность этого самого хранения, она по теории надежности давно уже высоченная у любого провайдера, а про защищенность этих данных от третьих лиц. Вот, что сейчас важно.
Идеальный вариант, это облако, которое ещё и никак нельзя связать с вашей личностью.
Идеальный вариант, это облако, которое ещё и никак нельзя связать с вашей личностью
Ну точно с такой же вероятностью тот же НАС может безвозвратно навернуться со всеми райдами-шмайдами. Shit happens.
вероятность того, что оба
— Откуда ты знаешь, что я не серийный убийца? — спросил меня подсевший попутчик.
— Шансы на то, что два серийных убийцы окажутся в одной машине, просто ничтожны, — ответил я.
Так у них все правильно сделано, у них был и выжил бэкап в другом месте
Ну точно с такой же вероятностью тот же НАС
Спросите у компании UniSuper, что они думают по поводу этого бэкапа.
Ну точно с такой же вероятностью тот же НАС может безвозвратно навернуться со всеми райдами-шмайдами. Shit happens.
Для этого и придумали 3-2-1 бэкап
Вот, например в России, сейчас хранить что-либо на материальных носителях опасно.
Я храню все критические копии в 3 разных облаках: Dropbox, Box, Terabox в VeraCrypt контейнерах.
Я храню все критические копии в 3 разных облаках: Dropbox, Box, Terabox в VeraCrypt контейнерах.
Критические бэкапы как правило мало весят. Всё остальное целиком льётся.
Читать надо сначала, предложения.
Хотя, конечно, можно дождаться товарища Майора, и тогда полный песец всему информационному "компоту".
Хотя, конечно, можно дождаться товарища Майора, и тогда полный песец всему информационному "компоту".
которые в итоге оказываются провайдерами одного и того же старого жёсткого диска в Индии.
и инкрементальные бэкапы работают в VeraCrypt? Или каждый раз целиком образ загружать?
Удаление можно быстро восстановить, а вот хакнутые личные артефакты не вернуть.
У Саши Грей так фото в одежде утекли из облака.
А из современных носителей самый сохраняющийся - перфокарты. Считывать можно хоть мобильным.
У Саши Грей так фото в одежде утекли из облака.
А из современных носителей самый сохраняющийся - перфокарты. Считывать можно хоть мобильным.
С грунтовыми водами давно научились бороться.
Грунтовые воды, и привет семье.
голые бетонные стены, под землей (там температура плюсовая).
растворяется в смеси пероксида и серной кислоты.
выбивание на камне. Читается без технических средств просто глазами и даже на ощупь. Уничтожить физически очень сложно
А потом окажется, что его обшили снаружи горючим пенопластом и все снова нае… навернулось. Как всегда
А то у меня есть классная идея древний баян - выбивание на камне. Читается без технических средств просто глазами и даже на ощупь. Уничтожить физически очень сложно и экспериментально подтвержден срок хранения в несколько тысячелетий.
делать копии из титана
в чём сложность прочитать перфокарту?
Там же просто проволока намагниченная.
А потом окажется, что его обшили снаружи горючим пенопластом и все снова нае… навернулось. Как всегда
Читал историю что невозможно было прочесть инфу с "черного ящика" самолета - т.к. не осталось считывающих устройств, способных прочесть запись.
в чём сложность прочитать перфокарту? IBM умудрился там всё запутать, но алгоритм на странице умещается.
С высокой вероятностью до наших дней дожила очень небольшая часть грамот, которым повезло оказаться в удачных условиях.
Толку-то с надежности хранения носителей - если невозможно прочесть сохраненное?
Читал историю что невозможно было прочесть инфу с "черного ящика" самолета - т.к. не осталось считывающих устройств, способных прочесть запись.
С вырубанием на камне то же самое. Есть письмена, не поддающиеся расшифровке - ибо язык утрачен.
Читал историю что невозможно было прочесть инфу с "черного ящика" самолета - т.к. не осталось считывающих устройств, способных прочесть запись.
С вырубанием на камне то же самое. Есть письмена, не поддающиеся расшифровке - ибо язык утрачен.
и мягко говоря титан немного дороже картона и запасы сырья разные
титана
это фольклор. Когда были массовые сливы интимных фоток звёзд тема возникла.
У Саши Грей так фото в одежде утекли из облака
хранить в металлических коробках, переживут любой пожар. Любое электромагнитное излучение им не страшно. Механически повредить тяжело даже сознательно.
термин "современные" на какой период распространяется?
Что касается камня, то хотя бы перенос небольшой программы (равной пачке перфокарт) крайне тяжёл. Понадобятся действительно самые сильные программисты.
"Два расколол, три утопил"
Берестяные грамоты проще и дешевле, только раз в 1000 лет переписать на новую.
Уничтожить физически очень сложно
Горят. Клинопись крошится.
Читать оптическим считывателем.
выбивание на камне
Горят.
Уничтожить физически очень сложно и экспериментально подтвержден срок хранения в несколько тысячелетий.
Бэкапы есть - но кодировку никто не знает.
А из современных носителей самый сохраняющийся - перфокарты. Считывать можно хоть мобильным.
А то у меня есть
А из современных носителей самый сохраняющийся - перфокарты.
Так что только сказания и легенды. "Ох, как за флагом ЖОПЕГЕ в файле байты начинались, восемь А, эфэф три дэ, всё сейчас вам перечислю".
>>> Даже если вы имеете дело с такими крупняками
Не даже, а именно. Мелкие компании ещё хоть как-то за клиентов и за репутацию держатся. А "крупнякам" на вас абсолютно наплевать - ну куда вы с подводной лодки денетесь?
Не даже, а именно. Мелкие компании ещё хоть как-то за клиентов и за репутацию держатся. А "крупнякам" на вас абсолютно наплевать - ну куда вы с подводной лодки денетесь?
По меркам гугла "немаленькая" компенсация будет маленькой
всё окажется в одном и том же индийском датацентре, где сделают хэш и копию хранить не будут.
А за $300 индус на хотлайне сольёт любой чужой архив.
А за $300 индус на хотлайне сольёт любой чужой архив.
тем временем
А в пользовательском соглашении не появится тем временем маленькими буквами какой-нибудь "отказ от гарантий"(если ещё он не там)?
А "крупнякам" на вас абсолютно наплевать
Тем более, что Google свою вину уже публично признал.
Ну, или досудебное урегулирование, тоже может быть.
>>> Даже если вы имеете дело с такими крупнякамиНе даже, а именно. Мелкие компании ещё хоть как-то за клиентов и за репутацию держатся. А "крупнякам" на вас абсолютно наплевать - ну куда вы с подводной лодки денетесь?
Ну, в общем, хорошо то, что хорошо заканчивается
У меня тут встал вопрос про долговременное хранение избранных семейных фотографий, и я таки серьезно задумался - а не прикупить ли мне DVD. Записать три копии и хранить в разных местах самые ценные для меня фотографии. Видео у меня не так уж и много, так что я наверно более или менее улажусь пяток дисков.
А почему вертикально?
убрал все прокладки
прекрасным образом все читалось
И дело даже не в частоте использования. Там со временем происходит деградация материалов, естественный химический процесс.
P.S. Впервые поймал этот прикол ещё в 90-х с аудио-CD – которые со временем вдруг начинали "заикаться" и глючить при переключении треков.
У меня тут встал вопрос про долговременное хранение избранных семейных фотографий
P.S. DVD ненадёжен чуть менее чем полностью. Особенно сейчас, когда и сами-то качественные болванки найти изрядная проблема (то есть, компетентные производители просто ушли из этого сегмента).
Написано хранить, а не использовать. Но к вашему замечанию. Все UBS 3,5 диски от производителей допускаются до работы на боку, а некоторые так и задизайненны.
Давно известно, что CD-R гораздо устойчивее, чем CD-RW.
А почему вертикально? Я читал лет 7 назад где-то интервью со специалистом-дизайнером дисков, который объяснял, что контроллер рассчитывает импуль на головку исходя из горизонального расположения диска и даже её (головки) инерции. Я тогда использовал мягкие резиновые прокладки при установке дисков в корпус и считал, что уменьшение шума головок безвредно, однако через год-два начал замечать, что мои диски посыпались, СМАРТ начал говорить, что они растут. После прочтения статьи убрал все прокладки и ошибки поисчезали (ну, дохлые диски уже было не вернуть).
DVD читается отвратительно спустя годы
У меня диски, и CD, и DVD, разных фирм, записанные в разное время, хранятся абы как, я таки особо и не следил за условиям. Год назад начал разбирать что там накопилось, и прекрасным образом все читалось. Более того, у меня есть диски записанные в 97-98 годах, CD-R, и они до сих пор читаются. Единственное что я их достаю крайне редко.
И уронить...
Распечатать
Стеклоэмалью.
С обжигом.
У меня тут встал вопрос про долговременное хранение избранных семейных фотографий
Именно потому что ребята не очень то доверяли облаку, и имели еще пару бекапов.У меня тут встал вопрос про долговременное хранение избранных семейных фотографий, и я таки серьезно задумался - а не прикупить ли мне DVD. Записать три копии и хранить в разных местах самые ценные для меня фотографии. Видео у меня не так уж и много, так что я наверно более или менее улажусь пяток дисков.
Обычный жесткий диск.
CD/DVD не очень надежная штука. Имею личный опыт. С качеством не угадаешь. Какой-нибудь именитый производитель может не читаться спустя год, а лютый ноунейм живее всех живых спустя 10 лет.
Именно потому что ребята не очень то доверяли облаку, и имели еще пару бекапов.
То есть облакам они доверяли больше, чем собственным хранилищам.
И это правильно, на один случай факапа с облаком есть тысячи случаев факапов с личными хранилищами.
CD/DVD не очень надежная штука. Имею личный опыт. С качеством не угадаешь. Какой-нибудь именитый производитель может не читаться спустя год, а лютый ноунейм живее всех живых спустя 10 лет. Предполагаю, что производиться может каждая партия где придется и из чего придется, и сам производитель не знает сколько оно в итоге прослужит. Присоединяюсь к мнению Экслера - жесткий диск намного удобней и надежнее.
Именно потому что ребята не очень то доверяли облаку, и имели еще пару бекапов.У меня тут встал вопрос про долговременное хранение избранных семейных фотографий, и я таки серьезно задумался - а не прикупить ли мне DVD. Записать три копии и хранить в разных местах самые ценные для меня фотографии. Видео у меня не так уж и много, так что я наверно более или менее улажусь пяток дисков.
