Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 892 сообщений
Cообщения с меткой

резервное копирование - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Реализация восстановления после аварий

Пятница, 30 Сентября 2016 г. 23:03 (ссылка)

Сергей Бурладян (Avito)



Сергей Бурладян



Всем привет, меня зовут Сергей Бурладян, я работаю в «Avito» администратором баз данных. Я работаю с такими системами:







Это наша центральная база 2 Тб, 4 сервера — 1 мастер, 3 standby. Еще у нас есть логическая репликация на основе londiste (это из Skytools), внешний индекс sphinx’а, различные выгрузки во внешние системы — такая, как DWH, допустим. Еще у нас есть собственные наработки в области удаленного вызова процедуры, xrpc так называемая. Хранилище на 16 баз. И еще такая цифра, что наш бэкап занимает 6 часов, а его восстановление — около 12-ти. Мне хотелось бы, чтобы в случае различных аварий этих систем простой нашего сайта занимал не более 10-ти минут.



Если попытаться представить различные связи этих систем, то они как-то так выглядят:







И как все это не потерять при аварии?



Какие могут быть аварии?







Я рассматриваю, в основном, аварии потери сервера, и плюс для мастера может быть еще такая авария, как взрыв данных.







Начнем.







Допустим, какой-то администратор по ошибке сделал update без where. У нас такой случай был несколько раз. Как от нее защититься? Мы защищаемся с помощью того, что у нас есть standby, который применяет WAL’ы с задержкой в 12 часов. Когда произошла такая авария, мы взяли эти данные со standby и загрузили обратно на master.







Вторая авария, которая может произойти с мастером — это потеря сервера. Мы используем асинхронную репликацию и после потери сервера мы должны сделать promote какого-то standby. А т.к. у нас репликация асинхронная, то необходимо выполнить еще различные процедуры для восстановления связанных систем. Мастер у нас центральный и является источником данных, соответственно, если он переключается, а репликация асинхронна, то мы теряем часть транзакций, и получается, часть системы — в недостижимом будущем для нового мастера.







Руками это все сложно сделать, поэтому нужно сразу делать скриптом. Как выглядит авария? Во внешних системах появляются объявления, которых уже нет на мастере, sphinx выдает при поиске несуществующие объявления, sequences прыгнули назад, логические реплики, в частности из-за этого тоже, перестали работать (londiste).







Но не все так плохо, это все можно восстановить. Мы посидели, подумали и спланировали процедуру восстановления. В частности, DWH мы можем просто выгрузить заново. И непосредственно, т.к. у нас простой 10 минут, то на месячных отчетах изменение этих потерянных items просто не видно.



Как восстанавливать xrpc? У нас xrpc используется для геокодинга, для вызова асинхронных процедур на мастере и для расчета кармы пользователя. Соответственно, если мы что-то загеокодили, т.е. из адреса превратили его в координаты на карте, а потом этот адрес пропал, то ничего страшного, что он останется загеокоденным, просто, мы во второй раз не будем такой же адрес геокодить, соответственно, не надо ничего восстанавливать. Локальный вызов процедуры асинхронный, т.к. он локальный, он расположен на одном сервере базы, даже на одной базе, и поэтому, когда базу мы переключили, она консистентна. Тоже ничего не надо восстанавливать. Карма пользователя. Мы решили, что если пользователь сделал что-то плохое, а потом произошла авария, и мы потеряли эти плохие items, то карму пользователей можно тоже не восстанавливать. Он же сделал эти плохие вещи, пускай у него и останутся.







Sphinx сайта. У нас есть два sphinx — один для сайта, другой для backoffice. Sphinx, который сайта, реализован таким образом, что полностью перестраивает каждые 10 минут весь свой индекс. Соответственно, произошла авария, восстановились, и через 10 минут индекс полностью перестроен и соответствует мастеру. А для backoffice мы решили, что тоже не критично, мы можем зарефрешить часть объявлений, которые изменились после восстановления, и плюс раз в месяц мы полностью перестраиваем весь backoffice sphinx’овский, и все эти аварийные items будут почищены.



Как восстанавливать sequences, чтобы они не прыгали назад? Мы просто выбрали важные для нас sequences, такие как item_id, user_id, платежный первичный ключ, и мы после аварии их прокручиваем вперед на 100 тыс. (мы решили, что нам будет достаточно).



Логическую репликацию мы восстанавливаем с помощью нашей системы, это патч для londiste, которое делает UNDO для логической реплики.







Патч Undo — это такие три команды. Непосредственно сама команда и плюс две команды добавления/удаления Undo для логической реплики. И еще replay в londiste мы добавили флаг, чтобы он передавал TICK_ID с мастера в сессионную переменную Postgres’a.







Это нужно непосредственно в самой реализации Undo, т.к. она реализована — просто это триггеры на всех таблицах subscriber’а. Триггер пишет в табличку истории, какая непосредственно операция произошла. В целевой таблице. Этот переданный tick_id с мастером он запоминает в этой записи. Соответственно, когда произошла авария, логическая реплика оказалась в будущем, и ее нужно почистить, чтобы восстановить изменения, которые из недостижимого будущего. Это делается с помощью выполнения обратных запросов, т.е. для insert мы делаем delete, для update мы обновляем предыдущими значениями, ну, а для delete — insert.







Руками мы все это не делаем, мы делаем с помощью скрипта. Какая здесь особенность нашего скрипта? У нас три асинхронных standby, соответственно, прежде чем переключаться, нужно выяснить, какой из них наиболее близкий к мастеру. Далее, мы выбираем этот standby, дожидаемся, пока он проигрывает оставшиеся WAL’ы из архива, и выбираем его для будущего мастера. Дальше, мы используем Postgres 9.2. Особенности этой версии в том, что чтобы standby переключились на новый промоушн и мастер, их приходится останавливать. По идее, в 9.4 это уже можно не делать. Соответственно, делаем promote, сдвигаем sequences вперед, выполняем нашу процедуру Undo, запускаем standby. И дальше вот тоже интересный момент — нужно дождаться, когда standby подключится к новому мастеру. Мы это делаем с помощью ожидания появления timeline нового мастера на соответствующем standby.







И вот, оказывается, в Postgres нет такой функции SQL’ной, невозможно понять timeline на standby. Но мы решаем это таким способом, оказывается можно подключиться по репликационному протоколу Postgres’а к standby, и там после первой команды standby сообщит свой, выделенный красным, timeline.



Такой у нас скрипт восстановления мастера.







Пойдем дальше. Как мы восстанавливаемся непосредственно, когда внешние системы какие-то разваливаются. Например, standby. Т.к. у нас три standby, как я уже говорил, мы просто берем, переключаемся на оставшийся standby, если один из них падает. В крайнем случае, даже если мы потеряем все standby, мы можем переключить трафик на мастера. Здесь будет теряться часть трафика, но, в принципе, сайт будет работать. Здесь еще была такая хитрость — сначала я все время создавал новые standby из бэкапа, потом у нас появились сервера SSD’шные, а я все так же продолжал восстанавливать из бэкапа standby. Потом оказалось, что если брать из бэкапа, восстановление занимает 12 часов, а если просто взять pg_basebackup с какого-либо работающего standby, то это занимает гораздо меньше времени. Если у вас несколько standby, можно попробовать у вас это проверить.







Если ломается sphinx сайта. Sphinx сайта у нас написан таким образом, что он полностью перестраивает весь индекс, а sphinx сайта — это все активные объявления сайта. Сейчас все 30 или 35 млн. объявлений на сайте индексируются вот этой системой. Индексация идет с отдельной реплики логической, она подготовлена специально для индексации и сделана так, что там все разложено в памяти, и происходит индексация очень быстро, поэтому мы можем делать индексацию каждые 10 минут, полностью с нуля. Реплик логических у нас — по паре. И если мы теряем реплику, мы переключаемся на ее резерв. А если что-то случилось со sphinx, то через 10 минут он полностью переиндексируется, и все будет хорошо.







Как можно восстановить экспорт в DWH? Допустим, что-то мы экспортировали, на DWH произошла авария, мы потеряли часть последних данных. Экспорт DWH у нас идет через отдельную логическую реплику, и на этой реплике хранятся последние четыре дня. Мы можем просто руками заново вызвать скрипт экспорта и выгрузить все эти данные. Плюс там есть еще архив в полгода. Либо, в крайнем случае, т.к. у нас несколько standby, мы можем взять один из них, поставить на паузу и заново выгрузить, вообще, все данные с мастера в DWH.







Хrpc у нас реализован поверх pgq (это Skytools), и благодаря этому мы можем делать такие хитрые штуки. Pgq — это, по сути, просто таблица в базе, в ней хранятся события. Она приблизительно так выглядит, как на рисунке. Там есть время события и id транзакции. Когда мы восстановили клиента xrpc, мы можем взять и сдвинутся назад в этой очереди, и проиграть заново те события, которых нет в получателе.







Xdb — это у нас есть хранилище из нескольких баз. 16 баз расположены на восьми машинах. Это хранилище у нас резервируется следующим образом — просто бинарная репликация Postgres настроена с одной машины на другую. Т.е. первая машина резервируется standby’ем на второй, вторая на третьей, соответственно, восьмая на первой. К тому же, проигрывание WAL’ов, там также происходит задержка в четыре дня, т.е., по сути, у нас есть за четыре дня бэкап любой из этих нод.







Сейчас я подробно расскажу про реплику, что это такое. Логическая реплика построена у нас на основе возможностей Postgres, это есть view’ха на мастере и deferred триггер на нужных таблицах. По этим триггерам срабатывает специальная функция, которая пишет в отдельную табличку. Ее можно считать как материализованное представление. И дальше эта табличка средствами londiste реплицируется на логическую репку.







Непосредственно это как-то так выглядит, я не буду на этом подробно останавливаться.







