Если инфошум о замедлении Твиттера вчера не позволил вам увидеть важное, то сообщаю. Вчера, 10 марта, произошел пожар в дата-центре провайдера OVH в Страсбурге, который входит в топ-5 крупнейших провайдеров. Полностью уничтожен центр обмена данными SBG2 (выгорел полностью) и на 30% ЦОД SBG1 (выгорело несколько боксов). Остальные 2 здания, находившиеся рядом, залиты водой.

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

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

Я руковожу небольшимDigital-агентством, обслуживаем малый и средний бизнес, часто общаемся с начинающими предпринимателями. И постоянно сталкиваемся с анти-кейсами резервного копирования, возражениями вроде дорого, сложно, позже настроим, пока не надо и само рассосется.

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

1. Купите отдельные IP-адреса для боевых проектов

Если у вас облако, сервер или VPS, то один IP-адрес уже в комплекте. Если у вас виртуальный хостинг, то докупите к нему выделенный IP-адрес. В нештатных ситуациях это поможет быстро сменить хостинг или перенести проект на другой сервер. Обойдется примерно в99 руб. в месяц.

2. Используйте NS-сервера регистратора домена

Хостинг провайдеры предлагают перенести обслуживание DNS на свой хостинг. Не соглашайтесь, оставьте домен на NS-серверах регистратора домена, а в А-записи домена пропишите IP-адрес хостинга. Так вы сможете быстрее сменить хостинг в случае аварии. При изменении А-записи обновления распространятся в течение 1 часа, и ваш проект через час уже будет доступен на новом хостинге. Но если же вы будете менять NS-сервера, то обновления могу занять до 72 часов. Обычно регистраторы предоставляют услугубесплатно, но RU-center хочет денег.

3. Включите локальное резервное копирование на хостинге

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

4. Храните 1-3 локальных бэкапа

Как правило, дисковое пространство на хостинге стоит не дешево, даже если вы покупаете отдельный диск для бэкапов. Поэтому нецелесообразно хранить там большие объёмы информации. Храните только самые последнии копии за предыдущие дни.

5. Настройте резервное копирование на отдельный сервер

Я рекомендую использовать облака как основное хранилище резервных копий, но вы можете использовать и простой сервер или дешевый хостинг от другого провайдера. Главное, чтобы сервера этого другого провайдера располагались не в том же дата-центре, что и основной сайт. Но облака гораздо дешевле, хранение одного терабайта там стоит обычнооколо 500 руб. в месяц. Можно использовать Google Cloud, AWS или Yandex Cloud для них есть готовые инструменты резервного копирования, поэтому их легко настроить. Обычно рекомендуют хранить 7 копий за неделю, 4 копии за месяц, 12 копий за год так и сделайте.

6. Поверяйте бэкапы раз в неделю

Минимум раз в неделю проверяйте факт создания бэкапов и их размер. Любой сбой может нарушить вашу схему резервного копирования: смена пароля, обновление ПО, переполнение диска, нехватка денег на счету. Потратьте всего 2-3 минуты в неделю этого хватит, чтобы предотвратить неприятности.

7. Восстанавливайте бэкапы раз в месяц

Хотя бы изредка восстанавливайте свои резервные копии на тестовом сервере. Идеально делать это раз в месяц, минимум хотя бы раз в 3 месяца. Одно дело иметь резервные копии, и совсем другое иметь реально работающие резервные копии. Вы должны быть уверены, что в нужный момент бэкапы вам реально помогут и у вас есть возможность их быстро развернуть. Удобно и дешево можно разворачивать облачные сервера на reg.ru или hetzner.cloud, потратитемаксимум 100-200 руб за раз. Процедура займет всего 1-2 часа, но убережет от проблем в будущем.

Вот и все, просто соблюдайте хотя бы эти простые правила.

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

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

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

Недавно мы публиковали статью про производительность Vault с разными бэкендами, а сегодня расскажем, как делать бэкапы и снова на разных бэкендах: Consul, GCS (Google Cloud Storage), PostgreSQL и Raft.

Как известно, HashiCorp предоставляет нативный метод бэкапа только для одного бэкенда Integrated Storage (Raft Cluster), представленного как GA в апреле прошлого года. В нем можно снять снапшот всего одним curlом и не беспокоиться о каких-либо нюансах. (Подробности смотрите в tutorial и документации по API.)

