Комментарии 35
Была полка СХД у заказчика, 24 диска, raid6 + 1 диск на hot swap. В один прекрасный момент за час сдохли диски один за одним. Официальный ответ вендора — неудачная партия дисков.
Выводы: рейды на стореджах — зло. Распределение файлов должно быть организовано программным образом на независимых физических серверах. К тому же рейд уменьшает производительность всей много-дисковой системы, куда эффективнее распределение файлов скриптами. Особенно выбор всяких экзотических уровней ведет к катастрофам.
Из того, что я видел в своей работе, raid6 + 1 диск на hot swap стоит у 80 % заказчиков, еще 10% на raid 10 с hot swap, ну, и 10% на другие варианты.
Рейд6 используют только потому, что все заказчики жадные и не способны создавать нормальных решений, потому как либо нет знаний, либо нет денег, рейды — вообще зло для файл-стореджевых проектов и их крупные проекты никогда не используют. Балансировка трафика, нагрузки и бекапирование проводятся исключительно скриптами и никак по другому. Иначе начинаются проблемы — уперлись в производительность контроллера, еще чего-то, либо просто платформа странно работает, хотя должна же держать нагрузку… У меня был опыт работы с сервером в котором 32 диска, рейд на нем — это смерть для проекта, он не работает эффективно, уже при 4 Гбит / с начинает загибаться.
Ничего себе. То есть все компании, которые вкладывают, иногда сотни тысяч $ просто не понимают, что надо было скриптики нарисовать да и дело с концом?
Для защиты от подобных случаев используется репликация на уровне СХД.
Для защиты от подобных случаев используется репликация на уровне СХД.
То есть Вы хотите сказать, что аппаратные решения способны полноценно заменить программные? Это бред. На счет денег. Без мозгов можно и миллион вложить впустую (это на самом деле не очень большие деньги для нормального проекта). К нам иногда приходят подобные кадры, которые увы сами не понимают, чего хотят, при этом имеют вагон денег. Вложить не проблема… Проблема сделать успешный проект, который будет не только приносить прибыль, но и граммотно построен и при этом реально полезен людям, а для этого помимо денег нужно иметь мозг в голове с уровнем IQ выше обезьяны (что встречается редко в наше время), хотя бы для того, чтоб найти граммотных специалистов и иметь возможность контроллировать процесс. Я отказываю таким клиентам, так как, если люди сами не знают чего хотят — жди беды, нарвешься на вынос мозга, никакие деньги не стоят этого. Время — оно бесценно.
Крупные успешные проекты (а их единицы) — да, построены исключительно на скриптах. Всякие аппаратные репликации — удел небольших проектов (так как малобюджетные стартапы не имеют средств на комманду программистов), в крупных используются в исключительных случаях. В случае с крупным проектом аппаратные репликации = неэффективно потраченные средства, не эффективное использование ресурсов, в результате дополнительное загрязнение окружающей среды за счет использования дополнительного оборудования, ну и дополнительные фин. потери.
Минимализм — будущее. И аппаратные прибамбасы никогда не обеспечат нужного результата, так как проекты индивидуальны и требуют индивидуальных решений / подхода / архитектуры для достижения лучшего результата. Помио реплицирования — есть еще масса других задач. Так что все зависит исключено от скриптов в первую очередь.
Крупные успешные проекты (а их единицы) — да, построены исключительно на скриптах. Всякие аппаратные репликации — удел небольших проектов (так как малобюджетные стартапы не имеют средств на комманду программистов), в крупных используются в исключительных случаях. В случае с крупным проектом аппаратные репликации = неэффективно потраченные средства, не эффективное использование ресурсов, в результате дополнительное загрязнение окружающей среды за счет использования дополнительного оборудования, ну и дополнительные фин. потери.
Минимализм — будущее. И аппаратные прибамбасы никогда не обеспечат нужного результата, так как проекты индивидуальны и требуют индивидуальных решений / подхода / архитектуры для достижения лучшего результата. Помио реплицирования — есть еще масса других задач. Так что все зависит исключено от скриптов в первую очередь.
У вас очень странное мнение.
HostingManager, несомненно, не особо прав (а может, просто не сталкивался с ситуациями, когда «железо спасает»), но, право, даже если посмотреть, с какими проблемами боролить в дизайне ZFS, и как эти проблемы решены (а порой — как бы «решены») в железных дорогих решениях, задумываешься, сколько в цене решений реальной защиты, сколько маркетинга, а сколько «сделать бы лучше, но покупатели привыкли, что должно быть минимум так, а то им страшно»).
Собственно, тут уже вопрос компетенции и выбора правильной железки/софтины, причем порой выгоднее не вестись на вендорские обещания.
Собственно, тут уже вопрос компетенции и выбора правильной железки/софтины, причем порой выгоднее не вестись на вендорские обещания.
Не в первый раз сталкиваюсь с похожей точкой зрения, у людей с некоторым опытом fail-ов.
К.О. mode — наиболее эффективными и надежными получаются решения, где soft- и hardware части решения дополняют и компенсируют недостатки друг друга.
К.О. mode — наиболее эффективными и надежными получаются решения, где soft- и hardware части решения дополняют и компенсируют недостатки друг друга.
Ну вопрос умирания дисков в одной партии вообще часто возникает. Скорее важно, как к этому вендор относится. Меня при покупке единоразовой 24 дисков для полки, например, мало радует необходимость постановки вопроса о том, чтобы «партии дисков были разные», это перемешивание мог бы вендор сделать.
Я так понимаю, что у того вендора заказчик после такого фейла мало что хочет покупать. Мало ли, вдруг там не только диски «неудачные», но и проект полки плохой, софт недоделанный, менеджер невнимательный?
Я так понимаю, что у того вендора заказчик после такого фейла мало что хочет покупать. Мало ли, вдруг там не только диски «неудачные», но и проект полки плохой, софт недоделанный, менеджер невнимательный?
Помню был случай: полетел диск со свей файлопомойкой, ОСью, играми в домашних условиях… Много чего там было: нужного мне и (не только мне).
После того случая храню информацию минимум на 3 жестких дисках (500 / 500 / 2000 ГБ), 1 из которых достается только в случае крайней необходимости сверить старые и новые версии используемых программ.
Так что бородатая присказка тут очень и очень кстати.
В последнее время часто перезаливаю в облако типа Меги и Мейла (у них была хорошая акция недавно, успел не пропустить), подумываю опробовать ВанДрайв от Майкросовта.
Так что в какой-то мере меня можно считать параноиком хоть и не являюсь оным: общее количество бекапа порой доходит до 10 одинаковых копий.
Автору спасибо за напоминание в очередной раз делать бекапы любых нужных данных!
После того случая храню информацию минимум на 3 жестких дисках (500 / 500 / 2000 ГБ), 1 из которых достается только в случае крайней необходимости сверить старые и новые версии используемых программ.
Так что бородатая присказка тут очень и очень кстати.
В последнее время часто перезаливаю в облако типа Меги и Мейла (у них была хорошая акция недавно, успел не пропустить), подумываю опробовать ВанДрайв от Майкросовта.
Так что в какой-то мере меня можно считать параноиком хоть и не являюсь оным: общее количество бекапа порой доходит до 10 одинаковых копий.
Автору спасибо за напоминание в очередной раз делать бекапы любых нужных данных!
Интересует насколько вы зависимы от обстоятельств украинской политики, давно приглядываюсь к вашим предложениям но опасаюсь, нестабильной ситуации в Украине. Мой друг недавно, потерял большие деньги из за этой нестабильности, украинские партнеры просто исчезли после многих лет работы, очень надеется, что с ними все хорошо.
Почти не зависим. Разве что если бы ввели ЧП и отрубили по всей стране внешние каналы, было бы грустно, т.к. не в Украине только один человек на данный момент. Однако и к такой ситуации и соответствующему манёвру готовились. А так, если оплачивать не через банк, проблем не будет. Компания зарегистрирована в Белизе, серверы размещены в Нидерландах и США. В Украине только мы все родились. :)
Поделюсь как устроено у меня.
Учтите что некоторые учатся один раз, а я поучился уже 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 полностью, то у меня остаются все данные на основной компе;
— если сдохнут оба компа, то у меня остаются данные трехмесячной давности;
— если рядом взорвется ядерная бомба — черт с ними с данными, главное что бы была коробка консервов с тушенкой )))
Учтите что некоторые учатся один раз, а я поучился уже 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 полностью, то у меня остаются все данные на основной компе;
— если сдохнут оба компа, то у меня остаются данные трехмесячной давности;
— если рядом взорвется ядерная бомба — черт с ними с данными, главное что бы была коробка консервов с тушенкой )))
Дома основная помойка живет на RAID50, который собран из кучи разных дисков одинакового объема — как результат приемлимая надежность не зависящая от «ну вы понимаете, вся партия бракованная, её Вася уронил со второго этажа» и «да, мы облажались с этим LBA=0», плюс бэкап делающийся на внешний хард + бэкап на файлопомойку в ohv.
Хотя надо сказать путь до этого был долгий:
1) БП Rolsen, который благодаря чЮдо экономии производителя (чтоб он в гробу вертелся) не только унес старую машину на тот свет, но и чуть не вызвал пожар. После него я начал делать бэкапы на внешний диск
2) Старый WD на 120гигов, который решил довольно резвенько осыпаться в момент бэкапа, чего не поняла самописаная утилита и запорола бэкап. После этого я перешел на софтовый рейд, чтобы не налететь на такое снова.
3) Успешно откинувшие копыта IBM ные DDYS-ки с разницей в 1 час, угробившие raid5. После этого я перешел на аппаратный рейд из хардов от различных производителей.
4) После падения цен на хостинг/аренду серверов/облака — добавил к этому всему бэкап раз в неделю на диски, которые вообще не находятся около меня.
Для домашнего применения — этого более чем достаточно, можно даже сказать, что перебор.
Хотя надо сказать путь до этого был долгий:
1) БП Rolsen, который благодаря чЮдо экономии производителя (чтоб он в гробу вертелся) не только унес старую машину на тот свет, но и чуть не вызвал пожар. После него я начал делать бэкапы на внешний диск
2) Старый WD на 120гигов, который решил довольно резвенько осыпаться в момент бэкапа, чего не поняла самописаная утилита и запорола бэкап. После этого я перешел на софтовый рейд, чтобы не налететь на такое снова.
3) Успешно откинувшие копыта IBM ные DDYS-ки с разницей в 1 час, угробившие raid5. После этого я перешел на аппаратный рейд из хардов от различных производителей.
4) После падения цен на хостинг/аренду серверов/облака — добавил к этому всему бэкап раз в неделю на диски, которые вообще не находятся около меня.
Для домашнего применения — этого более чем достаточно, можно даже сказать, что перебор.
На Daily WTF читал шикарную историю: фирма расформировывала резервный ЦОД, и нужно было приехать туда, вытащить из серверов харды и кинуть в специальный шредер для хардов. Т.к. работа рутинная, то послали туда самого баклана. Все всполошились, когда через некоторое время стали падать сервера в основном ЦОД.
Он перепутал адреса ЦОДов и начал гасить основной (-:
Он перепутал адреса ЦОДов и начал гасить основной (-:
Бэкап папки с рабочими документами и фотки — в облаке. Года два назад удачно попал под акцию Box на 50ГБ пожизненно.
Системный хард раз в 3-4 месяца сливаю с помощью Norton Ghost.
Остальное — не жалко.
Системный хард раз в 3-4 месяца сливаю с помощью Norton Ghost.
Остальное — не жалко.
Еще одну довольно популярную причину забыли: заводской брак HDD редко бывает в одном винте, обычно затрагивает целую партию. Поэтому граждане закупившие OEM винты и собравшие на них конфигурацию raid из расчета замены одного винта «если че», жестоко обламываются, когда диски начинают вылетать пару раз в день.
Еще страшилка — это плохая политика бэкапов. Когда данных много (десятки-сотни ТБ, сканы доков например), а хранилище архивное (write once read many), люди часто думают терминами дифференциальных бэкапов: меняется редко, если че — восстановимся. И тут — опа, надо подниматься собираясь из диффов за последние XX месяцев (=оффлайн на несколько дней), а то и ввобще выясняется что парочка диффов не читается.
И еще одна в кучу — основной и резервный датацентры в одной погодной зоне, напр. на восточном побережье в штатах (а то и вообще в 15 минутах друг от друга, в рамках одной подстанции). В последний ураган было весело: оба ДЦ работают на дизелях два дня, шлют мольбы сокращать энергопотребление. Та-да!
Еще страшилка — это плохая политика бэкапов. Когда данных много (десятки-сотни ТБ, сканы доков например), а хранилище архивное (write once read many), люди часто думают терминами дифференциальных бэкапов: меняется редко, если че — восстановимся. И тут — опа, надо подниматься собираясь из диффов за последние XX месяцев (=оффлайн на несколько дней), а то и ввобще выясняется что парочка диффов не читается.
И еще одна в кучу — основной и резервный датацентры в одной погодной зоне, напр. на восточном побережье в штатах (а то и вообще в 15 минутах друг от друга, в рамках одной подстанции). В последний ураган было весело: оба ДЦ работают на дизелях два дня, шлют мольбы сокращать энергопотребление. Та-да!
Простите, но мне кажется, вы путаете дифференциальные бакапы с инкрементальными. Вообще-то для восстановления с дифференциального бакапа нужен 1 полный архив и 1 дифференциальный.
У меня полные делаются 1 раз в квартал, дифференциальные — раз в неделю. инкрементальные — каждый день.
Чтобы восстановить на нужный день нужны — 1 полный, 1 дифференциальный, и стопка инкрементальных.
У меня полные делаются 1 раз в квартал, дифференциальные — раз в неделю. инкрементальные — каждый день.
Чтобы восстановить на нужный день нужны — 1 полный, 1 дифференциальный, и стопка инкрементальных.
Я подумываю собрать простенький ПК, выбрал мамку на LGA1150 с 6 SATA 6 Gbit. При том, что фото/видео архив у меня сейчас достигает 450ГБ и со временем только растёт. Я пока не знаю — какое облако зажуёт такое количество информации.
Алсо — прискорбный случай произошёл с внешним 2,5 диском на террабайт (резиновый Transcend). которому не было и полугода. Он использовался только для бекапов в среднем раз в 2 недели. Я наплевал на гарантию (на том диске есть фото, которые не хочется потерять), вскрыл. вставил в компьютер — ничего не поменялось, по симптомам умерла механика.
Посему — бекапов много не бывает. Особенно при почти нулевой стоимости копирования.
Алсо — прискорбный случай произошёл с внешним 2,5 диском на террабайт (резиновый Transcend). которому не было и полугода. Он использовался только для бекапов в среднем раз в 2 недели. Я наплевал на гарантию (на том диске есть фото, которые не хочется потерять), вскрыл. вставил в компьютер — ничего не поменялось, по симптомам умерла механика.
Посему — бекапов много не бывает. Особенно при почти нулевой стоимости копирования.
У нас прошлой осенью горел один крупный филиал. Он располагался на верхних этажах БЦ, а непосредственно пожар был на крыше. В итоге огонь до нас не добрался, но водой и пеной пожарные все залили хорошо. Все, что было не приколочено, натурально плавало. Инфраструктуру же спасло только то, что над серверной была сплошная бетонная плита, и вода туда не добралась. В итоге, когда через пару дней воду из помещений откачали, привели в норму влажность и дали питание — все завелось.
Драматизм в том, что кассеты с бэкапами лежали в коробках в той же самой серверной. После того случая для хранения кассет был куплен водонепроницаемый огнеупорный сейф, а каталогизация бэкапов сливается на центральный сервер резервного копирования.
Драматизм в том, что кассеты с бэкапами лежали в коробках в той же самой серверной. После того случая для хранения кассет был куплен водонепроницаемый огнеупорный сейф, а каталогизация бэкапов сливается на центральный сервер резервного копирования.
Потерял много личных данных на знаменитой 500-ке Сигейта — три диска одни за другим.
Из необычного — разбойное нападение.
4 парня (2 студента, 2 вчерашние студенты) снимали 3-комнатную квартиру.
Один из них «наплел» малознакомой девушке, что крутой неимоверно и имеет огнестрел.
Однажды вечером, 14 февраля, когда все были в городе на любовных фронтах, дома остался один из нас (не «крутой») девушки не имевший.
Далее с его слов: позвонили в дверь, он как человек крупного телосложения без всякой опаски открывает дверь и через секунду понимает что у его живота находится далеко не тупой предмет. Далее его заталкивает в квартиру 5-ро бугаев, связывают, сажают на стул, пытаются выяснить где лежит ствол, при этом планомерно обыскивают всю квартиру. Не найдя никакого оружия, его развязывают и быстро уходят прихватив все более-менее ценное, что попало под руку.
Итог получасового просиживания на стуле: унесли у кого-то деньги (немного), у кого-то одежды, и у меня — два харда по терабайту, довольно дорогие по тем временам. Данные было жаль больше всего.
Успокаивался тем, что бобыль-«сиделец» невредим остался — отделался легким испугом.
А «крутой» приехал только через час после того как узнал о разбое, только после того как сам вызвал полицию и издалека убедился что они подъехали к дому. Хотя остальные (я и еще один «сосед по квартире») были через 20-30 минут и оперативно посовещавшись, решили полицию не вызывать — материальные потери были не значительны.
Мораль из этой истории:
1. Бэкапы хранить в разных местах, особо ценную информацию не лениться дублировать несколько раз
2. Аккуратней выбирать с кем жить под одной крышей
3. Даже если ты «Рэмбо», банальное «кто там?» может лучше уберечь
4. Полиция если захочет, может работать, но чаще всего не хочет, иногда если нужно, надо помогать ей «хотеть»
5. И вообще иногда лучше молчать.
Из необычного — разбойное нападение.
4 парня (2 студента, 2 вчерашние студенты) снимали 3-комнатную квартиру.
Один из них «наплел» малознакомой девушке, что крутой неимоверно и имеет огнестрел.
Однажды вечером, 14 февраля, когда все были в городе на любовных фронтах, дома остался один из нас (не «крутой») девушки не имевший.
Далее с его слов: позвонили в дверь, он как человек крупного телосложения без всякой опаски открывает дверь и через секунду понимает что у его живота находится далеко не тупой предмет. Далее его заталкивает в квартиру 5-ро бугаев, связывают, сажают на стул, пытаются выяснить где лежит ствол, при этом планомерно обыскивают всю квартиру. Не найдя никакого оружия, его развязывают и быстро уходят прихватив все более-менее ценное, что попало под руку.
Итог получасового просиживания на стуле: унесли у кого-то деньги (немного), у кого-то одежды, и у меня — два харда по терабайту, довольно дорогие по тем временам. Данные было жаль больше всего.
Успокаивался тем, что бобыль-«сиделец» невредим остался — отделался легким испугом.
А «крутой» приехал только через час после того как узнал о разбое, только после того как сам вызвал полицию и издалека убедился что они подъехали к дому. Хотя остальные (я и еще один «сосед по квартире») были через 20-30 минут и оперативно посовещавшись, решили полицию не вызывать — материальные потери были не значительны.
Мораль из этой истории:
1. Бэкапы хранить в разных местах, особо ценную информацию не лениться дублировать несколько раз
2. Аккуратней выбирать с кем жить под одной крышей
3. Даже если ты «Рэмбо», банальное «кто там?» может лучше уберечь
4. Полиция если захочет, может работать, но чаще всего не хочет, иногда если нужно, надо помогать ей «хотеть»
5. И вообще иногда лучше молчать.
Я терял данные на рейд 5 уже 2 раза. Но, к счастью, оба раза у меня были бэкапы. Оба раза очередной винт вылетал во время восстановления рейда, что и становилось причиной смерти рейда. С тех пор я больше не использую этот тип рейда.
У нас был случай, когда «полетела»(подробностей не вспомню) ФС ext3 на которой находилась БД системы тикетов Trac. Был, примерно, полугодовой давности бэкап, но, поскольку система(Trac) использовалась крайне активно(контроль задач сотрудников и снабжение). Потерянные данные были критичны. Хорошо вспомнили, что все изменения всех тикетов высылалось на почту руководителя. Выгрузили письма, написали парсер и почти безболезненно восстановили данные. С тех пор относимся к данным гораздо ответственнее.
Потерял доступ к файловому архиву (к одной из свежих копий точнее) когда всунул жесткий в компьютер отца, там была система резервирования BIOS на ЖД, и работала она глючно, не поддерживала диски более 1Tb, благо проблема была известная и народ написал программу для исправления файловой структуры, которая меня спасла.
Терял данные на рейд 5 когда в «датацентре» сломался кондей. Все оборудование пошло на перегрев. Почтовый сервер, через который должно было быть отправлено письмо, что с рейдами появилась проблема отключился сам — у него единственного была аппаратная защита от перегрева.
Теперь в скриптах контроля у меня проверяется и температура на дисках. Если повышение среднее — шлется письмо. Если повышение существенное — дается команда на отключение.
Стоимость носителей и аппаратуры их обработки однако далеко не нулевая.
Делать очень много копий может оказаться слишком дорого.
Для своей конторы остановился на raid на серверах (1,10 или 5)+ежедневный бакап на самосборный сторейдж на диски с raid 5.
Теперь в скриптах контроля у меня проверяется и температура на дисках. Если повышение среднее — шлется письмо. Если повышение существенное — дается команда на отключение.
Стоимость носителей и аппаратуры их обработки однако далеко не нулевая.
Делать очень много копий может оказаться слишком дорого.
Для своей конторы остановился на raid на серверах (1,10 или 5)+ежедневный бакап на самосборный сторейдж на диски с raid 5.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Форс-мажоры, или как люди теряли свои данные