А сам сервер логической реплики, зачем это, вообще, нужно? Это отдельный сервер. Он характерен тем, что там все находится в памяти, т.е. shared_buffers такого размера, что вся эта табличка и ее индексы полностью в него влезают. Это позволяет на таких логических репликах обслуживать большую нагрузку, в частности, например, одна репка обслуживает у нас 7000 транзакций в секунду, и 1000 событий в очередь с мастера в нее льется. Т.к. это логическая реплика реализована средствами londiste и pgq, то там есть удобная штука — отслеживание, какие транзакции уже проигрались на этой логической реплике. И вот на основе этой штуки можно делать такие вещи как Undo.







Я уже говорил, что реплик у нас две штуки, мы можем восстанавливаться, просто переключаясь. Если одна реплика потерялась, переключаемся на вторую. Это возможно из-за того, что pgq позволяет подписать на одну очередь несколько потребителей. Репка упала, и дальше нам нужно восстановить ее копию. Если это делать просто средствами londiste, то это занимает у нас сейчас для репки сайта 4 часа, для сфинкса — 8 часов, т.к. там вызываются триггеры, которые нарезают данные для удобной индексации сфинксу, и это все очень долго. Но оказалось, что есть другой способ создать упавшую репку — можно сделать pg_dump с работающей.







Но если просто сделать pg_dump и запустить на него londiste, то это все не заработает, потому что londiste отслеживает и на мастере, и на логической реплике текущую позицию проигранной транзакции. Поэтому там еще нужно делать дополнительные шаги. Нужно поправить после восстановления dump’а на мастере tick_id, чтобы он соответствовал тому tick_id, который на восстановленной репке. Если так, через pg_dump копировать, то все это занимает не более 15 минут.







Сам алгоритм как-то так выглядит.







Backup предназначен для защиты от аварий, но непосредственно с самим бэкапом тоже могут происходить аварии. Например, в Postgres команда архивирования WAL, там не указано, что нужно делать fsynk, когда WAL записывается в архив. Но это важная вещь и позволяет защититься от, допустим, аварийной перезагрузки архива. К тому же, у нас бэкап еще резервируется тем, что он копируется во внешнее облако. Но в планах: мы хотим сделать два активных сервера архива, чтобы archive_command писал на оба WAL. Еще можно сказать, что сначала мы экспериментировали с pg_receivexlog для того, что получать непосредственно на самих серверах архива WAL, но оказалось, что в 9.2 его практически невозможно использовать, потому что он не делает fsynk, не отслеживает, какие WAL он уже получил с мастера, какие можно чистить при checkpoint. Сейчас в Postgres это доделали. И, возможно, в будущем мы будем использовать не archive_command, а pg_receivexlog все-таки.







Мы не используем streaming у себя. Т.е. то, про что я рассказывал, это все основано только на WAL архиве. Это было сделано из-за того, что сложно обеспечить при streaming еще и архив, т.к. если, например, берем архив со standby, бэкап завершился, а мастер еще не успел заархивировать все эти WAL’ы, нужные для восстановления бэкапа. И мы получаем битый бэкап. Это можно обойти, если у нас, допустим, standby, с которого мы берем бэкап, отстает на 12 часов, как у нас. Либо — в Postgres 9.5 сделали такую настройку archive_mode=always, при которой такой проблемы не будет. Можно будет брать спокойно бэкап со standby и получать WAL’ы непосредственно тоже со standby в архив.







Недостаточно делать просто бэкап, его еще нужно проверять, все ли там корректно у нас забэкапилось. Мы это делаем на тестовом сервере, и для этого написали специальный скрипт проверки бэкапа. Он основан на том, что проверяет после восстановления сервера и запуска сообщения об ошибках в логе сервера. И для каждой базы, восстановленной на кластере, вызывается специальная проверяющая функция check_backup, которая выполняет дополнительные проверки. В частности, такая проверка, что дата последней транзакции должна отличаться от даты последнего объявления не более чем на минуту. Т.е. если никаких дырок нет, мы считаем, что бэкап восстановлен корректно.







На слайдах можно посмотреть, какие конкретно ошибки мы анализируем в логе при проверке бэкапа.



Раньше мы проверяли бэкапы с помощью выполнения vacuum’а всей базы и вычитывания таблиц, но потом решили от этого отказаться, потому что мы считаем по восстановленному бэкапу еще отчеты, и если отчеты посчитались корректно, нет никаких дырок, странных значений, то бэкап сделан корректно.







Я рассказывал про асинхронную репликацию, но иногда хочется сделать синхронную. У нас Avito состоит из множества сервисов, один из таких сервисов — это платежный сервис. И благодаря тому, что он выделен, мы можем сделать синхронную репликацию для него, т.к. он работает на отдельной базе. Там не такая большая нагрузка и стандартная latency сети позволяет нам включить там синхронную репликацию.







Что можно сказать в конце? Все-таки, несмотря на то, что репликация синхронная, можно в таком режиме работать и восстанавливаться, если посмотреть на свои связанные системы, то можно придумать, и как их можно восстанавливать. Важно еще тестировать резервные копии.







Еще такое замечание. У нас скрипт восстановления, в конце него необходимо изменить DNS’ы, т.к. у нас мастер это или слэйв — это закреплено в DNS. Мы сейчас думаем о том, чтобы использовать какие-то системы типа ZooKeeper для того, чтобы автоматически переключать DNS. Такие планы.



Этот доклад — расшифровка одного из лучших выступлений на конференции разработчиков высоконагруженных систем HighLoad++. Сейчас мы активно готовим конференцию 2016 года — в этом году HighLoad++ пройдёт в Сколково, 7 и 8 ноября.



Команда Avito традиционно предлагает очень сильные выступления, например, в этом году это будут:





Также некоторые из этих материалов используются нами в обучающем онлайн-курсе по разработке высоконагруженных систем HighLoad.Guide — это цепочка специально подобранных писем, статей, материалов, видео. Уже сейчас в нашем учебнике более 30 уникальных материалов. Подключайтесь!



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/311472/

Комментарии (0)КомментироватьВ цитатник или сообщество
climbing86

Восстановление Windows 10. Восстановление системы | Блог Дмитрия Сергеева

Пятница, 23 Сентября 2016 г. 14:31 (ссылка)
moicom.ru/vosstanovlenie-wi...animatsii/

Сегодня мы поговорим о восстановление Windows 10, что нужно знать, как включить, как запустить и как вернуть операционную систему компьютера к более раннему состоянию.




Подробнее о способах восстановления десятки здесь:
http://moicom.ru/vosstanovlenie-windows-10-shest-sposobov-reanimatsii/
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
milggolfwijud

Window Wizard - магнитная щетка для окон

Понедельник, 19 Сентября 2016 г. 09:53 (ссылка)

bigimg (197x700, 84Kb)
nA1Eu5MymgIgRH4cNYs4Y5sU25cfVDYNg1Llj5H
nA1Eu5MymgIgRH4cNYs4Y5sU25cfVDYNg1Llj5H

Комментарии (0)КомментироватьВ цитатник или сообщество
Владимир_Шильников

Резервное копирование в Windows 7.

Суббота, 10 Сентября 2016 г. 10:37 (ссылка)

архивация и резервное копированиеВ операционную систему Windows 7 встроены средства архивации, которые позволяют провести резервное копирование операционной системы Windows и пользовательских данных. Архивация позволит создать резервный образ системы и других данных пользователя, с помощью которых можно будет восстановить систему после серьезных неполадок.

В этой статье будет дан обзор использования встроенных средств резервного копирования Windows 7. Встроенные средства резервного копирования операционной системы, по своим возможностям, могут удовлетворить большинство пользователей компьютера.


Как сделать резервное копирование? Существует довольно много программ для резервного копирования, среди них выделяются такие популярные программы, как Acronis True Image Home, Nero BackItUp, Norton Ghost, Paragon Drive Backup Professional. Также резервное копирование системы можно сделать без помощи сторонних программ, используя средства архивации и резервного копирования Windows.

Метки:   Комментарии (14)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Сертифицированная ФСТЭК версия Veeam Backup and Replication: резервное копирование конфиденциальной информации

Понедельник, 05 Сентября 2016 г. 11:16 (ссылка)



В этом году мы получили сертификат ФСТЭК (ТУ+НДВ4) на версию Veeam Backup & Replication v8 Update #2. В этом посте я кратко расскажу о том, в каких случаях стоит выбирать именно эту (сертифицированную) версию продукта вместо обычной (не сертифицированной) версии, о ключевых отличиях нашей сертифицированной версии, и об общих требованиях законодательства к резервному копированию информации ограниченного доступа, не относящейся к гостайне.



Сертифицированную версию продукта, предназначенного для резервного копирования информации, в общем случае требуется применять в следующих случаях:




  • Если продукт применяется в государственных организациях, в сегментах сети, где в силу требований ФСТЭК, необходимо применять сертифицированные версии программных средств.

  • Если на виртуальных машинах обрабатывается информация ограниченного доступа, не относящаяся к государственной тайне. Этот термин определен в законодательстве, и фактически включает в себя любую информацию, доступ к которой ограничен в силу того или иного закона. Например, к информации ограниченного доступа относится: конфиденциальная информация компании, персональные данные физлиц, различные виды тайн (коммерческая, врачебная, адвокатская и др.), информация о секретах производства и т.д. Государственная тайна также, конечно, должна защищаться сертифицированными продуктами, однако, в этом случае сертификация должна быть более высокого уровня, чем есть у Veeam Backup & Replication, поэтому защищать данные, отнесенные к гостайне, с помощью имеющейся сертифицированной версии продукта нельзя.

  • Если в организации в силу политики безопасности требуется применять сертифицированные версии программных средств.

  • Если компания в рамках исполнения контракта получает от контрагента информацию ограниченного доступа (например, сведения, составляющие коммерческую тайну контрагента).

  • Если на информационную систему организации (в силу ее критичности и важности) явно распространяются законодательные требования, обязывающие применять в ней сертифицированные средства защиты информации. Например: не имеющие системы резервирования участки сетевой инфраструктуры Интернета, АСУ ТП АЭС, автоматизированные системы МЧС, информационные системы органов государственной власти, и др.