В остальных же случаях придется выкручиваться самим, придумывая, как правильно реализовывать бэкап. Очевидно, что во время резервного копирования Vault часть данных может меняться, из-за чего мы рискуем получить некорректные данные. Поэтому важно искать пути для консистентного бэкапа.

1. Consul

В Consul существует встроенный механизм для создания и восстановления снапшотов. Он поддерживает point-in-time backup, поэтому за консистентность данных можно не переживать. Однако есть существенный недостаток: на время снапшота происходит блокировка, из-за чего могут возникнуть проблемы с операциями на запись.

Для создания такого снимка необходимо:

1. Подключиться к инстансу с Consul и выполнить команду:

# consul snapshot save backup.snapSaved and verified snapshot to index 199605#

2. Забрать файл backup.snap (заархивировать и перенести в место для хранения бэкапов).

Для восстановления будет схожий алгоритм действий с выполнением другой команды на сервере с Consul:

# consul snapshot restore backup.snap

В HA Vault-кластере активный узел будет являться лидером во время экспорта данных или моментального снимка. После восстановления данных Vault в Consul необходимо вручную снять эту блокировку, чтобы кластер Vault мог выбрать нового лидера.

Выполните команду после восстановления данных для снятия блокировки:

# consul kv delete vault/core/lock

Работа со снапшотами обычно происходит быстро (см. примеры в конце статьи) и обычно не вызывает трудностей.

2. Google Cloud Storage

С GCS всё оказалось сложнее: подходящих вариантов для создания снапшотов/бэкапов бакета найти не удалось. Предусмотрена поддержка версионирования, но с ним восстановить сразу весь бакет на определенный момент времени нельзя можно только по одному файлу. В теории это решается скриптом для взаимодействия со всеми файлами, но если учесть размер Vaultа и количества файлов в нем, скорее всего такой скрипт будет работать слишком долго. Если мы хотим получить консистентные данные, то снятия дампа придется на время останавливать Vault.

А для копирования данных в GCS предусмотрен удобный способ Data Transfer. С его помощью можно создать полную копию бакета, а дальше уже работать с ним по своему усмотрению.

Последовательность действий:

1. Выключаем Vault.

