Там были довольно странные обстоятельства. Если коротко, то имела место репликация VEEAM, на фоне бэкапа на полностью заполненное хранилище, и оно так висело несколько дней. Мне не удалось установить, что именно из этого всего привело в такой ситуации. Но походу, если раз в полчаса примаунчивать-отмаунчивать диск, это в итогеможет плохо кончиться.
Для таких объемов, имхо, репликация не очень, лучше инкрементальный бэкап + синтетический полный раз в какое-то время. Это быстрее и стабильнее. Но время восстановления из бэкапа будет гораздо больше, чем из реплики. Можно конечно запустить ВМ из бэкапа напрямую, но я не помню, перенесутся ли изменения после полного восстановления в восстановленную копию.
Все это у меня было с esx 5 и вим 5 или 6, как сейчас дела тут обстоят не знаю.
Да, проблема с псевдо-неконсолидированным диском мне известна, и в том числе и она там возникала на других машинах в этот момент, но не на проблемной. Серьезно, что именно привело к поехавшим разделам - совершенно непонятно. Тикет что ли в вим написать... Хотя я даже не знаю с чего начать такой опус. "Бэкапя на хранилище с переполненным диском, на фоне репликации с помощью прокси, смонтированной на этом переполненном диске, которая по этой причине встала на паузу..."
Репликация там запущена для опять-таки довольно специфической цели. Собственно, она идет параллельно с основным бэкапом. Тем же вимом. фулки по выходным, инки по ночам.
При запуске прямо с бэкапницы падает производительность по дискам. Это, в принципе, хорошее и главное быстрое решение, но подходит только для точечных случаев. Кстати по-моему там "окончание восстановления" подразумевает просто ухуячивание этой виртуалки. Нужна, дескать - так клонируй всферой перед этим. Не нужна - ну и хуй с ней.
Также пользуюсь Вимом, также сталкиваюсь с "волшебными снапшотами".
Как вариант решения - простенький скриптик в заббиксе, который парсит все ноды вмвары, на предмет наличия снапшотов вне времени работы бакапов. нашел - алярмабля!
далее виртуалка просто "лечится" и все дела.
ибо было несколько крайне неприятных историй, один раз с корп почтарем. потерял переписку за несколько дней, чуть небыл уволен ))
Пощупай аппаратные снапшоты, если у тебя СХД их поддерживает.
Снапшоты силами ВМ создаются буквально на секунды, а потом уже делается снап на СХД. И Veeam работает с ним.
Так эти снапшоты как раз об бэкапов/реплик остаются, поэтому будут во времени работы бэкапов.
Млять... Эта почта... У меня 2.5 Тб почты... Я запарился подбирать бэкапер. Вимом не вариант был, т.к. искать в его бэкапах один файл слишком долго и накладно. К тому же нужно чтобы как минимум полгода была глубина бэкапа с возможностью восстановления до любого дня (спасибо хоть, что не до минуты :-D). Остановился на rsnapshot, пока он лучше всего себя показал.
Возможно, зависит от почтаря. Мои полтора терабайта вим со свистом чекает, и умеет восстанавливать ящики и письма отдельно - но на эксчендже. А человек о каких-то файлах говорит...
Ну так и у нас чанга в меру свежая. Veeam Explorer for Exchange нас устраивает целиком и полностью, в принципе.
У меня почтарь на linux, postfix. Его вим бэкапит только как ВМ целиком, файло (1 файл = 1 письмо с вложениями) там искать не просто в его бэкапах. Поэтому и приходится rsnapshot'ом бэкапить.
Ну, серебряной пули не существует. В твоём случае - rsnapshot - более эффективный инструмент. :-)
Как вариант, можно написать. Описать все подробно, на сколько возможно и известно. У меня тоже было, что бэкапы на забитый сторедж пытались делаться, но я просто получал фэйлы от вима.
Я бы не стал делать параллельно бэкапы и репликацию. Хотя современный вим может это как-то определенным образом научили обрабатывать. Но вот на 5м виме я бы точно не стал делать такого, там, на сколько помню, не было это предусмотрено (хотя могу и ошибаться).
Это да, конечно будет падать производительность. По суди это же виртуальное хранилище, которое монтируется к esx'у по nfs и с него идет чтение.
Там запись идет в другой виртуальный диск, вроде по принципу Copy-On-Write. Как когда снапшот есть и пишется все в снапшот, а читается с диска. Поэтому потом слить новую инфу с восстановленным бэкапом технически возможно, но вот было ли в вип 5 реализовано это я не помню, а как в более свежих версиях не знаю.
Я бы тоже бы не стал, но, блин, нужно "мягко" переезжать на удаленное хранилище, и бэкапы тоже нужны, как бы. Декабрь все-таки. Вот одолжил бы мне кто-нибудь штук пять пролиантовских лезвий текущего поколения...
А разнести по времени бэкапы и реплики нельзя?
Ох... Я бы сам от таких лицух не отказался :-D
Если же долго хранить снапшоты, то попадает производительность дисковой подсистемы ВМ.На таких объемах имеет смысл пользоваться аппаратными снапшотами СХД. Благо практически все крупные вендоры с тем же Veeam'ом умеют работать.
Это все верно и даже правильно, согласен. Но бывает и так, что нет такой возможности. У меня, например, были IBM'овские DS'ки с икспашенами и они не умели такого. Не помню почему, то ли сами по себе не могли, то ли esx\veeam с ними не умели так работать.
Современные СХД зачастую умеют виртуализовывывать хранилища. Есть, конечно HCL, но там достаточно много железок.
Это все верно. Но как-никак, а есть где просто не дают денег на нормальные схд, есть где не обновляются годами. И т.д. Вот у нас бывший начальник купил DS'ки, хотя ему говорили, что не стоит, теперь вот живем с тем, что есть.
У нас серверный парк, считай впервые обновился за 6 лет.
Так что не показатель. Вернее, вопрос умения выбивать из бизнеса деньги.
Я в бюджетниках. Мы не можем купить что-то конкретное, только по конкурсу. Сейчас нужны новые сервера, потом ленточное хранилище, потом уже будут схд новые.
Прописываешь какой-нибудь функционал, подходящий только к конкретному вендору, и делов то...
Попроси чтобы интеграторы ТЗ написали под конкретного вендора. Они умеют.
Условно говоря, прописываешь, чтобы в СХД были ASIC'и, например. И вариантов всего два - HPE и Huawei.
Ну или какой-нибудь Булат - который по сути и есть Huawei. Зато можно отмахнуться от всяких DEPO.
Да, знаю. Сейчас примерно так и делаем.
Писал о не очень давних временах. Тогда другой начальник был, он по своему делал, видать под "своих".
Лига Сисадминов
2.3K постов18.8K подписчиков
Правила сообщества
Мы здесь рады любым постам связанным с рабочими буднями специалистов нашей сферы деятельности.