Резервное копирование и восстановление Graylog-сервера

  • Tutorial
Приветствую, хабраюзеры!
Дело было вечером, делать было нечего, и тут я вспомнил — я же хотел поделится с сообществом своим недавним боевым опытом.
Было у меня задание — автоматизировать процедуру резервного копирования и создать процедуру восстановления Graylog-сервера.


Сервер был для меня неизвестным, ранее сталкиваться не приходилось.
Ну что ж, посидел-почитал, да подумал — ничего сложного. Однако поиски в Google показали, что не каждый день такая задача появляется, ибо информации практически не было.
«Где наша не пропадала?» — подумал я, все должно быть предельно просто, скопируем конфигурационные файлы и вуаля.
Сделаю небольшое лирическое отступление, дабы описать Graylog-сервер и его составляющие.

Что такое Graylog-сервер?



Graylog2 — это open-source система для сбора и анализа статистики, позволяющий обрабатывать данные достаточно гибко. В качестве агента — он использует syslog. Данные посылаются с узлов посредством syslog и агрегируются Graylog-сервером.
В качестве базы данных для хранения контента и настроек — используется MongoDB.
Ну и самая громоздкая часть сервера — это ElasticSearch, мощный инструмент для индексирования данных и поиска по ним.

Процесс резервного копирования



Задание начинало приобретать очертания. Необходимо было копировать содержимое MongoDB и индексы ElasticSearch, а также конфигурационные файлы каждой из частей Graylog.
Остановив предварительно сервис graylog-server и elasticsearch, я приступил к резервному копированию.
/etc/init.d/graylog-server stop
/etc/init.d/elasticsearch stop
/etc/init.d/chef-client stop


В моем случае, в MongoDB у нас находилась база под названием graylog2. Дабы получить копию оной, я создал dump базы следующей командой:
logger -s -i "Dumping MongoDB"
mkdir -p path-to-backup
mongodump -h 127.0.0.1 -d graylog2 -o path-to-backup/

Таким образом, в директории path-to-backup cоздается dump базы данных «graylog2», находящейся на localhost (можно указывать также удаленный узел).

Следующий шаг — резервное копирование и сжатие индексов ElasticSearch. В нашем случае, за 7 месяцев работы, собралось около 12 Гбайт индексов. По умолчанию, не было настроено их сжатие, что могло бы уменьшить затраты места под хранение в разы.
Директория, хранящая индексы, в нашем случае находилась на примонтированном разделе. За указание на место хранения индексов отвечает параметр path.data в /etc/elasticsearch/elasticsearch.yml. Также, немаловажным параметром (без него не заработает, никак) — является имя кластера, заданное в том же конфигурационном файле параметром cluster.name.
Для резервного копирования индексов я использовал следующую команду, которая сжимала и упаковывала содержимое директории с индексами:
logger -s -i "Dumping MongoDB"
tar -zcf path-to-backup/elasticsearch.tar.gz --directory=path-to-indices graylog2

В результате, из 12 Гбайт исходной информации получился архив в 1.8 Гбайта. Что ж, уже неплохо…

Далее, оставалось скопировать конфигурационные файлы Graylog, MongoDB и ElasticSearch. Стоит отметить, что в конфигурационном файле ElasticSeach — elasticsearch.yml — содержался также параметр node.name, представляющий собой hostname нашего сервера. Это важно в том случае, если восстановление Graylog-сервера будет происходить на узле с другим hostname. Точно также содержимое конфигурационного файла Graylog — graylog2.conf — содержало настройки под нашу конкретную базу MongoDB, с используемым в ней для доступа пользователем и паролем.
Упоминаю я это все к тому, что бездумное копирование файлов конфигурации к добру не приведет, и это «не наши методы, Шурик» (с)

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

В моем случае копирование осуществлялось при помощи scp с использованием ключа для аутентификации:

logger -s -i "Copying backups to Backup server"
scp -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -r -i /root/.ssh/id_rsa path-to-backup backup-user@backup-server: 

logger -s -i «Copying backups to Backup server: DONE»

Подытоживая процесс резервного копирования, я бы хотел выделить шаги, которые необходимо предпринять:
  • Остановка сервисов Graylog и ElasticSearch
  • Создание dump-а (копии) MongoDB базы данных
  • Копирование и архивирование директории индексов ElasticSearch
  • Копирование конфигурационных файлов