2. Заходим в Data Transfer (https://console.cloud.google.com/transfer/cloud).

3. Выбираем исходный бакет, вводим название бакета, куда переносить данные, и выбираем разовую операцию. Здесь возможно установить и операцию по расписанию, но она не учитывает специфики Vault (тот факт, что сервис необходимо остановить Vault на время её выполнения), поэтому оставляем разовый запуск.

4. После успешного копирования запускаем Vault.

5. С созданным бакетом можно работать: например, скачать его содержимое при помощи gsutil, заархивировать все данные и отправить на долгосрочное хранение.

В зависимости от количества ключей продолжительность бэкапа может сильно изменяться: от нескольких минут и практически до бесконечности. Ниже будет приведена таблица с примерными значениями.

Скриншоты страницы при создании трансфера и после завершения:

3. PostgreSQL

Базу в PostgreSQL достаточно забэкапить любыми доступными для этой СУБД способами не сомневаюсь, что они хорошо известны инженерам, уже работающим с PgSQL. Инструкции по выполнению операций для настройки бэкапов и восстановления данных на нужный момент времени (PITR, Point-in-Time Recovery) описаны в официальной документации проекта. Также хорошую инструкцию можно найти в этой статье от Percona.

Не останавливаясь на технических деталях по этим операциям (они уже раскрыты в многочисленных статьях), отмечу, что у PostgreSQL получился заметно более быстрый бэкап, чем у вариантов выше. Для простоты действий, мы замеряли бэкап и восстановление обычными pg_dump и pg_restore (да, это упрощенное измерение, однако использование схемы с PITR не повлияет значительно на скорость).

4. Integrated Storage (Raft)

Однако обзор не был бы полным без самого удобного и простого на сегодняшний день бэкенда Raft. Благодаря тому, что Raft полностью дублирует все данные на каждый из узлов, выполнять снапшот можно на любом сервере, где запущен Vault. А сами действия для этого предельно просты.

Для создания снимка необходимо:

. Зайти на сервер/pod, где запущен Vault, и выполнить команду:

# vault operator raft snapshot save backup.snapshot

2. Забрать файл backup.snapshot (заархивировать и перенести в место для хранения бэкапов).

Для восстановления команду на сервере с Vault надо заменить на:

# vault operator raft snapshot restore backup.snapshot

Как работать с Raft и со снапшотами, хорошо описано в официальной документации.

Простой бенчмарк

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

Загрузка данных в Vault

Перед началом тестирования загрузим данные в Vault. Мы для этого использовали официальный репозиторий от HashiCorp: в нем есть скрипты для вставки ключей в Vault.

Протестируем на двух коллекциях: 100 тысяч и 1 млн ключей. Команды для первого теста:

export VAULT_ADDR=https://vault.service:8200export VAULT_TOKEN=YOUR_ROOT_TOKENvault secrets enable -path secret -version 1 kvnohup wrk -t1 -c16 -d50m -H "X-Vault-Token: $VAULT_TOKEN" -s write-random-secrets.lua $VAULT_ADDR -- 100000

Эту операцию проделаем для всех инсталляций Vault, а затем повторим её для другого количества ключей.

Результаты

После загрузки данных мы сделали бэкап для всех 4 бэкендов. Бэкап для каждого hosted-бэкенда снимался на однотипной машине (4 CPU, 8 GB RAM).

Результаты сравнения по бэкапу и восстановлению:

* Восстановление бэкапа в GCS может происходить в нескольких вариантах:

1. Мы просто переключаем Vault на бэкапный бакет. В таком случае достаточно перезапустить Vault с новым конфигом и все сразу же заработает.

2. Загрузить файлы бэкапа в бакет через утилиту gsutil и уже после этого переключать. Результаты для такого варианта будут зависеть от количества файлов и их размера в таблице приведен результат именно для такого варианта.

NB. В этом мини-тестировании сравниваются решения разного рода: single-экземпляр PostgreSQL против кластеров Consul и Raft против сетевого распределённого хранилища (GCS). Это может показаться не совсем корректным, потому что у таких бэкендов и разные возможности/свойства (отказоустойчивость и т.п.). Однако данное сравнение приведено исключительно как примерный ориентир для того, чтобы дать понимание порядковой разницы в производительности. Ведь это зачастую является одним из факторов при выборе того или иного способа.

Выводы

PostgreSQL занимает уверенное первое место по скорости создания бэкапа. Raft не так сильно отстает от лидера на небольшом объеме секретов, но разница заметно возрастает при увеличении количества данных. Однако в то же время Raft явно лидирует в скорости восстановления.

Если сравнивать удобство, то Raft и Consul максимально простые: для выполнения бэкапа и восстановления достаточно выполнить буквально одну команду. GCS же предоставляет встроенный функционал в UI для копирования бакетов: на мой вкус, это немного сложнее, однако для других пользователей может быть плюсом, что все действия выполняются мышкой в браузере. Но в GCS есть существенная проблема с отсутствием гарантий по времени создания снапшотов: одинаковый набор данных может бэкапиться как за 1 час, так и за 3-4 часа.

Помимо производительности и удобства есть и другой критерий надежность. Вывод, казалось бы, довольно банален: чем менее надежен бэкенд, тем легче его бэкапить. Хотя Vault сам по себе позиционируется как приложение категории cloud native, его бэкап полностью зависит от выбранного бэкенда, и во многих случаях мы получим простой, что недопустимо для такого важного сервиса:

• В Consul можно ожидать проблем с чтением и записью при бэкапе/восстановлении данных.

• А у PostgreSQL при восстановлении.

• У GCS проблема другого характера: нет гарантий на скорость копирования.

Получается, что все эти решения имеют серьёзные недостатки, которые могут быть недопустимы в production. Понимая это, в HashiCorp и создали своё оптимальное решение Integrated Storage (Raft). В нём получается делать бэкапы полностью беспростойно и при этом быстро.

В итоге: если вам важна максимальная скорость для снятия и восстановления бэкапов, то подойдут PostgreSQL и Raft. В первом случае, однако, надо повозиться с удобством: чтобы все правильно настроить и автоматизировать, придется потратить время (и иметь экспертизу). Наш текущий выбор пал на Integrated Storage (Raft) как самый простой в использовании и надежный бэкенд.

P.S.

Читайте также в нашем блоге:

• Сравниваем производительность HashiCorp Vault с разными бэкендами;

• Как мы Elasticsearch в порядок приводили: разделение данных, очистка, бэкапы.

Нередко наши клиенты, уже использующие облака для работы с персональными данными, задаются вопросом: а подходят ли облачные сервисы для бэкапов ПДн? Сегодня мы на собственном опыте покажем, какие требования к резервному копированию ПДн и данных ГИС предъявляют регуляторы, как их выполняет сервис-провайдер в облаке и как мы решаем насущные задачи клиентов по обеспечению доступности персональных данных при использовании распределенной инфраструктуры.

Требования со стороны регуляторов

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

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

Если как следует ознакомиться с основным регулирующим законом, 152-ФЗ О персональных данных, а именно со ст. 19, можно увидеть следующее:

Статья 19. Меры по обеспечению безопасности персональных данных при их обработке

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

2. Обеспечение безопасности персональных данных достигается, в частности:

7) восстановлением персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;

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