В 2013-2014 ФСТЭК выпустила приказы №17, №21 и №31, в которых средства резервного копирования в целом (и, в частности, средства резервного копирования виртуальных сред), были явно отнесены к средствам защиты информации, и для них были установлены специальные требования. В частности требования к резервному копированию средств виртуализации описывается мерой ЗСВ.8. Особо хочу отметить, что Veeam Backup & Replication v8 прошел сертификацию на ТУ в соответствии с требованиями этих приказов ФСТЭК.



Если же продукт резервного копирования проходил сертификацию до вступления в силу этих приказов ФСТЭК, то он имеет "обычный" сертификат на ТУ (без подтверждения соответствия мере ЗСВ.8), это усложняет задачу для пользователя, потому что ему нужно самостоятельно провести испытания, чтобы показать соответствие своей информационной системы актуальным требованиям приказов ФСТЭК.



Например, если говорить про резервное копирование персональных данных, то




  • Требуется подтвердить соответствие функционала продукта защитным мерам из приказов ФСТЭК для случая 1-го и 2-го уровней защищенности ИСПДн, а для 3-го и 4-го уровней решение об их использовании принимает сам оператор, исходя из установленных им требований к функционированию информационных систем персональных данных. Сертификат ФСТЭК на ТУ позволяет подтвердить это «автоматически», не прибегая к аттестации или иным видам исследований безопасности информационной системы.

  • Также требуется подтвердить отсутствие недекларированных возможностей (НДВ) в продукте: поскольку в приказах ФСТЭК резервирование и восстановление данных прямо отнесено к «мерам обеспечения безопасности», то программные продукты, обеспечивающие выполнение резервного копирования, относятся к средствам защиты информации. Средства защиты информации, используемые в ИСПДн 1-го и 2-го уровней защищенности персональных данных, а также в системах 3-го уровня защищенности, для которых к актуальным отнесены угрозы, связанные с наличием недекларированных возможностей в прикладном программном обеспечении, должны пройти проверку не ниже чем по 4-му уровню контроля отсутствия недекларированных возможностей. Это очень важный момент для определения необходимости сертификации средств резервного копирования, потому что НДВ можно подтвердить только через систему государственной сертификации.



Касательно поддерживаемых платформ можно отметить, что сертифицированная версия Veeam Backup & Replication поддерживает такие распространенные версии платформ виртуализации Microsoft и VMware как VMware vSphere 5.5/6.0 и Microsoft Hyper-V Server 2012 R2.



Следует иметь в виду, что сертифицированная версия поставляется на физическом носителе с необходимой сопроводительной документацией (формуляр, ТУ, сертификат), но пробную версию можно скачать, как обычно, в электронном виде (путем обращения в отдел продаж). Количество лицензий, приобретаемых вместе с сертифицированным комплектом, может быть любым. Для поставки сертифицированной версии не требуется наличия лицензий ФСТЭК, поэтому поставку электронной лицензий и физического сертифицированного комплекта может произвести любой партнер Veeam в России.



Отдельным преимуществом сертифицированной версии Veeam Backup & Replication является ее техническая поддержка, которая осуществляется на территории России:

1) по специальным алгоритмам обслуживания, так как сертифицированный продукт нельзя обновлять (а именно это часто предлагается делать для обычной несертифицированной версии);

2) полностью (все три уровня) на русском языке.



Краткое заключение

Полученный сертификат ФСТЭК дает пользователям Veeam возможность организовать бизнес-процессы в соответствии с требованиями законодательства РФ. Сертифицированная версия Veeam Backup & Replication v8 может применяться для резервного копирования персональных данных физлиц, конфиденциальной информации организаций, ДСП-информации, коммерческой тайны и другой информации ограниченного доступа, не относящейся к государственной тайне, как в государственном секторе, так и в коммерческих организациях.



Дополнительные ссылки:




  1. Информационный сайт о сертифицированной ФСТЭК версии Veeam Backup & Replication и о резервном копирование информации ограниченного доступа в целом

  2. Статья М.Ю. Емельянникова "Необходимость резервного копирования данных для бизнеса, и нужен ли для этого сертификат ФСТЭК"

  3. Запись вебинара "Резервное копирование запросы бизнеса и требования закона" (спикеры Виталий Савченко, Михаил Емельянников, Мария Сидорова)

  4. Сертификат ФСТЭК на Veeam Backup & Replication


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282530/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Еще раз о пользе резервных копий или история о моей неудаче

Суббота, 03 Сентября 2016 г. 17:12 (ссылка)

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



image


Итак, жил-был системный администратор и был у него Active Directory домен. Так как инфраструктура была небольшой и досталась ему в наследство давно, то был в ней всего один контроллер домена с установленной на нём Windows Server 2003. Ресурсов сильно не хватало, поэтому на этом же сервере было установлено довольно большое количество приложений, которыми пользовался сам администратор и некоторые его коллеги. Ну и вишенкой на торте — резервных копий в этой компании никогда не делалось. Что могло пойти не так? Подробности под катом.



Ничто не может оставаться неизменным вечно и решило техническое руководство, что пора переходить на более свежую версию Active Directory, а значит нужно обновить контроллер домена. Как перейти на более свежую версию Windows Server в своем домене, если у вас есть всего один контроллер, на котором стоит много дополнительного софта и для которого нет резервных копий? Конечно — in-place upgrade! Во время обновления что-то пошло не так и процесс прервался с ошибкой. После этого посыпались ошибки от различных систем и приложений, и наш герой, поняв, что со старым контроллером беда, решил исправить ситуацию добавив новый контроллер (очень жаль что он не начал с этого). Был поднят новый сервер с Windows Server 2008 и он попытался ввести его в домен, чтобы затем сделать контроллером. Получив очередное сообщение об ошибке, администратор понял, что пришла пора искать помощь на стороне.



Именно здесь начинается наше с ним знакомство. Небольшая ремарка — в процессе поиска способа ему помочь участвовало несколько человек, но чтобы упростить повествование, я не буду акцентировать на этом внимание, тем более, что никаких технических деталей это не добавит.



По этическим причинам я не могу демонстрировать скриншоты из чужой рабочей среды. Поэтому, для написания истории я (теперь уже зная, что именно сломалось) воспроизвёл ситуацию в тестовой лаборатории. Для желающих, в конце статьи будет сказано, как вы можете сделать тоже самое, если вам захочется попробовать свои силы в решении этой задачки. Таким образом, нашими пациентами будут домен Test.local, Windows Server 2003 контроллер TESTDC, Windows Server 2008 сервер TESTNEWDC.



DNS



При попытке ввести новый сервер в домен выдавалась следующая ошибка:







Как обычно, проблемы с Active Directory начинаются с DNS. Заглянув в оснастку управления DNS на TESTDC мы увидели пустой сервер без зон. Так явно быть не должно, так как этот единственный контроллер, по совместительству являлся и единственным DNS сервером.





Итак, задача номер один — восстановить работоспособность DNS. Без него о рабочем домене не может быть и речи. На всякий случай, уточнили у заказчика, что все зоны были Active Directory integrated. Значит найти их файлы на самом сервере не удастся. Данные DNS должны загрузиться из разделов Active Directory базы. Но, похоже, что с этим были проблемы. Заглянули в System и Application логи, чтобы посмотреть, что происходит при старте службы DNS. Так и есть — в логах пестрили ошибки Event ID 4000 и Event ID 4007, характерные для проблем с работой AD integrated зоны:







Это был очень неприятный знак, так как невозможность загрузки информации из Active Directory базы единственного доступного контроллера намекала, на серьезность случившегося. Однако, оставалась надежда, что получится руками заставить всё это заработать. При попытке создать зону заново, подтвердилась мысль, что DNS не может ничего получить из Active Directory. Он не мог получить даже список контроллеров домена на которых хранятся соответствующие разделы:





В качестве обходного решения было решено попробовать подменить родную DNS зону локальной заглушкой. Понятно, что в ней не будет всей необходимой информации, но контроллер можно заставить принудительно обновить DNS записи Active Directory, а всё остальное пока могло подождать. Так что, была создана локальная основная зона test.local и в ней были разрешены динамические обновления. Самый простой способ, который предлагает Microsoft для регистрации DNS записей контроллера домена — рестартовать на нём сервис NetLogon. Это и было сделано. В результате, была получена локальная зона с нужными записями:





New DC



Здесь мы взяли паузу. Заказчик проверил функциональность приложений и систем в своей среде. Всё работало. пользователи могли штатно использовать свои учётные записи. У заказчика слегка отлегло от сердца — по крайней мере люди могли вернуться к работе.



Но основная проблема не была решена. Мы вернулись к попытке ввести новый сервер в домен. Для введения в домен использовался аккаунт доменного администратора test.local\administrator, который успешно логинился на старый контроллер. Снова ошибка. Правда, на этот раз, другая. Теперь «Login Failure: The target account name is incorrect».





Помня о проблеме загрузки информации из Active Directory, здесь появилась идея попробовать вместо доменного аккаунта локальный аккаунт администратора со старого контроллера testdc\administrator. Понятно, что, по сути, это тот же аккаунт, так как при создании домена, локальный built-in администратор первого контроллера становится built-in администратором домена, но, тем не менее, это сработало. Сервер был успешно введен в домен и его аккаунт появился в Active Directory базе:





Пришло время попытаться сделать его контроллером. Снова ошибка. Процесс получения роли контроллера через dcpromo завершался с сообщением «Access denied»:





В Active Directory логах старого контроллера при этом часто встречалось сообщение об ошибке Event ID 40960 — опять проблема с учётной записью, на сей раз, с записью самого контроллера:





Вообще, мысли о такой возможности появились ещё на этапе обнаружения ошибки с DNS, но очень уж не хотелось в это верить.



Учётные записи



Итак, стало окончательно ясно, что пошло не так во время in-place upgrade — были потеряны те данные о доменной учётной записи контроллера, что хранились на нём локально. В итоге, у нас был частично работоспособный домен, но не было контроллера домена. Был лишь сервер, на котором хранилась Active Directory база. Так как он не помнил своего компьютерного пароля, то для домена он, по сути, был никем. Выше была приведена ссылка, на статью Microsoft, которая предлагает метод решения этой проблемы:




  • Остановить службу KDC на повреждённом контроллере

  • Выполнить с правами администратора команду netdom resetpwd /server: /userd: /passwordd:*

  • Перезагрузить контроллер