Процесс восстановления Graylog-сервера



Неудивительно, что процесс восстановления — зеркальное отображение процесса резервного копирования.
Ниже я приведу небольшой bash-скрипт, который восстанавливает Graylog-сервер:

/etc/init.d/graylog-server stop
/etc/init.d/elasticsearch stop
scp -r user@backup-server/graylog-backup/* ./
tar zxf graylog2-mongodump.tar.gz
tar zxf elasticsearch.tar.gz
mongorestore -d graylog2 ./graylog2
mv ./elasticsearch/* /opt/elasticsearch/data/
mv ./graylog2.conf /etc/
mv ./elasticsearch.yaml /etc/elasticsearch/elasticsearch.yml

/etc/init.d/graylog-server start
/etc/init.d/elasticsearch start


Скрипт копирует архивы с backup-server, распаковывает их, потом восстанавливается база graylog2 в MongoDB и перемещаются индексы ElasticSearch в директорию по-умолчанию. Также копируются конфигурационные файлы ElasticSearch и Graylog-сервера. После этого запускаются сервис ElasticSearch и Graylog-server.

Для того, чтобы удостовериться в целостности восстановления можно поступить следующим образом:
  • зайти на web-интерфейс сервера и удостоверится, что все Messages, Hosts, Streams и параметры присутствуют в идентичном состоянии
  • сравнить результат curl-запроса curl -XGET " localhost:9200/graylog2_0/_mapping


Процесс простой, проверенный на нескольких экземплярах. Однако мало-документированный. Стоит также отметить, что с релизом ElasticSearch v.1 — он упрощается введением процедуры получения «слепков» индексов, но сути это не меняет.
Надеюсь, что кому-то данная статья поможет. Спасибо за внимание.

P.S. Отдельное спасибо моему коллеге Siah, который сделал этот скрипт красивым и поддающимся автоматизации. Ну а я — ленивый топикстартер :)
EPAM
154.38
Компания для карьерного и профессионального роста
Share post

Comments 17

    +1
    Круто. Вот только Elasticsearch 1.0 научился делать snapshot и восстанавливать его практически одним вызовом

    www.elasticsearch.org/guide/en/elasticsearch/reference/master/modules-snapshots.html

    Вероятно, Graylog скоро обновится.
      0
      Я знаю, об этом и написал в последнем предложении топика.
      с релизом ElasticSearch v.1 — он упрощается введением процедуры получения «слепков» индексов, но сути это не меняет
      +1
      12G индекс, а база? И сколько времени занимает полное переиндексирование, если не хранить индекс эластика?
        0
        База порядка 3 гб, если я не ошибаюсь. Времени — я не дождался, ибо производилось это все на AWS инстансе, не самом шустром. Сомневаюсь, что быстрее, чем упаковка (порядка 30 мин.)
          0
          Пишут, что graylog хранит сами логи в elasticsearch'е, что объясняет такое необычное соотношение размера индекса и размера базы.

          Интересно, почему они не взяли lucene/solr.
            +1
            Минус и никаких объяснений…

            То ли у кого-то такая ненависть к stored полям, то ли к lucene. Тот же logstash умеет хранить и в solr, и в elasticsearch.
        +2
        На самом деле, если иметь 3 ноды, 1 реплику и больше 2 шардов на индекс в elasticsearch (это дефолтные настройки как минимум), то бекап из статьи будет неполным.
          0
          Эмпирически проверяли — восстанавливается без потерь, насколько могу судить. И ноды, и мессаджи.
            +1
            В описанном мной случае ни одна нода не будет иметь полный набор данных, так что бекап одной не сможет восстановить кластер целиком.
              0
              А, это да, немного не о тех нодах подумал. Спасибо, сделаю уточнение в статье завтра.
        • UFO just landed and posted this here
            +1
            Место == деньги. Снапшот был моей изначальной идеей.
            • UFO just landed and posted this here
                0
                О простоте решения никто не говорит, снапшот — проще всего. Может у вас не проблема, но отдать 18-20 гб. под хранение бэкапов не самое разумное решение. 2 гб. — уже другой разговор.
                • UFO just landed and posted this here
                    0
                    Согласен, но опять же — речь тут шла о том, что все stays in cloud. Да и о методах DR, для которых писалось сие — не спорят. У каждого свои ресурсы. On-premises HDD — не был вариантом.
            0
            а каков размер дампа mongodb?

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