Лично у меня ощущение, что некоторые администраторы своей настольной книгой сделали специздание Остера с вредными советами по настройке бэкапа для оптимистов, не верящих в закон Мерфи.
Сегодня решил выложить свой короткий хит-парад с реальными историями, с которыми приходилось сталкиваться за время работы на стороне сервис-провайдеров и клиентов. После каждого такого случая виновник торжества остро чувствует, что ему в компании больше не рады, и понимает, что самое время обновить резюме на ХХ.
Читайте и мотайте на ус.
Совет 1. Используйте RAID вместо бэкапа
Зачем бэкап, когда есть RAID? Не заморачивайтесь с разворачиванием и настройкой системы резервного копирования, отдельной инфраструктурой для нее и специальным человеком, который будет ее админить. У вас же RAID, а значит есть две копии данных либо хранятся избыточные данные.
Случай из жизни. Данные клиента находились на СХД. Для скорости и надежности на ней был создан RAID-10 из более чем 24 дисков. У СХД также было некоторое количество запасных дисков. Когда произошел отказ одного из дисков в зеркале, СХД заменила отвалившийся диск запасным и принялась восстанавливать содержимое на нем. Оставшийся в строю диск работал за двоих и активно отдавал данные тому новенькому диску, но делал это недолго, буквально 5 секунд. Потом диск не выдержал нагрузки, и произошел отказ всего RAID. В результате данные на всех 24 дисках были потеряны.
Если серьезно. Зеркалирование, дублирование данных, которое лежит в основе работы RAID, не защищает их. RAID нужен для того, чтобы система не останавливалась из-за каждого отказа жесткого диска. RAID – это про доступность, а не про сохранность данных. Он не поможет, если нерадивый администратор или вирус испортил данные. Не обеспечит он и версионность.
В общем RAID – не для бэкапа. Не путайте теплое с мягким.
Совет 2. Складывайте бэкапы на ту же СХД, где находятся исходные данные
Если все-таки решили делать бэкап, не тратьтесь на отдельное хранилище для резервных копий. Современные СХД очень надежные и умные. Берете и выделяете быстрые тома под продуктивные данные, а на медленные складываете резервные копии. Забудьте про правило 3-2-1. Те, кто говорит про него, просто не знают, что так можно.
Используйте возможности СХД до конца!
Случай из жизни. Тут историй много, так как с СХД может произойти все что угодно. Конец у этих историй, правда, одинаковый: отказ СХД и недоступность, а иногда и полная потеря данных. Самые мои любимые истории из серии “человеческий фактор”:
- администратор перепутал и удалил продуктивный LUN;
- начинающий администратор прилепил к СХД на забор воздуха большую наклейку с подробным описанием назначения СХД, ее IP-адреса, краткой инструкцией по включению и выключению, контактами ответственного и пр. очень “нужной” в работе информацией. СХД перегрелась и отказала.
Или вот совсем недавно коллеги рассказали: СХД старой модели долго-долго работала и умерла. Когда ее труп увидели инженеры, они поняли, что такую СХД видели только в музее. Идей, как ее восстановить, тем более – как это сделать быстро, нет.
Если серьезно. Не делайте так. Если делаете, то будьте морально готовы к тому, что останетесь без исходных данных и без бэкапов на неопределенное время.
Совет 3. Откажитесь от бэкапа сервера и базы данных системы резервного копирования
Бэкапить сам сервер и базу данных резервного копирования? Зачем? У вас уже есть бэкапы, как-нибудь восстановитесь. Если сервер резервного копирования прикажет долго жить, то просто развернете все заново, импортируете туда файлы с бэкапами. Потом подождете, пока система поймет, что со всем этим хозяйством делать, и восстановит базу данных с информацией о заданиях, расписании, объектах резервного копирования и их расположении, месте хранения бэкапов. Не беда, что сначала вы потратите время на восстановление системы резервного копирования и только потом начнете приводить в чувство упавшую инфраструктуру.
Случай из жизни. На одном LUN СХД размещались исходные данные и сервер резервного копирования. Когда LUN стал недоступен и понадобилось восстановиться, оказалось, что бэкапа сервера и базы данных резервного копирования нет. Без последней все резервные копии превратились в чемодан без ручки. Ребятам пришлось разворачивать систему резервного копирования “с нуля”. Благо у используемого решения была возможность воссоздать базу заново через импорт бэкапов в систему. Но был один нюанс: данных для импорта было 100 ТБ. Чтобы собрать новую базу, новая система должна по ним обстоятельно пройти и каталогизировать все данные. В итоге за 1,5 суток было обработано лишь 20%. Потом кто-то им посоветовал импортировать только full бэкапы (самые большие файлы), и дело пошло быстрее, но потерпевшие уже потеряли много времени и нервов.
Если серьезно. Чтобы быть во всеоружии, когда сервер резервного копирования потерян, нужно предусмотреть два момента:
- бэкап сервера и базы данных резервного копирования (
резервирование резервного копирования). В каких-то решениях достаточно развернуть систему заново и импортировать в нее файлы бэкапов. То есть наличие бэкапа базы данных с заданиями, объектами резервного копирования и пр. не столь критично. Так, например, устроено у Veeam.
С другими без базы данных не обойтись (Symantec). Если она не бэкапилась, придется потратить время на ее восстановление.
Для третьих – после потери базы остается только обратиться к техподдержке вендора (Commvault).
- заранее продуманный план по Disaster Recovery для сервера резервного копирования на случай отказа основного сервера/площадки. Многие вендоры систем резервного копирования в документации предлагают варианты по организации Disaster Recovery сервера резервного копирования, например: Veeam, Commvault.
Совет 4. Не тестируйте восстановление из резервных копий
Бэкап – не для восстановления, а для того, чтобы просто был и грел администратору душу самим своим существованием. Главное – настроить резервное копирование, а дальше все точно будет бэкапиться так, что вы сможете без труда восстановить и виртуальную машину, и базы данных, и приложения. Во всех случаях восстановленные данные будут целостны и невредимы.
До “часа Ж” RTO останется тайной для администратора и для начальства. Зато потом для всех будет сюрприз.
Еще лучше, если никто, кроме администратора, не знает, где лежат бэкапы, а сценарий восстановления есть только в его голове. Пусть коллеги попробуют свои силы в импровизации.
Случаи из жизни. Таких историй тоже много, вот одна из самых типичных. Жила-была база данных по имени prod. Инженер резервного копирования как положено поставил ее на бэкап. В один прекрасный день случился сбой, и администраторы восстановили базу рядом с названием prod1. Продуктив соответственно стал жить на prod1. Инженер резервного копирования про это ничего не знал, поэтому prod1 на бэкап не поставил. Старая база prod продолжает бэкапиться. Когда наступает необходимость восстановиться из бэкапа, оказывается, что его нет. Данные за последние 3 месяца потеряны.
Похожая история происходит, когда БД переезжает на новые диски или сервер. Проблема во многом организационная, но и ее можно избежать, если периодически проводилось тестовое восстановление из резервной копии с участием владельца системы.
Если серьезно. После настройки системы резервного копирования, проведите хотя бы раз тестовое восстановление. Дальнейшее расписание тестов зависит от объекта бэкапа: как часто он меняется, его размеры и пр. В проверке должен участвовать владелец системы/приложения.
Если не хочется проверять все вручную, то у большинства ПО резервного копирования есть функции автоматизации проверок (например, у Veeam Sure Backup – целостность данных).
Кроме того, у многих ПО есть возможность использовать скрипты для проверки бэкапов, позволяющие проделать какие-то действия после восстановления (загрузить приложения, подключиться к определенным портам, создать объекты в базе и пр.).
Тестовое восстановление поможет получить реалистичную оценку RTO (RTO, полученное расчетным путем, может сильно отличаться от жизни). Также оно поможет выявить пробелы в регламентах по восстановлению, если таковой вообще имеется.
Причин для тестирования бэкапа много, как и рекомендаций по его организации. Об этом подробно расскажу в одной из следующих статей.
Совет 5. Никакой отдельной инфраструктуры под резервное копирование
Систему резервного копирования и инфраструктуру под нее делаем по остаточному принципу. Когда продуктив уже работает, в эту же инфраструктуру и сеть впихиваем и резервное копирование. Пусть все ходит по одному каналу. Не ставьте ограничения на полосу пропускания для заданий резервного копирования, пусть бэкап ест столько ресурсов, сколько хочет.
Случай из жизни. У клиента продуктив и резервное копирование делили между собой один сетевой канал.
Раз в квартал в компании рассчитывался квартальный отчет. Весь процесс занимал более 15 часов, поэтому группа (назовем ее условно “бизнес”) стартует генерацию отчета с утра и получает готовый отчет утром следующего дня. Одним таким прекрасным утром оказывается, что квартальный отчет не сформировался. Расследование показало, что ошибка произошла из-за разрыва соединения с базой данных. Каких-либо видимых технических причин этому не находилось. Через неделю ребята повторно запускают создание отчета, и все получается. Но через полгода проблема повторяется.
Оказалось, примерно в это же самое время другая группа (назовем ее “ИТ”) запускает задание на полное резервное копирование базы. Выполнение задания занимало большую часть сетевой полосы, нагружало базу данных, в результате чего соединение между системой, рассчитывающей отчет, и базой данных обрывалось. Проблему удалось решить после отказа от резервного копирования в день создания квартального отчета.
Если серьезно. Резервное копирование – ресурсоемкая вещь. В идеале под него нужна своя инфраструктура и сеть на выделенном оборудовании. Тогда резервное копирование не будет создавать помех продуктиву, а задания на бэкап и восстановление будут выполняться за приемлемое время.
Заложить отдельную инфраструктуру под резервное копирование легче всего на этапе планирования продуктивного стенда.
Если отделить мух от котлет уже не получается, то можно попробовать выставить ограничения средствами системы резервного копирования (Network Traffic Throttling) или ограничить полосу пропускания с помощью QoS на сетевом оборудовании. Тут главное соблюдать баланс и не “зарезать” полосу для резервного копирования так, что задания будут выполняться по 24 часа.
Совет 6. Не мониторьте
Зачем настраивать почтовые уведомления о том, что очередное задание на бэкап успешно сделано или зафейлилось? Спама в ящике и так хватает. Тем более не нужно следить за состоянием сервера, где работает система резервного копирования.
Меньше знаешь – крепче спишь.
Случай из жизни. У Veeam есть одна особенность: после установки обновления нужно обязательно зайти на основной сервер и запустить этот обновленный Veeam. Он проверит и выдаст список инфраструктурных серверов, требующих обновления. Если какие-то из компонентов инфраструктуры резервного копирования останутся необновленными, то основной сервер не сможет общаться с ними, при выполнении заданий будет выдаваться ошибка. Администратор то ли забыл про этот момент, то ли просто не знал, обновил основной сервер и ушел со спокойной душой на выходные. Оповещения не настроены, поэтому о своей ошибке он узнал только в понедельник, когда понадобились бэкапы, которых не было.
Если серьезно. Настраивайте оповещения о выполненных заданиях и об ошибках. Так вы будете понимать, есть у вас вообще бэкап или у вас закончилось место на диске и складывать уже некуда. В дополнение можно настроить еженедельные отчеты по заданиям и ошибкам, количеству оставшегося места под бэкапы.
Мониторьте доступность самого сервера резервного копирования: хотя бы пингуйте.
Этот список можно продолжать долго, но я, пожалуй, на этом остановлюсь. Делитесь в комментариях своими вредными советами и историями про резервное копирование из цикла “было бы смешно, если б не было так грустно”.
Комментарии (51)
mikkisse
20.04.2017 11:50Я бы посоветовал еще никогда не проверять бэкапы на валидность. Зачем время тратить? бэкап есть — значит рабочий.
alexoron
21.04.2017 12:09Особенно это касается (раньше так было, незнаю как сейчас) продуктов Acronis, когда там ОБЯЗАТЕЛЬНО нужно делать бекап бекапов!
Двойная трата дискового пространтсва и времени.
В свое время это меня очень бесило и не понимал зачем делать двойной бекап, потом забыл о нем навсегда.
Есть и другие системы резервного копирования.
KorP
20.04.2017 12:17+2Мне кажется в основной части этих вопросов проблема даже не в админах, а в руководителях, которые не хотят тратиться на РК, считая что их это никогда не коснётся. Сталкивался с таким несколько раз в небольших компаниях.
5000shazams
20.04.2017 12:44+1да, это отдельная проблема. Вот одна из таких историй, где после того, как прижгло, руководство решило таки инвестировать в инфраструктуру для резервного копирования. https://www.reddit.com/r/sysadmin/comments/63gs2s/update_to_got_hit_bad_tonight/
dmxrand
20.04.2017 18:33+2Вы знаете я как безумный ходил и жаловался КАЖДЫЙ день, что у меня нет диска для резервного копирования. Писал письма. Руководство отмахивалось. И вот в один прекрасный день грохнулся диск. Фирма с оборотом 7млн в день только в 1 офисе встала. Паника была неимоверная. И что вы думаете? Мне сказали: «Это твоя вина. Ты не сумел донести важность».
Про рейд. У знакомого была логика, что рейд это надежно. И что вы думаете? Слетает контроллер. Данные на дисках, но формат рейда никто не понимает (китайский какой, то почти софт рейд)…
Areso
20.04.2017 12:50+1Когда случилось непоправимое на одном из мест моей работы (в рамках политики резервного копирования, впрочем), я задал вопрос про разницу между бэкапом и точкой времени, на которую были потеряны данные и услышал в ответ: «А разницу руками забьют. Сегодня не будут пить чай и обслуживать клиентов, сейчас повесим распечатку и уведомим охрану, чтобы всех приглашали на завтра» оО.
KorP
20.04.2017 13:02+1Да, многим руководителям проще заставить кучу людей перепахивать, чем потратить несколько тысяч на простенькую систему, что бы прикрыть тылы. Грустно это.
rubikon
21.04.2017 14:54+1бизнес ничего личного. зп платится, простой не стоит ничего. а за систему бекапа денег хочет админ. нафиг оно
KorP
21.04.2017 15:36Это то меня и грустит. А я тут про какие то veeam'ы, datadomain'ы, репликацию резервных копий статьи пишу.......:)
rubikon
21.04.2017 15:41да просто когда боссам и прочим важет будт простой и они реально могут оценить потери от простоя, легче на диалог идут.
иногда надо потерять все что понять стоимость спокойствияKorP
21.04.2017 15:46Проработав уже почти 3 года в крупной компании, где такие вещи даже не обсуждаются (в хорошем смысле) я всё-равно ещё чувствую эту боль где руководству пофигу :) При чём даже когда они понимают что стоимость простоя и кол-во головной боли просто огромное :(
Am0ralist
21.04.2017 21:12зп платится, простой не стоит ничего.
Угу, а вот когда после моего ухода из-за грозы один жесткий копыта двинул с кучей данных по аудиту клиентов… Это ж явно было дешевле, чем выделить 10к рублей, которые я просил для бекапов.
Кстати, в конторах восстановление тогда стоило наверно раза в полтора больше.
Да и в другой конторе нам быстренько деньги выделили после того, как 1С-ник убил базу (обновил без бекапов, ага). До того хрен вам был вечный.
Вот бесполезно людям объяснять, распинаешься-распинаешься. Пока данные не угробятся — люди не понимают русских слов. Зато потом «а чего вы нам не объяснили нормально?». Как?
navion
21.04.2017 16:20Везде нужно экономические обоснование, которое и есть тот самый "cool factor" для руководства.
Busla
21.04.2017 00:46+4А что вас удивляет? — это как раз и есть правильный подход: совместно с руководством определить допустимое время простоя.
uzverkms
21.04.2017 16:01Проблема в руководителях только отчасти. Потому что часто проблема в админах, которые на пальцах не могут обосновать необходимость затрат на резервное копирование.
Am0ralist
21.04.2017 21:29+1Если люди далеки от IT, то:
На пальцах — не понимают.
С примерами — не понимают.
Пока разок не потеряется куча данных — не понимают.
Потом же быстро находятся деньги и на новый сервер, и на пачку жестких дисков, и на проги для бекапов.
Что легко объяснимо когнитивными искажениями: вероятность негативного исхода кажется слишком низкой, что ничего не случится — высокой, а так как личного опыта нет, то это служит подтверждению их мнению.
Если уж даже админы делятся на три типа (кто не делает бекапы, кто УЖЕ делает и кто проверяет сделанные), то что говорить о не IT начальстве?
Miller777
22.04.2017 13:46Обновлял периодически 1С на одном военном заводе. Не админ, админа у них нет, просто раз в несколько месяцев обновлял релизы и ставил свежую отчетность.
Периодически говорил: а вот хорошо бы вам под 1С отдельный сервер… Меня не слышали. Зачем? Все же и так работает…
Умер жесткий диск на ПК, где лежалаMiller777
22.04.2017 13:52+2… где лежала база. Хорошо так умер, похоронив все данные.
Вызывают меня. Я нахожу на другом ПК свой бэкап базы, которую делал перед обновлением. Полугодовой давности.
вызывают директора завода, полковника. Тот смотрит на бухгалтеров и говорит: а мне-то что? Хоть умрите тут. Сидите и восстанавливайте, чтоб все было восстановлено. Настоящий полковник, да.
Бухгалтерия — 5 человек две недели до глубокой ночи забивала в старую базу данные за пол-года с бумажных носителей.
После этого был куплен сервер и настроено автоматическое резервное копирование каждую ночь.
Все замечательно доходит через руки.
aik
22.04.2017 14:05Бухгалтерия — 5 человек две недели до глубокой ночи забивала в старую базу данные за пол-года с бумажных носителей.
Сейчас знакомая контора (просто знакомая, я их не обслуживаю) как раз этим самым и занимается, шифровальщика словила, а он им файловые базы 1С обработал.
Бэкапы, теневые копии? Не, мы таких слов не знаем.
Да даже если далеко не ходить — на моей основной работе деньги на сервер бэкапов, про который я говорил и писал два или три года дали только после того, как шифровальщик добрался до главбуха.
Am0ralist
22.04.2017 14:17Для бекапа 1С хватало одной проги, ценой в несколько тысяч. И, собственно, куда их складывать, то есть парочка соседних компов.
Собственно ровно так я сделал на первой работе, ровно так поступил на второй, где был инженером по автоматизации (админом был другой), после того, как программист 1с (который и отвечал за 1с полностью, мы не касались ее совсем в тот момент) убил базу при обновлении. На отдельный сервер мы потом переехали, но программа успешно продолжила бекапить и сервер.Taciturn
22.04.2017 14:52Для бекапа файловой 1С вообще достаточно любого архиватора и простейшего скрипта.
Да и SQL-версию можно просто архивировать, если штатно останавливать SQL-сервер перед архивацией и запускать после.navion
22.04.2017 14:59Даже в SQL Express проще настроить штатный бекап, который сам будет жать архивы. С Postgres ещё проще, ей достаточно консистентного бекапа папки с базой (например, через VSS).
aik
22.04.2017 15:371С беэкапится несколькими халявными скриптами, не обязательно за них деньги платить.
У файловой просто файлы базы копируешь куда-нибудь, у sql'ной я делаю дампы средствами sql плюс выгрузку в dt'шки средствами 1С.Am0ralist
22.04.2017 16:53Естественно можно скриптами. Сейчас у нас, например, другая бд-ка бекапится через скрипты.
Вот только копировать файлы 1С-ки просто так нельзя, так как вначале надо выход из базы всех пользователей сделать на всякий случай.
А прога намного удобнее и платить надо за пару доп.возможностей (так то у нее была и бесплатная версия — уж точно не помню, но на первой работе мне вроде бы хватило ее с головой). Может как раз ради бекапов sql-ной базы купили.
То есть из вариантов:
1) каждая новая версия скрипта называется «теперь уж точно все работает как надо»
2) удобная прога за 2к рублей от того, кто ее сделал для себя и собрал больше грабель на пути
я предпочел выбрать тот, который будет работать практически не зависимо от того, в руки кого она попадет в дальнейшем (от эникея до продвинутого вин.админа). Я ж не собирался работать там вечно.aik
22.04.2017 17:19Вообще по копированию файловых баз я специалист небольшой, у меня их мало и по ночам там никого не бывает, так что всё нормально копируется.
Из sqlной же базы я народ не выгоняю, сперва делаю дамп средствами БД, потом его восстанавливаю рядышком и оттуда уже средствами 1С сливаю dt. В основной базе при этом спокойно продолжают работать.
А вторая копия базы часто пригождается, когда народ хочет поиграться, не трогая основную базу.
На счет версий скрипта — ну разве что при обновлении платформы меняю путь к исполняемому файлу 1С. А sql'ные скрипты вообще не трогаю, там ничего менять не нужно.
Am0ralist
20.04.2017 16:15+3Совет 1. Используйте RAID вместо бэкапа
Из встреченного на жизненном пути, сразу восстановленную хронологию:
Стоял обычный комп в бухгалтерии с зеркальным рейдом.
В какой-то момент один диск из рейда выпал видимо из-за большого количества бедов, хотя в смарте их не было, пока викторией не прогнали. Но так как за рейдом никто не следил, то комп проработал в таком режиме с одним диском пару лет, пока однажды после очередного пропадания электричества не перестал грузиться.
Админ, зайдя в биос увидел, что SATA в режиме AHCI вместо рейда оказался и без всякой задней мысли просто вернул настройку на место. Оба диском рейд-контроллером увиделись, подцепились без проблем и с одного диска информация отзеркалилась на другой. Причем за основу был взят сбойный диск. С устаревшей на два года информацией…
Случай два:
Сервер от супермикро. С встроенным в интеловскую мать рейдконтроллером. На SAS дисках был поднят зеркальный рейд. Сервер отключили, подключили в Sata порт обычный винт, после включения сервера — рейдконтроллер сказал, что никакого рейда он не помнит и никогда ничего подобного там не было вообще. При попытке же опять организовать рейд, вся структура с обоих дисков была удалена полностью без каких-либо предупреждений и вопросов. Действительно, зачем же кому-то может потребоваться переставить диски с одного сервера на другой дабы собрать рейд обратно и снять с него данные? Пфф, глупость какая.
msolovyev
20.04.2017 17:42+2Не так давно на рынке было полно материнских плат с софт-рейдами и даже NAS-ов, в которых можно было собрать зеркало из дисков. При отказе одного из дисков вы, что логично, меняли дохлый диск на живой, и… ребилда не следовало, потому что функция ребилда рейда реализована не была!
Это в плюс того, что нужно тестировать :)dmxrand
20.04.2017 18:34+1Недели две назад в на один форум обратился человек. Он собрал рейд и стал тестировать как система выдерживает сбои. Жал ресет. В итоге убил один диск и через пару дней умер второй.
navion
20.04.2017 19:53Складывайте бэкапы на ту же СХД, где находятся исходные данные
Прямо рекламный слоган NetApp и прочих любителей снепшотов.
Для третьих – после потери базы остается только обратиться к техподдержке вендора (Commvault).
Есть четвёртые, у которых все метаданные хранятся в базе (TSM/Spectrum Protect) и при её утрате даже поддержка не спасёт. RPO базы приходится учитывать задавая срок хранения объёктов в пуле (REUSEDelay), чтобы после её восстановления остались данные на диске.khanid
20.04.2017 23:55Но ведь снэпшот — не бэкап. Сколько говорено уже. И в части гипервизоров функция снэпшота — не средство бэкапа.
onix74
20.04.2017 20:22+1Все важные обновления, изменения, установки и настройки делайте в пятницу после обеда, а ещё лучше — перед какими-нибудь длинными праздниками (типа новогодних каникул). И со спокойной совестью поезжайте куда-нибудь отдохнуть. Желательно туда, где нет телефонной связи и интернета. :-)
Miller777
22.04.2017 13:57Плюсую. Еще лучше — поздно вечером, в замученном состоянии, и чтоб некому было даже в минимальном объеме проверить работу.
SlavikF
20.04.2017 21:34+1Поделюсь одной весьма полезной штукой, появившейся в последних файловых системах, о которых почему-то пока ещё редко упоминают, говоря о backup.
Преположил, что вы настроили backup, и делаете две копии, и даже offsite, и проверяете их.
Но случилось так, что часть этих данных была удалена / испорчена / отредактирована… НО ЭТО СРАЗУ НЕ ОБНАРУЖИЛИ.
И backup забэкапил скомпроментированные данные. Приплыли…
Так вот в ZFS, BTRFS есть снэпшоты — крутая штука. Позволяет вернуться к состояниям любых файлов в прошлом, для которых есть спэпшоты. Я делаю снэпшоты каждую неделю (хотя можно делать хоть каждые пять минут).
Конечно, совсем правильно делать снэпшоты не на продуктиве, а на бэкапе, но на современных файловых системах снэпшоты практически не тормозят систему и очень удобны.
И да, конечно, снэпшоты — это не бэкап, может быть только полу-бэкап (решает проблему компроментации данных, но не решает потерю физического носителя — дисков или контроллера).aik
21.04.2017 07:00+1По-моему, это давно уже всеми используется для оперативного восстановления данных. Не замена полного бэкапа, конечно, просто удобное дополнение.
В windows зовется «предыдущие версии файлов».
vladimirad
20.04.2017 22:45Интересный момент с RAID 10 — как конкретный контроллер понимают эту 10-ку,
0+0=1 или 1+1=10 этот момент не описывается в документации. иногда может быть важен.aik
21.04.2017 07:03Обычно видно в админке. Но особой разницы нет, всё равно вылет двух винтов может пережить только с определенными оговорками, просто на оба варианта оговорки будут разные. :)
Tabletko
21.04.2017 10:49Не совсем так raid10 переживает вылет 2-ух дисков в разных парах, а raid 01 — при вылете одного. Второй вылет в другой паре для него фатален, так как первый страйп уже развалился.
aik
21.04.2017 11:0310 — страйп зеркал, информация переживёт вылет одного диска в каждой паре, умрёт, если вылетят оба диска в одной паре.
01 — зеркало страйпов, информация переживёт вылет двух дисков в одной паре, умрёт при вылете двух дисков в разных парах.
PS. Это про четыре диска в массиве, конечно. При большем количестве дисков математика уже немного другая начинается.Tabletko
21.04.2017 12:07Я не пытаюсь с Вами спорить. Мы, видимо, об одном и том же говорим, но с разных сторон. Я веду к тому, что в случае Raid01 смерть второго диска в паре не важна, так как страйп уже умер.
vladimirad
21.04.2017 13:47Написал потому, что видно одно, а по факту другое. Документация хорошо, а эксперимент — всему голова. Накатил систему, потом проверь. У меня был сервак, который не пережил вылет одного из четырех дисков.
aik
21.04.2017 14:00А как проверить? Вот у меня в админке видны два зеркала в страйпе. Как мне убедиться, что всё устроено именно так, а не два страйпа в зеркале?
Vld_Sergio
21.04.2017 21:59Со временем почти все приходят к мысли сначала тестировать на тестовой сборке, а уж потом выносить в продакшн. Т.е. условно говоря — взяли сервер, собрали RAID, накатили боевые базы и софт (из бэкапа, хе-хе), прогнали на все возможные варианты крэша, потом снесли начисто всё, и заново установили, настроили, перенесли базы… и в продакшн. ))
aik
22.04.2017 06:34А как вы всё же проверите, 10 у вас или 01?
Видно два зеркала в страйпе. Выдернули вы два диска из одного зеркала, но массив продолжает работать. Какой вывод? У вас страйп в зеркале? А может просто софтинка врёт по другому и вы выдернули диски из разных зеркал?Vld_Sergio
22.04.2017 09:37Ну вот придумать безукоризненный план тестирования новых серверов как раз самое сложное.
В случае софтрейдов, например, можно получить s/n каждого тома, и, выдернув диск, посмотреть, какой серийник на корпусе. И так далее, было бы желание качественно протестировать.
aik
21.04.2017 07:06+1У меня как раз на днях вылетел один из дисков в десятом рэйде, а менеджер рейдов мне не сообщил. Заметил случайно, когда память в сервере добавлял. Посмотрел потом в менеджере — он видел, что диск вылетел, но считал это нормальным состоянием, зеленые галочки и всё такое. Похоже, что софтовый глюк в старой версии. После обновления сразу заорал о том, что всё плохо, диск снимают, клиент уезжает.
avlag
21.04.2017 10:50+1Во вредном совете 4 случай из реальной жизни (чистейшая административная ошибка/несогласованность действий) не имеет ни малейшего отношения к системам автоматизированной проверки корректности бэкапа. В частном случае к Veeam Sure Backup.
В этом случае из жизни проверка корректности бэкапа будет пройдена успешно.
Это примерно как рассчитывать на устранение пользовательской ошибки работы с БД средствами RAID'а
relia
21.04.2017 12:55+3К 4-му пункту еще одна история:
Упал интернет-магазин, есть бекап месячной давности (!), но из него восстановить базу не получается — что-то как-то сильно ругается и процесс обрывается даже не воссоздав всю схему данных. Клиент обратился ко мне — выяснил, что в бекапе 4 или 5 таблиц закольцованы по foreign key. Кто, где, когда и почему так сделал — неизвестно, т.к. модернизацией магазина занимались за все его жизнь несколько команд «разработчиков» с Upwork и никто документацию не вел. Отдельного бекапа схемы данных конечно тоже нет.
Пока вытащил схему данных из бекапа (к упавшему продакшену доверия нет), руками закомментировал эти ключи, восстановил схему, восстановил закольцованные ключи (зачем они? пусть разработчики разбираются — я тикет оставил), накатил данные из бекапа… Магазин не работал больше 16 часов (из них на меня пришлось почти 6 часов, из которых 2,5 часа ушло на операцию восстановления данных).
Через 4 месяца заглянул на тот сервер: бекапы собираются примерно раз в месяц в ручном режиме, закольцованные ключи на месте… Скорее всего этот магазин станет моим постоянным клиентом :)
erwin_shrodinger
Нельзя не вспомнить)
https://hi-news.ru/internet/oshibochka-vyshla-servis-dlya-xraneniya-koda-gitlab-sluchajno-udalil-pochti-vse-dannye.html