Проблема в том, что для этого нужно иметь второй рабочий контроллер, а его не было.



Вообще, раз у нас есть проблема с несовпадением пар логин-пароль хранящихся локально и в базе Active Directory, то для её решения нам нужно иметь возможность как-то эти данные изменять.



С локальной версией учётной записи всё просто. Есть замечательная утилита от Joeware — machinepwd. Она позволяет задать произвольный пароль компьютерной записи (а если запись эта еще не сломана, то не только локально, но и в AD базе).



Сложнее с записью хранящейся в AD. Так как учётные записи контроллеров критически важны для этой службы, от она защищает их от любых посягательств. Мы попробовали следующее:




  • Самый простой способ — Reset компьютерной учётной записи через Active Directory Users and Computers (если вы делаете Reset, то пароль сбрасывается в значение по умолчанию, при создании нового компьютера — COMPUTERNAME$). Операция выдала ошибку доступа.




  • nltest. Этот инструмент позволяет управлять свойствами secure channel (та же пара логин-пароль) для компьютеров в Active Directory. Вообще говоря, он позволяет сбросить значение пароля на обеих сторонах. Ошибка обнаружения домена I_NetLogonControl failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN




  • dsmod. Утилита для работы с компьютерной учётной записью в самой Active Directory бузе. Ошибка Internal Error.




  • admod. Еще одна утилита для работы с объектами в AD. Ошибка Unwilling to perform.




  • ktpass. Интересный инструмент, позволяющий генерировать keytab файлы (своего рода оффлайн Kerberos token). Одной из особенностей этой утилиты является возможность сменить пароль учётной записи, для которой вы создаете keytab файл. Снова ошибка доступа.



Последней надеждой было достать текущий пароль контроллера из Active Directory. После этого можно было бы установить такое же локальное значение пароля. Есть много инструментов для извлечения этой информации (например: Mimikatz DC sync). Однако, даже имея доступ администратора, извлечь пароль в открытом виде можно только если ДО его последней смены была включена настройка Store passwords using reversible encryption. В нашем случае, она была выключена. Так как пароль принадлежал компьютерной учётной записи, то не было никаких шансов подобрать его по словарю имея на руках NTLM hash.



Подводя итог



Неприятно это признавать, но я так и не придумал, как в этой ситуации исправить положение. Заказчик был вынужден передподнимать домен в праздники (спешки, в принципе, не было — с локальной зоной DNS, пользователи даже не заметили, что что-то не так, так что он мог спокойно подготовиться к этой операции). Не получилось даже воспользоваться инструментами миграции — для переноса паролей они требовали наличия доверительных отношений между старым и новым доменами, но для установления этих отношения нужен живой контроллер домена. Понятно, что человек сам себе злобный буратино и сделал не так всё, что только было можно, но всё-таки мне было обидно.



Надеюсь, вам понравилась эта история с немного грустным финалом. В качестве послесловия, несколько напоминаний начинающим администраторам Active Directory:




  • Использовать один единственный контроллер домена можно только если у вас есть ОЧЕНЬ серьезные на то причины (как правило, отсутствие денег на еще одну лицензию Windows Server). Вы получаете единую точку отказа, проблемы с которой полностью выводят из строя вашу инфраструктуру.




  • Независимо от того, сколько у вас контроллеров, но особенно если он всего один, ВСЕГДА делайте резервные копии. Носители информации сейчас стоят так дешево, что не может быть никаких причин на этом экономить.




  • Не ставьте приложения на контроллер домена без крайней необходимости. Это совсем не тот сервер на который можно что-то поставить «заодно».




  • Еще раз, повторюсь — никогда не начинайте процедуру in-place upgrade не имея резервной копии сервера. Эта процедура сама по себе несёт больше рисков, чем миграция, так что незачем подставлять себя еще больше, лишаясь ещё и возможности отката изменений.



P.S. Если вы хотите получить тестовую среду с такой же проблемой, то всё что вам нужно, это поднять Windows Server 2003 контроллер домена, скачать утилиту machinepwd, ссылку на которую я дал выше, отключить на контроллере сетевое подключение, остановить службу KDC и, с помощь machinepwd, задать новый компьютерный пароль.



P.P.S. Если вы знаете способ в такой ситуации починить связь между контроллером и доменом, то поделитесь им, пожалуйста с аудиторией. Ваш подвиг не будет забыт!
Original source: habrahabr.ru.

https://habrahabr.ru/post/309132/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[recovery mode] Как защита от Microsoft удалила код на серверах. Байка о Defender

Понедельник, 16 Августа 2016 г. 02:01 (ссылка)

Сегодня на календаре 16 Августа 2016.

Windows Defender удалил рабочий код с хоста. Как это было:



Обсуждая с коллегой новости о череде проблем у Microsoft, которые пестрят в новостях. Там зависло, там пропало, там еще что-то — видимо накаркал себе проблем.

Работая на виртуальном сервере с кодом под IIS вдруг получаю предупреждение о том что Windows Defender обнаружил Worm внутри многих ASP файлов на хосте и настоятельно рекомендует удалить.



Вся прелесть в том что вариантов не предлагает Defender. Файлы уже пустые и залоченные. До вчера этой проблемы не существовало. Любая попытка восстановить с репозитория файлы — вызывает возмущение у Defender, с последующим удалением файлов.

Проверка настроек показала что Windows Defender обновился 8/15/16 до версии 1.225.3982.0.

Сканер настойчиво видел Worm:VBS/VBSWGbased.gen в ASP (VBScript ) файлах.

Проверка одного из файлов на virustotal.com показала теже результаты. Из 53х тестовых проверок — только Microsoft Defender находит Worm:VBS/VBSWGbased.gen.







Далее идет много часовая попытка понять, что именно заставило найти вирус и удалить код. Перебирая варианты строк и проверяя сканером каждую строчку — удалось удалить все и получить минимальный тестовый файл который вызывает безумие у Defender.

Function SafeSQLLogin()
Execute(SafeSQLLogin())
End Function
Function Stream_StringToBinary(Text)
Set BinaryStream = CreateObject("ADODB.Stream")
BinaryStream.Type = adTypeText
BinaryStream.CharSet = "us-ascii"
BinaryStream.Open
BinaryStream.WriteText Text
BinaryStream.Position = 0
BinaryStream.Type = adTypeBinary
BinaryStream.Position = 0
Stream_StringToBinary = BinaryStream.Read
Set BinaryStream = Nothing
End Function
Function strCrypt()
For i = 1 To Len(Text)
End Function


Код странный только потому что я удалил максимально все что смог, пока сканер все еще видел Червя. Этот текст минимальный, любое изменение или удаление одной из строк — перестает сводить с ума Defender.



Update:

более свежая версия текста для принятия его за вирус:

Function S
Execute S
End Function
For i To Len T




Сохранив текст в файл как test.txt и отправив на virustotal.com все еще выдает потверждение о Черве, несмотря на то что Defender уже получил несколько новых обновлений.

Вот результат от virustital.com

Result



Попытка связаться с Tech центром от Microsoft в режиме чата, слегка подняло настроение. Девушка+специалист настойчиво пыталась помочь мне восстановить систему и RestorePoint выдавая команды типа SCN и др. Все попытки пояснить что проблему не у меня с компьютером, вели вокруг настойчивой попытки решить мою проблему с моим компьютером. Поняв что сообщить о проблеме с Defender не получится, я связался с Администраторами хостов с предупреждением, что у нас могут возникнуть проблемы на всех серверах.

Администраторы как обычно не доступны. Надеюсь что они отзовутся не как обычно, когда уже что-то рухнуло. (сарказм)



Анализ «вредоносного» когда, не дает понимания никакой логики. Все ведет к случайному набору каких то совпадений. Любое изменение в тексте, ведет к тому что Червь перестает находиться. Но вся хитрость состоит в том, что текст идет не подряд!!! Этот код очищен от всего остального и это только часть строк, между этими строками были сотни строк другого кода. Нахождение Червя срабатывало только при существовании этих строк среди других строк кода весом на 80kb. Значит это не шаблон, а скорее по регулярке нахождение какого-то кол-ва определенных слов или фраз. Другой логики я не увидел.



Ничего против Microsoft не имею, но чтото в последнее время их ошибки чреваты огромными последствиями. У Администраторов существует жесткое правило — Никаких обновлений на серверах!!! Сначала долгие тесты на тестовых машинах. Понимаю что это звучит не ново — но исправления от Microsoft должны исправлять и защищать а не убивать и создавать новые проблемы, еще более страшные.



P.S. Defender получил очередную порцию обновлений, v1.225.4025.0 — но он все еще настойчиво блокирует и удаляет файлы на тестовом PC, на остальных машинах он везде отключен.
Original source: habrahabr.ru.

https://habrahabr.ru/post/307818/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Восстановление из резервной копии с помощью Veeam Agent for Linux

Понедельник, 15 Августа 2016 г. 12:55 (ссылка)

Конечная цель создания резервной копии – обеспечить возможность восстановления данных в случае сбоя, и сегодня я вкратце расскажу, как с этим способен справиться новый Veeam Agent for Linux. Возьмем в качестве «подопытного кролика» тот же бэкап, создание которого было описано в предыдущем посте, и посмотрим, как из него можно восстановиться. За сим добро пожаловать под кат.







Восстановление на уровне файлов



Как вы помните, Veeam Agent for Linux успешно сохранил бэкап на сервер NFS. Запустим уже знакомый нам UI, введя команду

veeam

Сверим часы, то есть данные о последней сессии задания резервного копирования:





Внизу, в списке команд теперь появилась команда R (Recover Files) – восстановить файлы. По ней будет выведена информация о имеющихся в наличии резервных копиях: какой хост был в работе, какое задание создало бэкап, сколько получилось точек восстановления (в нашем случае – одна) и в какое время.





Дважды нажимаем Enter, и выбранный бэкап монтируется на файловую систему нашего хоста в папку /mnt/backup:





Почему мы решили ограничиться этой операцией? Просто подумали, что у пользователей обычно есть свои предпочтения в работе с файлами, и ни к чему изобретать велосипед. Так что после того, как прошло монтирование, вы можете задействовать привычный для вас способ – например, командную строку или популярный Midnight Commander (mc):





Восстановление тома



Теперь рассмотрим, как выполняется восстановление тома целиком. Для начала выполняем загрузку машины с использованием Veeam Recovery Media (скачивается вместе с установочным пакетом решения Veeam Agent for Linux). Он запускается, используя файл ISO.



Veeam Recovery Media открывает нам графический интерфейс с вот таким набором команд:





Здесь есть возможность восстановления томов (Restore volumes), восстановления файлов (Restore files), настроек сети (Configure network), перехода к командной строке (Switch to command line), а также перезагрузки (Reboot) и выключения (Shutdown).

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




  1. В данном меню выбираем пункт Configure network, затем выбираем в списке нужный сетевой адаптер, который будет использоваться для соединения с СХД, и жмем Enter.




  2. В диалоге Configure adapter (настроить адаптер) выбираем Manual (ручная настройка) и жмем Enter.




  3. В диалоге Adapter settings (параметры адаптера) указываем требуемое: IP-адрес, маску подсети, шлюз по умолчанию, сервер DNS




  4. Кликаем Apply (применить) и жмём Enter.





    Если вы работаете с сервером DHCP, то нужные настройки Veeam Agent for Linux сделает автоматически – если в диалоге Configure adapter выбрать Auto.




  5. Продолжаем восстанавливать том: выбираем соответствующую операцию из списка команд — это Restore volumes.




  6. Далее на шаге Select Backup Location нужно указать местонахождение нашего бэкапа. Для нашего примера нужно выбрать опцию добавления шары Add shared folder…




  7. Затем на шаге Mount Shared Folder указываем, что у нас это NFS:






  8. В поле Server/Directory вводим имя сетевой шары, в которой лежат файлы бэкапа. Veeam Agent for Linux смонтирует ее в папку /media на файловой системе нашего recovery image и отобразит содержимое смонтированного тома. На шаге Browse for Backup Files вы сможете выбрать нужную точку восстановления, чтобы импортировать ее:





    Полезно: Если ваши бэкапы хранятся на одном из локальных устройств, то на шаге Select Backup Location вы, естественно, выберете опцию Mount local disk. При этом можно будет выполнять монтирование многократно — для нескольких устройств, на которых живут файлы резервных копий. Для этого нужно вернуться на шаг выбора местонахождения бэкапа Select Backup Location и опять выбрать опцию Mount local disk.




  9. На шаге Backup выбираем нужный бэкап и в нём — точку восстановления.




  10. Затем на шаге Disk Mapping можно просмотреть, какие тома имеются у машины в продакшене (то есть у локального хоста – Current System) и в бэкапе. Veeam Agent for Linux отобразит для выбранного тома подробную информацию, включая тип раздела, файловую систему, местоположение точки монтирования, размер тома, а также выведет список доступных команд:




    • Restore volume from (восстановить том) – восстановить данный том из бэкапа.




    • Delete partition (удалить раздел) — позволяет переразметить диск перед восстановлением тома. После удаления раздела можно будет создать новый и замапить на него том из бэкапа.




    • [для восстановления томов LVM] Create LVM physical volume (создать физический том LVM)— создать физический том LVM на выбранном разделе и добавить его в уже существующую группу томов (volume group, VG), либо создать новую группу. Это позволит восстановить логические тома LVM или группы томов в выбранную VG.




    • Close (закрыть) — закрыть диалог и выбрать другой том.



    Здесь мы выбираем Restore volume from и жмем Enter.




  11. В панели Current system в поле Restore напротив выбранного тома появится имя того, с которого будем восстанавливаться:






  12. Подтверждаем выбор (будьте внимательны, оплошность может дорого обойтись, поскольку данные будут перезаписаны теми, что в бэкапе!), нажимаем (Start restore).




  13. Cмотрим краткую сводку, подтверждаем выбор ещё раз и наблюдаем за прогрессом:








После завершения процесса мы заканчиваем работу с Veeam Recovery Media:




  1. Нажимаем Esc для возврата в главное меню.

  2. Отключаем носитель с recovery image.

  3. В главном меню выбираем Reboot и жмем Enter.

  4. Ждем старта ОС.



Вот, в общем-то, и весь рассказ о том, как происходит восстановление с помощью Veeam Agent for Linux.



Полезные ссылки




Original source: habrahabr.ru.

https://habrahabr.ru/post/307758/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
kseniasamohina

Важная роль технической оптимизации сайта

Вторник, 09 Августа 2016 г. 15:40 (ссылка)
md-eksperiment.org/post/201...acii-sajta


Многие пользователи даже не догадываются, что существует менее заметная глазу, но достаточно важная вещь - техническая оптимизация сайта. Это комплекс действий, направленный на улучшение его взаимодействия с поисковыми системами.

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Понтифик_Иванов

Важная роль технической оптимизации сайта

Понедельник, 08 Августа 2016 г. 22:27 (ссылка)
md-eksperiment.org/post/201...acii-sajta

Многие пользователи даже не догадываются, что существует менее заметная глазу, но достаточно важная вещь - техническая оптимизация сайта. Это комплекс действий, направленный на улучшение его взаимодействия с поисковыми системами.
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Выбор оборудования для резервного копирования в небольшом офисе

Вторник, 02 Августа 2016 г. 13:03 (ссылка)





Любой офис полон информации. Зачастую она и есть самый дорогой актив компании. Плохо, что об этом вспоминают тогда, когда появляется реальный риск ее утраты. И даже после сбоя, после восстановления лишь части информации, этот урок быстро забывается.



Иной администратор разведет руками и скажет: «А что делать? Бюджета — нет, понимания со стороны руководителей — нет, поэтому и бэкапов у нас тоже нет. Сломается — на их совести.» Но это лишь половина беды, ведь сломать можете и вы сами. Неправильная конфигурация, ошибка в настройке, криптор (вирус-шифратор) — и данные безвозвратно утрачены. Поэтому бекапы делать необходимо. Достигнув этого понимания, можно приступать к практической части.



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



Если читателю интересно наше мнение, а может, есть возможность поделиться своим опытом и даже хитростями — продолжаем под катом.



Сначала надо определиться что, с какой периодичностью мы резервируем, и сколько резервных копий необходимо хранить.



Типы данных и способы их резервного копирования



Файловые серверы



Для оперативного восстановления файлов без резервных копий удобно использовать механизм теневых копий — Shadow Copies of Shared Folders. Для его работы, как правило, достаточно зарезервировать 5-20% дискового пространства на самом файловом сервере. В расписании для создания «снимка» (snapshot) можно указать конец рабочего дня и полдень. Резерв в 5% позволяет хранить около 14 снимков, фактическое число зависит от объема диска и интенсивности изменения данных.







Резервное копирование можно выполнять встроенным средством Windows Backup. Также есть достаточно надежные инструменты Cobian Backup и Handy Backup. Cobian Backup — бесплатное приложение, поддерживающее Unicode, FTP, сжатие, шифрование, инкрементальные и дифференциальные виды резервного копирования. Handy Backup имеет ещё больше возможностей, включая синхронизацию и восстановление данных из копий. Мы будем рассматривать работу Windows Backup.



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



Для обхода этого ограничения есть простой и действенный способ. Надо подключить диск для резервных копий с backup-сервера по протоколу iSCSI. Windows Backup будет считать такой диск локальным.



Первая резервная копия будет равна объему хранимых данных. Поскольку Windows Backup использует блочный, а не файловый способ резервного копирования, следующая инкрементальная копия займет столько, сколько фактически изменилось дисковых блоков.



Инкрементальное резервное копирование — это запись только изменённых данных. То есть не нужно каждый раз копировать всю базу целиком, достаточно один раз создать ее полную копию, а затем вносить в нее актуальные изменения. При этом предыдущая версия данных не сохраняется, новая версия пишется поверх нее.



Дифференциальное резервное копирование, напротив, подразумевает сохранение предыдущих версий. Например, ежедневно создавая копию базы данных, вы сохраняете все предыдущие копии за неделю. Это позволяет быстро откатиться к определённому состоянию. При дифференциальном копировании измененные данные записываются отдельно от полной копии.



Windows Backup не требует дополнительной настройки и полностью управляет хранилищем:



Automatic management of full and incremental backups. You no longer need to manage full and incremental backups. Instead, Windows Server Backup will, by default, create an incremental backup that behaves like a full backup. You can recover any item from a single backup, but the backup will only occupy space needed for an incremental backup. In addition, Windows Server Backup does not require user intervention to periodically delete older backups to free up disk space for newer backups—older backups are deleted automatically.






Целесообразно выделить под резервные копии два объема фактически хранимых данных. Этого будет достаточно для хранения ежедневных копий с глубиной примерно в полтора-два месяца. Частота — ежедневно.



Серверы Microsoft SQL



Серверы Microsoft SQL поддерживают три типа резервного копирования:




  • Полное. Копируется база данных полностью.

  • Дифференциальное. Копируются страницы базы данных, изменившиеся с момента предыдущей резервной копии.

  • Инкрементальное. Копируется журнал транзакций (для баз в Full Recovery).



Необходимо определиться, как часто мы создаем полную резервную копию.

Один из ориентиров — продолжительность резервного копирования. Его нужно выполнять в нерабочее время или в выходные. Операция резервного копирования создает заметную нагрузку на сервер. Если невозможно выполнить полное копирование ночью или в рабочий день, то такое задание выполняют в выходные.



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



Периодичность инкрементального копирования зависит от того, какую часть базы данных приемлемо потерять в результате сбоя. Если вы готовы потерять один час работы (то есть восстановить базу данных по состоянию на час назад), то инкрементальное резервное копирование необходимо выполнять один раз в час. Можно чаще, но помните про нагрузку на сервер. Следует помнить, что резервное копирование базы – только один из способов обеспечить сохранность данных. Если утрата данных недопустима, как и простой во время восстановления данных, то используйте такие механизмы, как AlwaysOn и Log Shipping.