Вывод 1, очевидный. Бэкапы не являются задачей на усмотрение оператора ПДн, а, согласно требованиям 152-ФЗ, лежат в его зоне ответственности: резервное копирование ПДн его прямая обязанность.

Строя свою ИС, работающую с ПДн и ГИС, важно учитывать требования приказов ФСТЭК 17 и 21, которые относят средства резервного копирования к средствам защиты информации.

Приказ ФСТЭК 17:

20. Организационные и технические меры защиты информации, реализуемые в информационной системе в рамках ее системы защиты информации, в зависимости от угроз безопасности информации, используемых информационных технологий и структурно-функциональных характеристик информационной системы должны обеспечивать: доступность информации

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

Приказ ФСТЭК 21:

ЗСВ.8 Резервное копирование данных, резервирование технических средств, программного обеспечения виртуальной инфраструктуры, а также каналов связи внутри виртуальной инфраструктуры

ОДТ.4 Периодическое резервное копирование персональных данных на резервные машинные носители персональных данных

ОДТ.5 Обеспечение возможности восстановления персональных данных с резервных машинных носителей персональных данных (резервных копий) в течение установленного временного интервала

Вывод 2. Клиент, работая с ПДн в облаке, обязан решить вопрос доступности информации и, как следствие, регулярно выполнять резервное копирование.

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

• Приказ ФСБ 416, ФСТЭК 489 от 31.08.2010

• Постановление Правительства от 18.05.2009 424

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

Вывод 3. Приказы выше не устанавливают никаких требований к техническим особенностям системы или методикам выполнения резервного копирования. Однако максимальное время, за которое необходимо восстановить доступ к данным, зафиксировано в этих нормативных актах и составляет 8 часов.

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

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

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

Как решаются вопросы бэкапа со стороны провайдера

Наше облако аттестовано по требованиям УЗ-1 и К1, соответственно, в нем уже решены два типа задач:

• резервное копирование непосредственно облачной инфраструктуры и обеспечение высокой доступности данных;

• предоставление бэкап-сервисов пользователям этого облака.

В части обеспечения доступности информации (ОДТ) мы как провайдер решаем следующие задачи:

• Периодическое резервное копирование конфигурации компонентов инфраструктуры защищенного сегмента на резервные носители информации (ОДТ.4).

• Обеспечение возможности восстановления конфигурации компонентов инфраструктуры защищенного сегмента облака с резервных носителей (т.е. из резервных копий) в течение установленного временного интервала (ОДТ.5).

В части защиты среды виртуализации (ЗСВ):

Резервное копирование данных, резервирование технических средств, программного обеспечения виртуальной инфраструктуры, а также каналов связи внутри виртуальной инфраструктуры защищенного сегмента облака (ЗСВ.8).

Технически эти требования по резервному копированию облачной инфраструктуры реализуются на базе продуктов Veeam. Они хорошо зарекомендовали себя в системах виртуализации. Но это не единственная причина, почему для сегмента 152-ФЗ мы выбрали именно это решение:

• Veeam Backup & Replication имеет сертифицированную версию с классификацией по 4-му уровню отсутствие декларированных возможностей;

• благодаря наличию сертификата с ним легко проходить аттестацию.

Использование этого решения позволяет нам не только защищать свою инфраструктуру, но и предоставлять возможности резервного копирования пользователям нашего защищенного облака. С помощью Veeam пользователи облака могут бэкапить компоненты своей ИС, выполняя все требования регуляторов, которые мы обсудили выше.

Клиенты нашего облака в рамках одной инфраструктуры получают не только соответствующее 152-ФЗ IaaS-решение, но и готовый инструмент бэкапа, ответственность за который лежит на наших плечах. Пользователю остается лишь корректно настроить задачи резервного копирования и следить за их выполнением.

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

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

Бэкап персональных данных с собственной локальной площадки в облако

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

