Форс-мажоры, или как люди теряли свои данные

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



    Моя личная история большой потери произошла лет 7-8 назад. У меня тогда было пару мелких сайтов и форум при одном из них. Сайты базу данных не использовали, держались сугубо на файлах, потому локальная копия у меня хранилась. А вот форум… Его резервная копия делалась, когда я менял движок, где-то за год-полтора до печального случая. На сервере, где я хостился, было 4 диска, объединённых в RAID5 для надёжности. И в один прекрасный момент один из дисков посыпался. Да, RAID5 безусловно сохранил работоспособность и продолжал доблестно шуршать. Но нагрузка на выжившие диски стала критической. Жить базе данных оставалось недолго…

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

    Существует множество причин и способов потерять данные. Все они различаются степенью предсказуемости. Есть более-менее предсказуемые: системный сбой, взлом, ошибка администратора. Известны также случаи непорядочности, когда нанятые администраторы в конфликтных ситуациях не давали доступ к данным или повреждали их. Но бывали ситуации, которых обычно не ждут, но которые приносят гораздо более существенные потери данных.

    Пожар


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

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



    На фотографии видно через разбитое окно, что в дата-центре использовали «складское» размещение оборудования, которое способствовало распространению пламени. Кстати, прокладка кабелей «вермишелькой» неплохо помогла гореть другому ЦОД.



    Хранение бэкапов в том же ЦОД, где установлены и рабочие серверы, уже не раз подводило людей. Мне попадалось сообщение, датированное январём 2008 года, о человеке, который с ужасом в глазах глядел на горящий дата-центр в США, в котором стояли и рабочий, и резервный серверы. Через два с небольшим года от той же ситуации пострадали клиенты украинского дата-центра, а я начал делать бэкапы в независимый ЦОД в другой стране.

    Пожар может возникнуть везде, и какую бы супернадёжность не обещал Вам дата-центр, перестрахуйтесь. В июле 2012 года в Канаде от взрыва и пожара пострадала инфраструктура, обслуживающая множество правительственной информации (данные по водительским правам, регистрациям автомобилей, лицензиям на охоту и рыбную ловлю, а также медицинская информация — истории болезней, планы процедур и т.п.). К счастью, сохранились резервные копии. А в августе 2013 года в Индии пожар уничтожил серверы, содержавшие личные данные 1,2 миллиардов граждан страны, собранные в рамках правительственного проекта.

    Наводнение


    29-30 октября 2012 года ураган Сэнди достиг побережья США. Дата-центры Нью-Йорка и Нью-Джерси готовились к принятию удара: запасались топливом для генераторов, договаривались о его экстренных поставках, морально готовили дежурные бригады к тому, что им 3-5 дней придётся прожить на рабочем месте из соображений безопасности. Они оперативно подготовились к возможному отключению электричества, часто сопровождающему ураганы. К чему они не были готовы, так это к затоплению.

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



    Кстати, это не единственный случай затопления. В сентябре 2009 из-за обильных дождей серверные стойки оператора Vodafone в Турции стояли нижним оборудованием в воде, а в июле 2013 на технической площадке в Торонто, где размещается около полутора сотен различных провайдеров, из-за обильных дождей и сопутствующих перебоев с энергоснабжением наблюдался отказ системы охлаждения.

    «Маски-шоу»


    Вынос оборудования «для проведения расследования» или отключение какой-то части оборудования по решению государственных органов — также одна из возможных причин потери данных. Чаще он касается крупных проектов. Жители Украины помнят судьбу Infostore, ex.ua, популярного интернет-магазина Rozetka. В России та же участь постигла файлообменник iFolder.ru, серверы которого были отключены в рамках поиска неназванных улик по делу, совершённому неустановленным лицом (формулировка из прессы).

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

    Недобросовестное сотрудничество


    Такие случаи крайне редки, но всё же бывают. В 2010 году из-за конфликта между компаниями «Макхост» и «Оверсан-Меркурий» большое количество серверов было отключено от сети. Естественно, каждая из компаний пыталась доказать свою правоту и обвинить оппонента, но клиентам, у которых полегли сайты, от этого не легче.

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

    Предлагаю читателям в комментариях поделиться своим опытом, своими ситуациями, проучившими и научившими делать резервные копии. Тем же, кого жизнь ещё не проучила, хочу напомнить, что сохранность Ваших данных нужна и важна прежде всего Вам, и именно Вы должны её обеспечивать и контролировать, не надеясь на провайдера, дата-центр и силы небесные.
    ua-hosting.company
    421.65
    Хостинг-провайдер: серверы в NL / US до 100 Гбит/с
    Share post

    Comments 35

      +7
      Была полка СХД у заказчика, 24 диска, raid6 + 1 диск на hot swap. В один прекрасный момент за час сдохли диски один за одним. Официальный ответ вендора — неудачная партия дисков.
        –5
        Выводы: рейды на стореджах — зло. Распределение файлов должно быть организовано программным образом на независимых физических серверах. К тому же рейд уменьшает производительность всей много-дисковой системы, куда эффективнее распределение файлов скриптами. Особенно выбор всяких экзотических уровней ведет к катастрофам.
          0
          Из того, что я видел в своей работе, raid6 + 1 диск на hot swap стоит у 80 % заказчиков, еще 10% на raid 10 с hot swap, ну, и 10% на другие варианты.
            0
            Рейд6 используют только потому, что все заказчики жадные и не способны создавать нормальных решений, потому как либо нет знаний, либо нет денег, рейды — вообще зло для файл-стореджевых проектов и их крупные проекты никогда не используют. Балансировка трафика, нагрузки и бекапирование проводятся исключительно скриптами и никак по другому. Иначе начинаются проблемы — уперлись в производительность контроллера, еще чего-то, либо просто платформа странно работает, хотя должна же держать нагрузку… У меня был опыт работы с сервером в котором 32 диска, рейд на нем — это смерть для проекта, он не работает эффективно, уже при 4 Гбит / с начинает загибаться.
            +8
            Ничего себе. То есть все компании, которые вкладывают, иногда сотни тысяч $ просто не понимают, что надо было скриптики нарисовать да и дело с концом?
            Для защиты от подобных случаев используется репликация на уровне СХД.
              –3
              То есть Вы хотите сказать, что аппаратные решения способны полноценно заменить программные? Это бред. На счет денег. Без мозгов можно и миллион вложить впустую (это на самом деле не очень большие деньги для нормального проекта). К нам иногда приходят подобные кадры, которые увы сами не понимают, чего хотят, при этом имеют вагон денег. Вложить не проблема… Проблема сделать успешный проект, который будет не только приносить прибыль, но и граммотно построен и при этом реально полезен людям, а для этого помимо денег нужно иметь мозг в голове с уровнем IQ выше обезьяны (что встречается редко в наше время), хотя бы для того, чтоб найти граммотных специалистов и иметь возможность контроллировать процесс. Я отказываю таким клиентам, так как, если люди сами не знают чего хотят — жди беды, нарвешься на вынос мозга, никакие деньги не стоят этого. Время — оно бесценно.

              Крупные успешные проекты (а их единицы) — да, построены исключительно на скриптах. Всякие аппаратные репликации — удел небольших проектов (так как малобюджетные стартапы не имеют средств на комманду программистов), в крупных используются в исключительных случаях. В случае с крупным проектом аппаратные репликации = неэффективно потраченные средства, не эффективное использование ресурсов, в результате дополнительное загрязнение окружающей среды за счет использования дополнительного оборудования, ну и дополнительные фин. потери.

              Минимализм — будущее. И аппаратные прибамбасы никогда не обеспечат нужного результата, так как проекты индивидуальны и требуют индивидуальных решений / подхода / архитектуры для достижения лучшего результата. Помио реплицирования — есть еще масса других задач. Так что все зависит исключено от скриптов в первую очередь.
                +4
                У вас очень странное мнение.
                  +1
                  HostingManager, несомненно, не особо прав (а может, просто не сталкивался с ситуациями, когда «железо спасает»), но, право, даже если посмотреть, с какими проблемами боролить в дизайне ZFS, и как эти проблемы решены (а порой — как бы «решены») в железных дорогих решениях, задумываешься, сколько в цене решений реальной защиты, сколько маркетинга, а сколько «сделать бы лучше, но покупатели привыкли, что должно быть минимум так, а то им страшно»).

                  Собственно, тут уже вопрос компетенции и выбора правильной железки/софтины, причем порой выгоднее не вестись на вендорские обещания.
                  +1
                  Не в первый раз сталкиваюсь с похожей точкой зрения, у людей с некоторым опытом fail-ов.
                  К.О. mode — наиболее эффективными и надежными получаются решения, где soft- и hardware части решения дополняют и компенсируют недостатки друг друга.
              +1
              Ну вопрос умирания дисков в одной партии вообще часто возникает. Скорее важно, как к этому вендор относится. Меня при покупке единоразовой 24 дисков для полки, например, мало радует необходимость постановки вопроса о том, чтобы «партии дисков были разные», это перемешивание мог бы вендор сделать.

              Я так понимаю, что у того вендора заказчик после такого фейла мало что хочет покупать. Мало ли, вдруг там не только диски «неудачные», но и проект полки плохой, софт недоделанный, менеджер невнимательный?
              +2
              Помню был случай: полетел диск со свей файлопомойкой, ОСью, играми в домашних условиях… Много чего там было: нужного мне и (не только мне).
              После того случая храню информацию минимум на 3 жестких дисках (500 / 500 / 2000 ГБ), 1 из которых достается только в случае крайней необходимости сверить старые и новые версии используемых программ.

              Так что бородатая присказка тут очень и очень кстати.

              В последнее время часто перезаливаю в облако типа Меги и Мейла (у них была хорошая акция недавно, успел не пропустить), подумываю опробовать ВанДрайв от Майкросовта.

              Так что в какой-то мере меня можно считать параноиком хоть и не являюсь оным: общее количество бекапа порой доходит до 10 одинаковых копий.

              Автору спасибо за напоминание в очередной раз делать бекапы любых нужных данных!
                0
                Интересует насколько вы зависимы от обстоятельств украинской политики, давно приглядываюсь к вашим предложениям но опасаюсь, нестабильной ситуации в Украине. Мой друг недавно, потерял большие деньги из за этой нестабильности, украинские партнеры просто исчезли после многих лет работы, очень надеется, что с ними все хорошо.
                  +1
                  Почти не зависим. Разве что если бы ввели ЧП и отрубили по всей стране внешние каналы, было бы грустно, т.к. не в Украине только один человек на данный момент. Однако и к такой ситуации и соответствующему манёвру готовились. А так, если оплачивать не через банк, проблем не будет. Компания зарегистрирована в Белизе, серверы размещены в Нидерландах и США. В Украине только мы все родились. :)
                    0
                    Отлично, думаю в ближайшее время приду к вам :)
                      0
                      Милости просим, готовим хлеб-соль. :)
                  0
                  Поделюсь как устроено у меня.
                  Учтите что некоторые учатся один раз, а я поучился уже 2 раза и чуть ли не 3ий раз уже как-то был (пронесло), после чего были сделаны масштабные оргвыводы :)))

                  Есть комп ПК1, который рабочий. На нем с помощью raid1 сделан диск для данных Disk1 (2Tb). ПК1 подключен к сети через ИБП типа on-line, т.е. с электросетью развязка полная т.к. до компа энергия добирается через преобразование розетка-выпрямитель-аккумуляторы-инвертор-розетка.
                  Я собрал дешевый комп ПК2. Засунул туда 2 дешевых винчестера Disk21 и Disk22 = объему Disk1. Из этих двух винчестеров организован пул Disk2 программой StableBit DrivePool (штука платная, кажется целых 20$ отдал). ПК2 подключен к сети через обычный бесперебойник.
                  На обоих компах установлен BitTorrent Sync. Трекер, DHT — отключены, прописаны IPшники компов и порты, по которым btc должны соединяться друг с другом (т.е. сделано все что бы они работали только в локальной сети). Таким образом, когда я работаю у меня всегда есть актуальная копия диска с данными и если что-то вдруг случится или я файлы удалю, то я могу их достать из «репозитория» (на ПК2 файлы при удалении btc не удаляет, а складывает в папку, которую можно потом почистить самостоятельно).
                  Ну и, разумеется, имеется обычный 3,5" Disk3 = объему Disk1, который покоится три месяца на полке в мягкой коробке в другой крвартире, а раз в три месяца достается и на него сливается копия с Disk1. Все знают что этот диск брать имею право только я и под страхом грозной кары эту коробку даже передвигать нельзя (хотя она и так у задней стенки заныкана, что бы случайно не вытащили).
                  Т.О.:
                  — если сдохнет один жесткий диск на ПК1, то надо бежать за хардом такого же объема и восстанавливать рейд (процесс репликации долгий — несоклько часов);
                  — если сдохне контроллер raid на ПК1, то есть идентичный )));
                  — если сдохнет один жесткий диск ПК2, то надо бежать за хардом такого же объема и просто подключить его к пулу (15 минут и пул восстановлен);
                  — если сдохнет ПК1 полностью, то у меня будет иметься копия данных давностью 10-20 минут;
                  — если сдохнет ПК2 полностью, то у меня остаются все данные на основной компе;
                  — если сдохнут оба компа, то у меня остаются данные трехмесячной давности;
                  — если рядом взорвется ядерная бомба — черт с ними с данными, главное что бы была коробка консервов с тушенкой )))
                    0
                    А если, скажем, виурс пробежится по дискам и заменить все содеримое всех дркументов нулями?
                      0
                      Так на других же дисках, физически отключенных, данные есть.
                    +1
                    Дома основная помойка живет на RAID50, который собран из кучи разных дисков одинакового объема — как результат приемлимая надежность не зависящая от «ну вы понимаете, вся партия бракованная, её Вася уронил со второго этажа» и «да, мы облажались с этим LBA=0», плюс бэкап делающийся на внешний хард + бэкап на файлопомойку в ohv.
                    Хотя надо сказать путь до этого был долгий:
                    1) БП Rolsen, который благодаря чЮдо экономии производителя (чтоб он в гробу вертелся) не только унес старую машину на тот свет, но и чуть не вызвал пожар. После него я начал делать бэкапы на внешний диск
                    2) Старый WD на 120гигов, который решил довольно резвенько осыпаться в момент бэкапа, чего не поняла самописаная утилита и запорола бэкап. После этого я перешел на софтовый рейд, чтобы не налететь на такое снова.
                    3) Успешно откинувшие копыта IBM ные DDYS-ки с разницей в 1 час, угробившие raid5. После этого я перешел на аппаратный рейд из хардов от различных производителей.
                    4) После падения цен на хостинг/аренду серверов/облака — добавил к этому всему бэкап раз в неделю на диски, которые вообще не находятся около меня.
                    Для домашнего применения — этого более чем достаточно, можно даже сказать, что перебор.
                      +6
                      На Daily WTF читал шикарную историю: фирма расформировывала резервный ЦОД, и нужно было приехать туда, вытащить из серверов харды и кинуть в специальный шредер для хардов. Т.к. работа рутинная, то послали туда самого баклана. Все всполошились, когда через некоторое время стали падать сервера в основном ЦОД.
                      Он перепутал адреса ЦОДов и начал гасить основной (-:
                        0
                        Шредер для хардов. Как серпом по…
                          +2
                          Послать баклана _гасить_ ДЦ. Они б еще воинскую часть с ядерным оружием одного баклана послали снимать с дежурства.

                          Видно, ДЦ у них занимал кладовку в соседнем здании. Иначе, думаю, рубильник бы поехала вырубать делегация из начальников и грамотных админов.
                          0
                          Бэкап папки с рабочими документами и фотки — в облаке. Года два назад удачно попал под акцию Box на 50ГБ пожизненно.
                          Системный хард раз в 3-4 месяца сливаю с помощью Norton Ghost.
                          Остальное — не жалко.
                            +1
                            Еще одну довольно популярную причину забыли: заводской брак HDD редко бывает в одном винте, обычно затрагивает целую партию. Поэтому граждане закупившие OEM винты и собравшие на них конфигурацию raid из расчета замены одного винта «если че», жестоко обламываются, когда диски начинают вылетать пару раз в день.

                            Еще страшилка — это плохая политика бэкапов. Когда данных много (десятки-сотни ТБ, сканы доков например), а хранилище архивное (write once read many), люди часто думают терминами дифференциальных бэкапов: меняется редко, если че — восстановимся. И тут — опа, надо подниматься собираясь из диффов за последние XX месяцев (=оффлайн на несколько дней), а то и ввобще выясняется что парочка диффов не читается.

                            И еще одна в кучу — основной и резервный датацентры в одной погодной зоне, напр. на восточном побережье в штатах (а то и вообще в 15 минутах друг от друга, в рамках одной подстанции). В последний ураган было весело: оба ДЦ работают на дизелях два дня, шлют мольбы сокращать энергопотребление. Та-да!
                              0
                              Простите, но мне кажется, вы путаете дифференциальные бакапы с инкрементальными. Вообще-то для восстановления с дифференциального бакапа нужен 1 полный архив и 1 дифференциальный.
                              У меня полные делаются 1 раз в квартал, дифференциальные — раз в неделю. инкрементальные — каждый день.
                              Чтобы восстановить на нужный день нужны — 1 полный, 1 дифференциальный, и стопка инкрементальных.
                              +1
                              Я подумываю собрать простенький ПК, выбрал мамку на LGA1150 с 6 SATA 6 Gbit. При том, что фото/видео архив у меня сейчас достигает 450ГБ и со временем только растёт. Я пока не знаю — какое облако зажуёт такое количество информации.

                              Алсо — прискорбный случай произошёл с внешним 2,5 диском на террабайт (резиновый Transcend). которому не было и полугода. Он использовался только для бекапов в среднем раз в 2 недели. Я наплевал на гарантию (на том диске есть фото, которые не хочется потерять), вскрыл. вставил в компьютер — ничего не поменялось, по симптомам умерла механика.

                              Посему — бекапов много не бывает. Особенно при почти нулевой стоимости копирования.
                                0
                                А вы не оптимизируете фотоархив? Ну, к примеру, перегоняя RAW в JPEG кадров вне категории «шедевр».
                                  0
                                  Вы лучше переплатите 500 руб и возьмите мать попроще и внешний контроллер SATA для дисков. И еще один контроллер в ЗИП.
                                  +1
                                  У нас прошлой осенью горел один крупный филиал. Он располагался на верхних этажах БЦ, а непосредственно пожар был на крыше. В итоге огонь до нас не добрался, но водой и пеной пожарные все залили хорошо. Все, что было не приколочено, натурально плавало. Инфраструктуру же спасло только то, что над серверной была сплошная бетонная плита, и вода туда не добралась. В итоге, когда через пару дней воду из помещений откачали, привели в норму влажность и дали питание — все завелось.

                                  Драматизм в том, что кассеты с бэкапами лежали в коробках в той же самой серверной. После того случая для хранения кассет был куплен водонепроницаемый огнеупорный сейф, а каталогизация бэкапов сливается на центральный сервер резервного копирования.
                                    +2
                                    Потерял много личных данных на знаменитой 500-ке Сигейта — три диска одни за другим.

                                    Из необычного — разбойное нападение.
                                    4 парня (2 студента, 2 вчерашние студенты) снимали 3-комнатную квартиру.
                                    Один из них «наплел» малознакомой девушке, что крутой неимоверно и имеет огнестрел.
                                    Однажды вечером, 14 февраля, когда все были в городе на любовных фронтах, дома остался один из нас (не «крутой») девушки не имевший.
                                    Далее с его слов: позвонили в дверь, он как человек крупного телосложения без всякой опаски открывает дверь и через секунду понимает что у его живота находится далеко не тупой предмет. Далее его заталкивает в квартиру 5-ро бугаев, связывают, сажают на стул, пытаются выяснить где лежит ствол, при этом планомерно обыскивают всю квартиру. Не найдя никакого оружия, его развязывают и быстро уходят прихватив все более-менее ценное, что попало под руку.
                                    Итог получасового просиживания на стуле: унесли у кого-то деньги (немного), у кого-то одежды, и у меня — два харда по терабайту, довольно дорогие по тем временам. Данные было жаль больше всего.
                                    Успокаивался тем, что бобыль-«сиделец» невредим остался — отделался легким испугом.
                                    А «крутой» приехал только через час после того как узнал о разбое, только после того как сам вызвал полицию и издалека убедился что они подъехали к дому. Хотя остальные (я и еще один «сосед по квартире») были через 20-30 минут и оперативно посовещавшись, решили полицию не вызывать — материальные потери были не значительны.
                                    Мораль из этой истории:
                                    1. Бэкапы хранить в разных местах, особо ценную информацию не лениться дублировать несколько раз
                                    2. Аккуратней выбирать с кем жить под одной крышей
                                    3. Даже если ты «Рэмбо», банальное «кто там?» может лучше уберечь
                                    4. Полиция если захочет, может работать, но чаще всего не хочет, иногда если нужно, надо помогать ей «хотеть»
                                    5. И вообще иногда лучше молчать.
                                      0
                                      Я терял данные на рейд 5 уже 2 раза. Но, к счастью, оба раза у меня были бэкапы. Оба раза очередной винт вылетал во время восстановления рейда, что и становилось причиной смерти рейда. С тех пор я больше не использую этот тип рейда.
                                        0
                                        А на какой перешли? 50/6/60? Или на старый добрый 10? Ну и в довесок — харды были от одного производителя и из одной партии?
                                        0
                                        У нас был случай, когда «полетела»(подробностей не вспомню) ФС ext3 на которой находилась БД системы тикетов Trac. Был, примерно, полугодовой давности бэкап, но, поскольку система(Trac) использовалась крайне активно(контроль задач сотрудников и снабжение). Потерянные данные были критичны. Хорошо вспомнили, что все изменения всех тикетов высылалось на почту руководителя. Выгрузили письма, написали парсер и почти безболезненно восстановили данные. С тех пор относимся к данным гораздо ответственнее.
                                          0
                                          Потерял доступ к файловому архиву (к одной из свежих копий точнее) когда всунул жесткий в компьютер отца, там была система резервирования BIOS на ЖД, и работала она глючно, не поддерживала диски более 1Tb, благо проблема была известная и народ написал программу для исправления файловой структуры, которая меня спасла.
                                            +1
                                            Терял данные на рейд 5 когда в «датацентре» сломался кондей. Все оборудование пошло на перегрев. Почтовый сервер, через который должно было быть отправлено письмо, что с рейдами появилась проблема отключился сам — у него единственного была аппаратная защита от перегрева.
                                            Теперь в скриптах контроля у меня проверяется и температура на дисках. Если повышение среднее — шлется письмо. Если повышение существенное — дается команда на отключение.
                                            Стоимость носителей и аппаратуры их обработки однако далеко не нулевая.
                                            Делать очень много копий может оказаться слишком дорого.
                                            Для своей конторы остановился на raid на серверах (1,10 или 5)+ежедневный бакап на самосборный сторейдж на диски с raid 5.

                                            Only users with full accounts can post comments. Log in, please.