Важная настройка, которую нужно сразу сделать на сервере — включить компрессию для резервных копий. Это сократит объем резервных данных практически вдвое. Следует иметь в виду, что при запуске резервного копирования под файл резервных копий на диске будет зарезервирован объем, равный фактическому размеру базы за вычетом пустых страниц.







Рекомендация по выделяемому для хранения объему на дисках — не менее двух полных размеров базы данных. Но это минимальное требование: зачастую бухгалтерам нужно хранить по полной копии базы за каждый из предыдущих лет, а также полные копии за предыдущие отчётные периоды в текущем году. Также может понадобиться ежедневно делать копии с глубиной не менее месяца.



Типичное расписание:
















Сб Полное
Вс-Пт Дифференциальное
Каждые 4 часа Инкрементальное


Для реализации плана можно создать «План обслуживания», включающий все три типа заданий.







Серверы Microsoft Exchange



Этот продукт поддерживает два типа резервного копирования:




  • Полное. Копируются полностью базы данных и журналы транзакций.

  • Инкрементальное. Копируются только журналы транзакций.



Важно регулярно выполнять резервное копирование, поскольку только оно позволяет удалить («обрезать») журналы транзакции для почтовых баз, не находящихся в режиме циклического ведения журналов.



Windows Backup поддерживает только полное резервное копирование Microsoft Exchange. Для минимизации объема хранимых копий можно использовать диск, подключенный по iSCSI, по аналогии с файловым сервером.



Рекомендация по выделяемому для хранения объему на дисках — не менее двух полных размеров базы данных. Ежедневно.



Виртуальные машины



Большинство продуктов для резервного копирования позволяют копировать виртуальную машину со всеми дисками без использования агентов внутри операционной системы. Veeam Backup & Replication позволяет выполнять полные и инкрементальные резервные копии, а также синтезировать новую полную копию, «накатывая» инкрементальные на старую полную копию.



Бесплатная версия позволяет делать только полную копию, что негативно сказывается на окне резервного копирования и объеме передаваемых данных. Объем резервных данных, хранимых на диске, можно сократить, включив Windows Deduplication. Когда снимается копия с виртуальной машины, на диске сохраняется *.vib файл, и так для каждой виртуальной машины. Они довольно эффективно дедуплицируются. Ночью создали резервную копию, за день дедуплицировались. Это многократно проверенная схема, но она требует использования платной версии продукта.



С учетом того, что Windows Deduplication работает в режиме постпроцессинга, рекомендация по выделяемому для хранения объему на дисках — не менее трех полных размеров виртуальных машин. Частота копирования зависит от сервера. Если это веб-сервер со статичным содержимым, то нет смысла копировать его чаще, чем один раз в неделю.



Основные требования к аппаратному обеспечению



Дисковая подсистема



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







У вас есть выбор между 2,5" SFF-дисками и 3,5" LFF-дисками. Веских причин, по которым стоит выбрать SFF-диски, мы не видим. Диски этого типа обладают меньшей емкостью и стоят дороже. Они незаменимы, когда требуется снять больше IOPS с одного сервера (вдвое больше дисков — вдвое больше IOPS). По этой же причине большинство предлагаемых SFF-дисков — SAS со скоростью вращения шпинделя в 10 тыс. оборотов.



Оптимальный выбор для сервера резервного копирования — емкие SATA/SAS диски со скоростью вращения шпинделя в 7200 оборотов. При этом диски SAS, в теории, дают немного больше IOPS, нежели их SATA-родственники, поэтому, если разница в цене незначительна, то предпочтительны именно они. Однако в целом для серверов резервного копирования гораздо важнее время наработки дисков на отказ.



Если вы планируете использовать функцию Instant VM recovery, то очевидно, что производительность хранилища резервной копии должна относительно соответствовать рабочей нагрузке. Тормозящая машина зачастую еще хуже, чем нерабочая.







Объем хранилища можно рассчитать с учетом рекомендаций, изложенных выше. Но резервное копирование — вещь тонкая, и точно посчитать и спрогнозировать рост можно, только имея на руках фактические данные.



Если вы приобрели программный продукт для резервного копирования, то размер резервной копии будет зависеть и от способа хранения данных на диске, и от эффективности встроенных механизмов дедупликации/компрессии.



RAM и CPU



Требования к оперативной памяти и процессору зависят от средства резервного копирования.