Рассмотрим каждый из этих вопросов подробнее на практике.

1. Как выполнить безопасный обмен данными между площадкой клиента и облаком?

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

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

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

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

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

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

3. Реализация отказоустойчивой архитектуры решения

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

Своим клиентам мы предлагаем решение на базе продуктов С-Терра. Этот инструмент решает все задачи организации высоконадежной и защищенной связности двух площадок для передачи бэкапов ПДн. В линейке продуктов С-Терра имеются различные варианты программно-аппаратных и виртуальных криптошлюзов. Благодаря широкой линейке можно подобрать оптимальное решение как по производительности, так и по и отказоустойчивости. Производительность шлюзов С-Терра в зависимости от модификации варьируется от 100 Мбит/c до 10 Гбит/с, поэтому и клиент, и мы как провайдер всегда сможем подобрать наиболее оптимальное для своих задач решение.

Варианты подключения локальной площадки клиента к BaaS-сервису

Обмен данными между площадками может быть организован двумя способами.

1. Veeam Cloud Connect Backup

   Схема используется в том случае, когда у клиента есть сервер Veeam Backup & Replication. Он выполняет резервное копирование объектов со своей площадки, а облако используется как репозиторий. Связь организуется между самим Veeam Backup & Replication и репозиторием через описанный выше защищенный канал связи.

   

2. С использованием агентов

   В случае, когда у клиента отсутствует сервер Veeam Backup & Replication на своей площадке, вместо него для резервного копирования используются агенты на серверах и ВМ. Управление осуществляется через Veeam Service Provider Console.

   

Эти сценарии в дальнейшем могут обеспечить и другие возможности.

• Восстановление в облако провайдера

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

• Миграция инфраструктуры

В случае, если клиент хочет перенести данные с одной площадки на другую, VCC позволяет решить и такую задачу.

А вот и продолжение истории из начала статьи, как говорится, это еще не все!

- А вы что, не делали мне бэкапы!? Зачем я тогда вообще размещаюсь по-вашему???

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

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

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

Как пропадают данные?

Потеря данных это действительно ужасная ситуация, все это понимают. Сотни оплаченных человеко-часов / результаты труда сотрудников, которые хранятся на серверах это не только деньги, это и ответственность и репутация. Восстановление же (*или попытки восстановления) данных после утери это тоже процесс очень трудоемкий и затратный. Само собой, наличие бэкапов это крепкий сон любого причастного сотрудника, но случиться может все что угодно:

• молния ударила в дата-центр Google;

• что-то пошло не так при миграции сервера и MySpace потеряла все данные пользователей за 12 лет с 2003 по 2015 годы (включая музыку, фотографии и видео);

• 16000 результатов тестов на коронавирус было утеряно из-за технической ошибки в Excel в Великобритании, подробности не уточняются;

• Яндекс удалил виртуальные машины активных пользователей, применив некорректную фильтрацию и перепутав их с должниками;

• администратор ошибся, а gitlab лишился базы данных объемом 300Гб;

• в результате кибератаки вируса-шифровальщика все данные в базе данных компании ISS World были утеряны.

Это малая часть известных случаев, которые афишировали на просторах интернета. Частностей на порядки больше, так что, лишний раз проверим наличие свежих бэкапов и идем дальше.

Наивность и дебиторка

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

Простым показателем этого может стать ваш (как человека, сотрудничающего с тем или иным хостером) селф-тест, спросите себя, а что произойдет, если вы не успеете вовремя оплатить? Прописаны ли эти сроки в договоре? Предлагались ли вам дополнительные услуги? Поинтересовался ли менеджер о том, насколько стратегически важная система будет находиться на вашем сервере?

Но вернемся к оплате, это наиболее частая ситуация, с которой сталкивалось большинство. Да и причины бывают разнообразные:

• оплатить забыли или не успели;

• сейчас нет денег;

• не получили счет и забили;

• бухгалтерия где-то как-то что-то;

• прочая бюрократия.

Как хостеры обращаются с данными

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

Для понимания, обрисую ситуацию, которую мы транслировали при общении:

Первое число месяца, с баланса списывается абонентская плата и образуется минус, для простоты счёта, представим, что мы должны хостеру денег ровно за один месяц. Рассматривались такие услуги как аренда физического сервера (dedicated) и аренда виртуального сервера, т.к. я искренне (а может и наивно) полагаю, что мой личный сервер на размещении (colocation) не пропадет просто так, как и данные с него.

Первый вопрос довольно безобидный.

Как быстро, с момента образования задолженности сервер будет отключен?

Работа встала, но еще не все потеряно.

Однако, что происходит после того, как предоставление услуг приостановлено?

После появления задолженности, в какие сроки сервер будет разукомплектован / удален?

Аренда физического сервера:

Аренда виртуального сервера:

Случилось страшное. Сервер разукомплектован или удален, но может быть еще есть шанс, что данные можно восстановить?

После того, как сервер разукомплектовали / удалили, есть ли возможность восстановить данные?

Аренда физического сервера:

Аренда виртуального сервера:

Раз уж статистика такая, может быть хостеры предлагают бэкапы, которые входят в услугу по умолчанию? (тут речь только про виртуальные сервера, для физических сразу 100% нет, что логично)

Имеется ли резервное копирование, которое входит в стоимость услуги по умолчанию?

Вместо выводов могу лишь смоделировать ситуацию при которой в случае отсутствия бэкапов, которые хранятся не у вашего хостера (кто знает, может их тоже оперативно удаляют) при задержке оплаты на 2 недели вы потеряете свои данные с вероятностью 70%. И не нужно молний, наводнений и апокалипсиса.

Что еще можно отнести к наивности?

Значок Договор, покажи ему свой договор! (с)

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

Под меня будут подстраиваться. Уверены?

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

Ситуация, когда наша бухгалтерия платит только по четвергам (с) не единична, но весьма комична.

А мы счет не получали! (с)

А мы отправляли! (с) - вот типичный ответ, который можно получить в такой ситуации. Хостер получит свои деньги, просто позже, а вот что он сделает с сервером на время ожидания остается за кулисами, но не для того, кто счет не получил.

Вы же профессионалы (с)

Этим многие любят оправдывать неприятные ситуации, которые случаются. Да, профессионалы, но далеко не все услуги и уж тем более профессионалов включены по умолчанию. Тут можно вернуться к пункту про договор и забыть про экономию, так как многие клиенты именно в целях экономии отказываются от предлагаемых им дополнительных услуг, самостоятельно настраивают бэкапы, но не мониторят их. Сделали и забыли. А лучше бы доверились тем самым профессионалам.

Уходя, гасите свет (с)

Речь про забывчивость и утилизацию. Когда закончили аренду, сотрите данные и перезапишите диски. Уничтожьте бекапы у хостера. Просто правило хорошего тона как блокировать консоль и чистить зубы на ночь. В идеале это должен делать хостер, но должен ли? На Бога надейся, а сам не плошай (с)

Заключение

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

• делайте бэкапы и храните их отдельно от сервера в другом дата-центре, а лучше в нескольких местах;

• проверяйте бэкапы (а можно ли из них что-то развернуть?);

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

• убедитесь, что вы точно получите счет за услуги, резервируйте получателей;

• настройте автоплатеж, если не задействована бухгалтерия;

• если бухгалтерия имеет место быть - объясните ей, что сначала нужно заплатить, а потом решать любые возникающие вопросы, промедление может оказаться фатальной ошибкой;

• спросите у своего хостера про бэкапы и другие, пусть даже самые очевидные ситуации;

• поинтересуйтесь у вашего менеджера как принято работать с дебиторкой, какие сроки у вас есть и как можно их оттянуть;

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

• не будьте наивными, это дорогого стоит.

Тут еще планировался большой текст о том, как работают с дебиторкой в нашем дата-центре, но в голову пришло два тезиса:

1. Мы не сможем точно ответить на ряд вопросов, потому что подход индивидуальный (и вот тут придется объясниться);

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

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

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

Да, у нас есть бэкапы по умолчанию для виртуальных серверов, но спросите менеджера когда исчезнут ваши данные и он не ответит. Почему? Потому что подход все еще индивидуальный. Факторов масса, но один, наиболее важный - мы не доверяем автоматизированным оповещениям. Счета рассылаются автоматически по электронной почте, туда же, с завидной периодичностью падают письма с напоминанием и дублем счета. Еще мы используем смс-оповещение, остановились на API greensms.ru, но это все автоматика.

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

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

Исключения наверное есть, но это те, кто:

а) не прислал платежку;

б) пользуется этим лайфхаком с завидной регулярностью.

И да, наш менеджер принимает платежки и гарантийные письма, без фанатизма, но почему бы и нет.

Берегите свои данные, не позволяйте хостерам их уничтожать!