Рубрика «бэкап»

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

Дано: есть локальное S3-хранилище, есть Veritas NetBackup, который обзавёлся новым расширенным функционалом по перемещению данных в объектные хранилища теперь уже с поддержкой дедупликации, и есть проблема со свободным местом в этом локальном хранилище.

Задача: сделать всё так, чтобы процесс хранения резервных копий был быстр и дешев.

Собственно, до этого в S3 всё складывалось просто файлами, причём это были полные слепки критичных машин дата-центра. То есть не так, чтобы очень оптимизированно, но зато всё работало на старте. Сейчас же пришло время разобраться и сделать правильно.

На картинке то, к чему мы пришли:

Как уплотнить до 90% хранение бэкапов в объектном хранилище - 1

Как видно, первый бэкап делался медленно (70 Мб/с), а последующие бэкапы тех же систем — значительно быстрее.

Собственно, дальше чуть больше деталей про то, какие там особенности. Читать полностью »

Backup? I don't need backup!!

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

В данной статье мы рассмотрим наш опыт использования CommVault для резервного копирования PostgreSQL. Для этого разберем небольшую часть одного из наших прошлых проектов, где мы настраивали резервное копирование БД PostgreSQL у клиента.

Статья про то, как CommVault делает бэкап PostgreSQL - 1Читать полностью »

Детям — мороженое, информационной системе — бэкап - 1

Все люди делятся на две категории: те, кто еще не делает бэкапы, и те, кто уже делает бэкапы.

Говорить о важности резервного копирования данных и о рисках, связанных с отсутствием такового, считаю излишним. Думаю, в этом вопросе все будут солидарны – резервные копии нужны!

В мнении по этому вопросу, к нам присоединились и правительство со своей карающей дланью, и регулирующие органы в области защиты информации. Все мы помним требования законодательства, озвученны в 17-м, 21-м и 31-м Приказах ФСТЭК. Так же регуляторами кредитно-финансовой сферы сформированы требования к резервированию и резервному копированию.

А с 1 января 2018 года к ним добавится (вступит в действие) и Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», который нам так же говорит, что одной из четырех «Основных задач системы безопасности значимого объекта критической информационной инфраструктуры является:» «восстановление функционирования значимого объекта критической информационной инфраструктуры, обеспечиваемого в том числе за счет создания и хранения резервных копий необходимой для этого информации».

Таким образом, данными требованиями охвачены фактически юрлица во всех сферах. А что у нас большего всего любят регуляторы? Читать полностью »

Черная пятница айтишника, или Сказ о потере данных - 1

Есть прекрасная поговорка «И на старуху бывает проруха». Её можно сделать девизом индустрии: даже хорошо продуманная многоуровневая система защиты от потери данных может пасть жертвой непредвиденного бага или человеческой ошибки. Увы, такие истории не редкость, и сегодня мы хотим рассказать о двух случаях из нашей практики, когда всё пошло не так. Shit happens, как говаривал старина Форрест Гамп.
Читать полностью »

Зачем бэкап? У нас же RAID - 1

В корпоративные блоги принято писать success story — это положительно влияет на образ компании. К сожалению, не всегда в работе инженера всё заканчивается happy end-ом.
Надо сказать, что коллеги уже начинают подшучивать, что я «притягиваю» проблемы. Тем или иным образом я поучаствовал почти во всех проблемных заявках за последнее время. И теперь хочу рассказать одну поучительную историю из своей практики.
Читать полностью »

Многоярусный бэкап PostgreSQL с помощью Barman и синхронного переноса журналов транзакций - 1

В Яндекс.Деньгах хранится масса важной для комфортной работы пользователя информации. Настройки профилей и подписки на штрафы тоже нужно бэкапить, чем и занимается у нас связка из Barman Backup & Recovery for PostgreSQL и pg_receivexlog.

В статье расскажу о том, почему архитектура стала такой, какой стала, а также расскажу, как реализовать подобный сценарий для вашей базы PostgreSQL.Читать полностью »

Чтобы карета не превратилась в тыкву, или зачем нужны тестовые восстановления из резервных копий - 1

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

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

Типичная для многих админов ситуация:

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

И почему бы не организовать бэкапы на Я.Диски наших клиентов? Бэкапы не только с файлами, но и с дампами баз данных? И проинструктировать их: не дай бог нам на встречку выедет Камаз, ваши сайты всегда у вас на Я.Диске.

Т.к. мы говорим о Яндексе, мы конечно же делегировали наши домены, на нашем сервере, на Яндекс. Зачем грузить свой сервер? Пусть с почтой, по протоколу smtp, работает Яндекс. А заодно пусть Яндекс и управление NS-ами на себя возьмет. Удобно, на самом деле.

Что нам нужно для организации бэкапов на разные аккаунты Я.Диска:

  • установить и настроить ssmtp на ваш сервер;
  • установить и настроить нужный клиент Я.Диска;
  • создать и настроить bash скрипт для бэкапа;
  • прописать задания в cron.

Ну и конечно у нас есть заветная почта вида root@your-site.ru созданная в Яндексе. От имени root@your-site.ru нам будут приходить письма о бэкапах.

Предложенный в статье алгоритм протестирован на сервере с Ubuntu 16.04 на борту.
Читать полностью »

Если настроил резервное копирование, не забил, не сэкономил — уже молодец. Но бэкап еще нужно уметь правильно готовить.
Лично у меня ощущение, что некоторые администраторы своей настольной книгой сделали специздание Остера с вредными советами по настройке бэкапа для оптимистов, не верящих в закон Мерфи.
Сегодня решил выложить свой короткий хит-парад с реальными историями, с которыми приходилось сталкиваться за время работы на стороне сервис-провайдеров и клиентов. После каждого такого случая виновник торжества остро чувствует, что ему в компании больше не рады, и понимает, что самое время обновить резюме на ХХ.
Читайте и мотайте на ус.

Вредные советы по настройке резервного копирования и несколько баек - 1

Читать полностью »