Например, для популярного Veeam Backup & Replication они таковы:




  • Одно ядро на каждое конкурентное задание резервного копирования

    (https://helpcenter.veeam.com/backup/hyperv/limiting_tasks.html)

  • 4 Гб памяти для работы продукта плюс 500 Мб на каждое конкурентное задание резервного копирования.



На самом деле, каждое конкурентное задание резервного копирования использует несколько агентов — один для передачи данных, другой для сжатия, третий для дедупликации резервных копий. Тем не менее, производительность хоста редко становится узким местом. Обратите внимание, что дедупликация в Windows — блочная, с переменной длиной блока и сжатием.



Результаты фирменной дедупликации Veeam довольно скромны, мы предпочитаем делать это средствами Windows Server 2012 R2. Если вы планируете использовать дедупликацию Microsoft, то необходимо ориентироваться на следующие системные требования: 1 ядро и 350 Мб памяти на один дедуплицируемый том. Рекомендуемый максимальный размер тома — 2 Тб.







Диск размером 1.5Tb, объем хранимых данных 720Gb, без дедупликации данные занимали бы более 1Tb.







Сеть



Минимальная скорость сетевого интерфейса — 1Gbit/s. Сложно найти оборудование, которое соответствует этому требованию, но может подвести коммутатор — будьте внимательны при выборе сетевого порта. На 100mbit/s резервное 1 Tb данных будет длиться от 28 часов, что выглядит относительно приемлимым. Но когда потребуется сделать дополнительную копию в течение рабочего дня, ждать в 10 раз дольше — себе дороже.



Можно попробовать увеличить скорость при помощи EtherChannel или нескольких IP-адресов, но такие конфигурации сложнее в сопровождении, а итоговая скорость не всегда соответствует ожиданиям.



Если вы используете виртуализацию VMware и выделенную SAN сеть, платные продукты могут существенно повысить скорость копирования читая данные непосредственно с VMFS томов (SAN Transfer).



Несколько тонкостей при выборе процессора и памяти мы разберем в главе о выборе сервера.



Простой NAS «бизнес-серии»



Типичный NAS — устройство с закрытой фирменной прошивкой/операционной системой, предназначенное для хранения файлов в небольшом офисе. В функции большинства современных NAS входит хранение и раздача файлов по протоколам SMB/FTP/HTTP/iSCSI. Для конфигурирования используется дружелюбный web-интерфейс. Зачастую производители используют фирменные технологии для создания RAID-массивов. Но за удобство придется заплатить. Бизнес-серия обычно отличается от домашних устройств набортным процессором — вместо ARM устанавливаются более производительные Intel Atom или младшие Intel Core i3.



Типичный представитель — NETGEAR RN314 (ориентировочная цена без дисков — 50 000).







Плюсы: относительно недорогой, возможность замены дисков hot-swap, собственный программный RAID.

Минусы: низкая дисковая емкость (4 диска), невысокая производительность, невозможно установить ПО для резервного копирования непосредственно на устройство.



Практически любые NAS, даже самые простые, позволяют подключать iSCSI-диски. Но под нагрузкой они работают «не очень», чем меньше памяти в устройстве и больше объём дисков, тем больше может быть проблем. А латентность доступа настолько высокая, что кроме как под бэкапы такие диски не годятся, даже файл-сервер будет тормозить.



По поводу дедупликации сама Netgear пишет о том, что ее не следует включать для iSCSI-устройств. Из их статьи можно сделать вывод, что метод, используемый в их железке, очень похож на аналогичный Oracle ZFS. А ZFS знаменита тем, что для дедупликации большого объема данных требуется огромное количество оперативной памяти, которой нет в этих скромных устройствах.



Что же касается Windows, то по памяти требования довольно скромные. Но iSCSI-диск в формате Windows Server — это VHD-файл. Дедупликация VHD поддерживается только для сценария VDI (Virtual Desktop Infrastructure), поэтому для резервной копии надо проверять на свой страх и риск. А рисковать бекапами — последнее дело.



Дедупликация самих данных, хранимых в архивах Windows Backup, лишена смысла. Поскольку каждая дифференциальная копия сохраняет только изменившиеся данные, то дедуплицировать нечего.



Ряд недостатков можно нивелировать покупкой чуть более мощного и емкого устройства — NETGEAR ReadyNAS 516.







6 дисков, Intel Core i3, с возможностью подключения до трех дополнительных пятидисковых модулей. Проблема в цене — без дисков устройство обойдется в 150 000 рублей.



Можно подобрать аналогичную по цене модель в стоечном исполнении.



Скорость устройств такого класса ограничена скоростью двух не самых быстрых гигабитных сетевых интерфейсов.



Продвинутый NAS «корпоративного уровня»



Эти устройства уже представляют собой серверы начального уровня всё с той же фирменной прошивкой и программным RAID.



Например, Netgear RN4220S.







Двухюнитовая модель поддерживает 12 дисков с общей сырой емкостью до 48 Тб. Два блока питания улучшают отказоустойчивость, и вы не останетесь без резервных копий, пока закупается новый блок. Будучи укомплектованным всего лишь простеньким Intel Xeon E3-1225v2 Quad Core 3,2 ГГц, 8 Гб RAM и двумя слотами SFP+ для 10 Гбит Ethernet, этот NAS обойдется вам в 400 000 рублей без дисков. Это очень дорого и не очень гибко, тем более для небольшой компании.



Серверы общего назначения



Обычный сервер будет хорошим вариантом, если вы готовы с ним повозиться. Независимо от того, какую вы выберете операционную систему, — Windows или Linux, — перед вами открываются широкие возможности создания конфигурации под ваши нужды. Можно доверить хранение данных хорошему RAID-контроллеру с кэшем, можно собрать программный массив на Windows Storage Spaces или ZFS — выбор за вами. На этот же сервер можно установить и саму систему резервного копирования.



Выбирая форм-фактор сервера, оптимально остановиться на сервере высотой в 2U. В такой сервер, как правило, можно установить 12 LFF (3,5") или 24 SFF (2,5") диска. Кроме того, сейчас стало популярным располагать в тыльной части сервера два слота под SFF-диски. Их можно использовать под системный раздел или SSD-кэш.



Один или два процессора? Серверные процессоры могу содержать на одном кристалле от 4-х до совершенно фантастических 22-х ядер, поэтому для сервера резервного копирования два процессора не являются жизненной необходимостью.



Однако в некоторых случаях два процессора могут стоить незначительно дороже или даже дешевле, чем один с аналогичным количеством ядер. А установив только один процессор, вы можете столкнуться с тем, что будут работать не все PCI-E слоты.



Пример такого ограничения описан на сайте Intel. Lenovo тоже предупреждает, что в сервере x3650 с двухпроцессорной материнской платой при однопроцессорной конфигурации вы и вовсе получите лишь один слот:



With one processor, only two fixed onboard PCIe slots (Slots 0 and 4) can be used (Slot 5 requires the second processor). An internal storage controller occupies PCIe slot 0.






Необходимо подобрать то количество ядер, которое оптимально будет соответствовать производительности сети и дисковой подсистемы.



Например, если у вас две гигабитные сетевые карты, то в лучшем случае сервер сможет передавать данные в два-четыре потока до 100 Мб/сек. (в реальности один поток редко превышает 50-60 Мб/сек.). Для этого достаточно и 4-6 ядерного процессора. Если же в сервер установлена 10-гигабитная карта и конфигурация сетевого оборудования позволяет получить соответствующий поток, то наш выбор — не менее 8-12 ядер.



Необязательно брать процессор топовой серии, для нашей задачи более чем достаточно не самого мощного E5.



При выборе модулей оперативной памяти следует учитывать возможности многоканальной работы процессора с памятью (оптимально — один модуль на канал), а также количество процессоров. На каждый процессор, как правило, ставится одинаковое количество модулей.



Какую модель сервера выбрать?



Если выбирать из серверов HP, то даже стартовая линейка двухъюнитовых серверов HPE DL 180 Gen9 предлагает серверы с 12-дисковой корзиной. Для конфигурирования сервера от вас не потребуется думать о нужных кабелях, доступных разъемах и других тонких моментах, в которых можно промахнуться. Мастер конфигурирования поможет вам сделать это без ошибок.



Из продукции IBM под сервер резервного копирования подойдет модель x3650 M5. В конфигурации TopSeller — 8871EAG всего 8 дисковых слотов, она будет стоить дешевле, если вам не потребуется больше дисков. Наиболее подходящая платформа — стандартная модель 8871D4x. Для конфигурирования сервера воспользуйтесь Standalone Solutions Configuration Tool (SSCT). При запуске программы не забывайте выбрать правильную страну.



Наконец, из продукции третьего производителя «большой тройки» — Dell — можно порекомендовать модель R510.



Удачного резервного копирования, желаем вашим данным пребывать в целости и сохранности.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306892/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[recovery mode] “А шо эта ваш бэкап такой уставший?”*

Пятница, 22 Июля 2016 г. 13:23 (ссылка)

* А что это ваш бэкап такой несвежий? (Одесск.)







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



Пусть, например, вчера была написана первая часть «Мёртвых Душ», и ночью сделана резервная копия. А сегодня написана вторая часть, и в эмоциональном порыве уничтожена ещё до того, как настало время очередного резервного копирования.



Бороться с такими ситуациями призвана технология непрерывного резервного копирования (Continuous Data Protection, CDP). Всё, что записывается на диск, одновременно отправляется в резервную копию.



Рассмотрим подробнее, как это делается в продукте Arcserve RHA (Replication and High Availability) на реальных примерах в средах Windows и Linux.



Содержание



Введение

1. Архитектура

2. Установка программного обеспечения

2.1. Установка управляющих компонентов

2.2. Установка управляемых компонентов

3. Эксперименты по восстановлению данных

3.1. Восстановление файлов на заданный момент времени

3.2. Восстановление базы данных MS SQL на заданный момент времени

4. Заключение и реклама





Введение



Пусть мы имеем два сервера.



Боевой сервер (Master) содержит постоянно обновляющиеся данные. Мы следим за изменениями и ведём ведомость (журнал) изменений в виде «было -> стало», например:

















Время Содержимое файла «мытьё» Журнал изменений
10:30:51 МАМА МЫЛА РАМУ
10:30:52 МАМА МЫЛА ПАПУ Файл «мытьё», смещение 10, «РАМ» -> «ПАП»


Журнал изменений постоянно пересылается на резервный сервер (Replica) и применяется к его файлам. Таким образом файлы боевого и резервного серверов становятся идентичными.



Некоторые детали:


  • Изменения отслеживаются на уровне байтов, то есть при изменении одного байта журнал будет содержать информацию только об этом байте, а не о всём блоке данных;

  • Журнал изменений пересылается по обычной IP-сети, то есть разнести боевой и резервный серверы можно на значительные расстояния, в том числе, в разные города;

  • При разрыве соединения данные накапливаются в буфере и, как только связь восстановится, будут переданы и применены к резервному серверу;

  • История изменений (в заданном объёме, например, последние 500 Мегабайт) сохраняется на резервной машине и может быть применена в обратной последовательности, вернув содержимое файлов в состояние на определённый момент времени.





1. Архитектура







Для того, чтобы описанная выше схема заработала, нам потребуется установить на машины Master и Replica компонент, именуемый Engine, который берёт на себя основную работу по отслеживанию изменений в файлах и репликации данных с одной машины на другую.



Для того, чтобы сконфигурировать работу этих двух Engine, установим на ещё одну машину (Manager) сервис управления (Control Service). Эта машина требуется только для конфигурации, получения отчётов и запуска отдельных действий на управляемых машинах. Она не должна быть постоянно включенной.



Наконец, пользовательский интерфейс мы получим, соединившись интернет-браузером с сервисом управления, и скачав оттуда windows-приложение.





2. Установка программного обеспечения



Скачаем Arcserve RHA (iso или zip) с сайта разработчика (как указано на странице arcserve.zendesk.com/hc/en-us/articles/205009209-RHA-R16-5-SP5-ARCSERVE-RHA-16-5-SP5 ):



Продукт работает 30 дней без лицензионных ключей.





2.1. Установка управляющих компонентов



Начнём с того, что установим Control Service на управляющую машину (Manager).



Для его работы требуется .NET Framework 3.5.



В Windows 2012R2 .NET Framework 3.5 устанавливается так.
В Server Manager выбираем Manage -> Add Roles and Features. Отмечаем галочкой “.NET Framework 3.5 Features”.







Важно! Нужно явно указать, где на дистрибутиве Windows находится этот компонент. Для этого на следующем экране нажать “Specify an alternate source path”:







В моём случае путь выглядит вот так (D: — DVD c дистрибутивом Windows):









Теперь запускаем Setup.exe с дистрибутива Arcserve RHA и выбираем “Install Components”:







На следующем экране выбираем “Install Arcserve RHA Control Service”. (Особенность: на слова “Install Arcserve RHA …” кликнуть не получается, а на “… Control Service” – получается):







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







Будем запускать сервис от имени Local System:







Следующий экран касается возможности иметь две управляющих машины для повышения отказоустойчивости. Мы для целей тестирования ограничимся одной:







После завершения установки соединимся интернет-браузером с машиной Manager на порту 8088. Войти можно под пользователем, у которого есть права локального администратора на машине Manager:







Мы получим доступ к странице, на которой будет публиковаться статистика работы различных машин. Но для реального управления нам потребуется скачать с этого сайта и запустить windows-утилиту “Arcserve RHA Manager”. Её можно запускать уже не на сервере, а на рабочей станции (например, Windows 7 или 10). Для скачивания нажмём на ссылку “Scenario Management”:







После предупреждений безопасности должна запуститься программа “Arcserve RHA Manager”:







Эта программа и в дальнейшем будет запускаться только с веб-страницы.





2.2. Установка управляемых компонентов



На машины Master и Replica установим рабочие компоненты – Engine.



Можно установить их локально с дистрибутива, а можно – удалённо. Для удалённой установки на сервер требуется, чтобы у сервера была установлена роль “File Server”:







Если роль “File Server” установлена на машинах master и replica, то на машине Manager мы можем обратиться к “\\master\C$” и “\\replica\C$”.



Из утилиты Arcserve RHA Manager, о которой шла речь в предыдущем разделе, запустим удалённую установку через меню “Tools -> Launch Remote Installer”.







На следующем экране нажимаем кнопку “Start host discovery” (1) и получаем список машин из кэша Active Directory.



Выделяем машины master и replica и добавляем их в список кандидатов на установку Engine при помощи кнопки “Add” (3)







На следующем экране введём пользователя (администратора домена), под которым будет выполняться удалённая установка:







Далее убеждаемся, что оба сервера (master и replica) позволяют выполнить удалённую установку и помечены галочками:







На следующем экране введём пользователя, под которым будет запускаться служба Engine.



Для целей непрерывного резервного копирования достаточно пользователя с правами локального администратора (Local System). А вот если мы хотим использовать функционал High Availability, когда резервная машина сможет изображать из себя вышедшую из строя основную машину, то нам нужно запускать сервис под доменным администратором. Описанный ниже пример из раздела () требует именно таких полномочий:







Нажимаем всякие Next -> Install -> Yes и ждём завершения установки:









3. Эксперименты по восстановлению данных





3.1. Восстановление файлов на заданный момент времени





Создадим на машине Master каталог “C:\Ax-уехала-жена\” и положим туда файлы:



Таня.jpg



Лена.jpg



Джоконда.jpg



Создадим сценарий репликации этого каталога на машину Replica. В меню “Arcserve RHA Manager” выберем Scenario -> New

Первый экран мастера создания сценариев оставляем без изменений:







На втором экране также ничего не меняем – там должен быть выбран сценарий репликации файлов (File Server):







Выберем в качестве основной машины сервер Master, а в качестве резервной – Replica:







На следующем экране видим подтверждение того, что служба Engine установлена на обеих машинах. Если мы не установили её ранее, то можем сделать это удалённо отсюда.



На следующем экране выберем исходный каталог “C:\Ax-уехала-жена\” на машине Master:







На следующем экране нам предложат реплицировать этот каталог в каталог с таким же именем на машине Replica. Согласимся:







На следующем экране ничего не меняем:







А вот здесь нам нужно выставить параметр “Data Rewind” в “On”, чтобы иметь возможность восстанавливать данные на произвольный момент времени в прошлом:







Наконец, нам скажут, что сценарий не содержит ошибок:







Запустим сценарий, нажав кнопку “Run Now”:







На главном экране мы увидим, как работает сценарий. Заданный каталог быстро синхронизируется (станет одинаковым на основной и резервной машине), и теперь любое изменение в каталоге на машине Master приведёт к аналогичному изменению его копии на машине Replica.







Выполним три действия на машине Master:

1. Изменим файл Джоконда.jpg







2. Сотрём файл Таня.jpg



3. Добавим файл Маша.jpg



Убедимся, что на машине Replica с файлами произошло то же самое.



Теперь мы хотели бы вернуть Джоконде прежний облик. Для этого отмотаем время назад на машине Replica, воспользовавшись инструментом Data Recovery.



Сначала мы должны остановить сценарий (меню Tools -> Stop)



Затем щёлкнуть мышью на машине Replica и вызвать меню Tools -> Data Recovery:







Нажав в следующем окне кнопку “Select Recovery Point”, попадаем вот в такое окно, где нужно:



(1) Установить просмотр всех временных точек, на которые возможен откат по времени

(2) Нажать кнопку Apply

(3) Выделить самую первую точку, когда Джоконда ещё не была повреждена

(4) Нажать на кнопку “OK”







Затем нажимаем кнопку “Run”:







Проверяем, что произошло с файлами на машине Replica.



— Джоконда.jpg снова вернулась в начальное состояние

— Маша.jpg исчезла

— Лена.jpg появилась



Именно для того, чтобы не потерять Машу.jpg, мы не стали восстанавливать данные на обеих машинах. Теперь достаточно переписать файл “Джоконда.jpg” на машину Master, и мы снова получим в работу неиспорченный файл, не затрагивая все остальные.





3.2. Восстановление базы данных MS SQL на заданный момент времени



Предположим, что MS SQL установлен на машине Master. На машину Replica можно MS SQL не ставить, тогда она будет служить лишь хранилищем копии каталога DATA:







Сценарий репликации MS SQL похож на сценарий репликации файлов, но добавляются две вещи, которые облегчают нам жизнь:



1. нам не придётся явно указывать, где находятся файлы базы данных, эта информация автоматически подтянется:





2. при восстановлении данных на основную машину (Master) сервисы MS SQL будут автоматически потушены и переведены в режим ручного запуска. После восстановления всё вернётся на место:





Предположим, что кто-то забыл написать “where” в команде “update”:



begin transaction;
update dbo.Table_1 set name='Сидоров';
commit;


(кто сам такое делал – поймёт глубину падения).



Так же, как и в предыдущем случае, останавливаем сценарий репликации, запускаем “Tools->Data Recovery”, но выбираем восстановление не только на резервную машину, но и на основную:







Остаётся только выбрать точку во времени, предшествующую моменту порчи данных, и провести восстановление:









4. Заключение и реклама



В этой статье мы рассмотрели только основные возможности продукта Arcserve RHA, направленные на восстановление данных на заданный момент времени в прошлом. То есть, расшифровали только половину названия “Replication and High Availability”. В следующей статье вы увидите, как реализуется вторая часть названия – High Availability. Мы посмотрим, как вышедшая из строя машина (физическая или виртуальная) будет подменятся резервной машиной, содержащей актуальную копию данных.



[Реклама] В настоящее время, до конца сентября 2016 года, вы можете бесплатно получить продукт Arcserve RHA, приобретая продукт Arcserve UDP Premium Plus по цене Arcserve UDP Premium.

Подробнее можете узнать у партнеров компании Arcserve.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306194/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Знакомство с Veeam Agent for Linux

Среда, 20 Июля 2016 г. 14:44 (ссылка)

Как вы, возможно, уже знаете, в недалеком будущем увидит свет наш новый продукт — Veeam Agent for Linux. И уже сейчас все желающие могут оценить это решение в ходе анонсированной программы бета-тестирования. Чтобы получить доступ к бета-версии, нужно зарегистрироваться здесь, и вы получите на email ссылку для скачивания. Обратите внимание, что период бета-тестирования закончится 1 сентября 2016 года – затем вы сможете установить уже релизную версию.



Итак, что же умеет бета? За ответом добро пожаловать под кат.







Veeam Agent for Linux — это наше новое бесплатное решение для резервного копирования машин под управлением Linux. Его основные характеристики:


  • Может использоваться как для виртуальных, так и для физических машин.

  • Работает с машинами семейств Debian и RedHat. Доступен в виде пакетов RPM и DEB.

  • Поддерживаются версии ядра Linux, начиная с 2.6.32 (т е. даже если у вас очень старенькая инсталляция, то и она будет поддержана при условии, что у вас стоит официальное ядро для данного дистрибутива).

  • Работает с 32-битной и 64-битной архитектурой.









Решение включает в себя следующие компоненты:


  • Veeam Agent for Linux Service – компонент, отвечающий за работу со всеми задачами и необходимыми ресурсами. Регистрируется как обычный сервис, автоматически стартует при старте ОС и работает в фоновом режиме.

  • Veeam Agent for Linux Job Manager – процесс, который запускается вышеназванным сервисом для каждой сессии задания резервного копирования и отвечает за ее работу.

  • Veeam Agent – это, собственно, рабочая лошадка, которая выполняет операции передачи данных: во время бэкапа копирует их в репозиторий, а во время восстановления – наоборот, а также выполняет дедупликацию, компрессию, и т.д.

  • Veeam Agent for Linux Driver – модуль ядра Linux, который отвечает за создание снапшотов томов вашей машины.

  • SQLite database engine — используется для хранения конфигурации; если у вас его нет – то поставится в процессе установки продукта.



Veeam Agent for Linux умеет выполнять резервное копирование на уровне образа, работая внутри гостевой ОС, причем можно делать бэкапы на уровне томов и файлов. Для создания инкрементальных резервных копий нами был разработан специальный драйвер, который отслеживает измененные блоки (его модуль динамически подгружается в ядро).



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



Выполняем установку



Для работы решения необходимо наличие пакета Dynamic Kernel Module Support (DKMS), который требуется для компиляции модуля ядра, а также пакета LVM2, который требуется для поддержки операции с томами LVM. Если их нет на машине, то установите их – к примеру, DKMS на CentOS можно поставить из дополнительного репозитория EPEL.







После того, как прошла установка первого компонента, можно переходить к установке собственно Veeam Agent for Linux (для установки понадобятся права root):







Агент Veeam Agent for Linux устанавливается в виде сервиса, с которым затем можно работать, применяя команду veeamconfig. Для просмотра списка ее опций после команды veeamconfig введите --help. Ну и затем можно переходить уже непосредственно к работе – а там уже практически все понятно и без подсказок, но мы все же вкратце рассмотрим сначала процесс бэкапа.



Приступаем к резервному копированию



Поскольку среди пользователей Linux есть как продвинутые, так и начинающие, то мы в дополнение к командной строке предлагаем простенький графический интерфейс. Для его запуска используется командная строка – в ней вводим команду veeam. На экране появится GUI с приветственным сообщением и кнопками меню:







Чтобы создать новое задание резервного копирования, нажимаем C (Configure). Проходим по шагам мастера:


  1. Вводим имя, которое хотим дать заданию.

  2. На шаге Backup mode выбираем, хотим ли мы бэкапить всю машину (Entire machine), какой-либо том (Volume level backup) или отдельные файлы и папки (File level backup):

  3. Затем указываем тип репозитория (Destination Location), куда будут сохраняться резервные копии. Если репозитория у нас еще нет, то мастер попросит его создать. В качестве репозитория поддерживаются:


    • устройства с прямым подключением (USB, eSATA, FС и т.п.)

    • сетевые файловые системы NFS, SMB (CIFS)

    • локальное устройство хранения (не рекомендуется)



    В данном примере в качестве репозитория выбирается папка NFS с общим доступом:








  4. Тут же можно указать, сколько точек восстановления (Restore points) должно храниться в репозитории – по умолчанию 14.

  5. Затем можно настроить расписание (Schedule) для нашего задания, указав, с какой периодичностью оно будет запускаться.



После того, как все настройки сделаны, мастер предложит вам запустить задание сразу же. Если вы еще раз хотите пройтись по настройкам и, возможно, что-то поменять, можно либо вернуться к предыдущему шагу, нажав Prev, либо, если вы уже нажали Finish и вернулись в главное меню, нажать C. Для запуска задания из главного меню нажмите S. Если же вы захотите запустить задание в какой-то момент по требованию, то к вашим услугам соответствующая команда:

veeamconfig job start --name "BackupJob1"



В ходе выполнения задания по нажатию Enter можно посмотреть, что как идет и что пишется в лог:







Наше задание успешно отработало, и на экране появилась соответствующая информация в поле Status:







В репозитории на NFS-сервере теперь лежат файлы резервной копии (.VBK и .VBM), поименованные согласно названию задания и времени создания:







Имея резервную копию, можно посмотреть, как Veeam Agent for Linux умеет выполнять восстановление Linux-сервера на уровне файла, тома, или же вообще «на голое железо» — но об этом в следующем посте.



Полезные ссылки



Регистрация для участия в бета-тестировании

Комментарии и пожелания можно оставлять на нашем форуме
Original source: habrahabr.ru.

https://habrahabr.ru/post/306032/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<резервное копирование - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda