Как я спасаю данные каждый день (или не спасаю): часть вторая⁠⁠

Wubba Lubba Dub-Dub, пикабушники, я вернулся из отпуска (но об этом отдельно).

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

Как говорится: хорошая статья — залог успеха, заключённые согласятся, а мы поехали.

Давным-давно это был самый обычный кабинет под номером 611. В нём мирно и активно работали сначала продажники, после них продакт-менеджеры и не знали они бед. Мир шатко держался в равновесии, пока однажды народ инженеров не развязал войну и не отнял эту территорию. Хотя по некоторым данным кабинет освободился в ковидные времена, ну да ладно, в нём всё равно никто не сидел в период "самоизоляции".

С тех самых пор как в него перебрался я, бывший инженер службы эксплуатации центров обработки данных (ЦОД) и нынешний инженер систем резервного копирования, кабинет превратился во всеми почитаемый «Душный уголок», который открыт избранным и закрыт… неизбранным ¯\_(ツ)_/¯.

В нашем кабинете воистину собрались настоящие душнилы, но в то же время профессионалы своего дела. Я и коллеги совместными стараниями поддерживаем всю IT-инфраструктуру наших Заказчиков, будь то серверы, СХД, LAN/SAN, виртуализация, облачные сервисы, ОС, прикладные службы и СРК, само разумеется.

Так вот продолжим тему СРК. Со времён ещё когда-то тогдашнего ведения своей деятельности иностранных вендоров на территории РФ наша команда бэкаперов занималась поддержкой таких решений как Veritas NetBackup и Backup Exec, EMC NetWorker, CommVault и IBM TSM (последними двумя занималась только часть моих коллег, т.к. проектов по ним было не так много). В Veeam мы, конечно, тоже можем, но кейсов по ним на нас прилетало не так много.

Сейчас, после начала специального крестового похода, когда иностранные вендоры ушли, мы продолжаем пользоваться нашей богатой экспертизой и поддерживать эти продукты у тех, у кого они ещё остались, но также наш портфель пополнился свежими решениями: Кибер Бэкап, РуБэкап и парочка китайских Aishu AnyBackup и VinChin. Open source решения мы не поддерживаем, т.к. профита в такой поддержке нет. К тому же комьюнити само по себе хорошо справляется с настройкой и траблшутингом.

Чем бэкапим мы разобрались. А вот на что — тут уже зоопарк поразношёрстнее. Тут всё работает по классике: "горячие" данные крутятся на SSD-стораджах, а вот "холодные" и "архивные" уже у нас на HDD и ленточных носителях. В самых редких случаях используются и VTL (Virtual Tape Library). Я уже понял, что вам интересно узнать обо всём чуточку подробнее, поэтому в дальнейшем планирую выпустить статьи по терминологиям и компонентам СРК. Пишите в комментариях о чём вам хотелось бы узнать.

В комментариях к прошлому посту упомянули про такое золотое правило как «3-2-1». Оно гласит следующее: храни не менее 3 копий — 2 на нескольких разных хранилищах и 1 на удалённом. Это самое короткое пояснение, но не самое подробное. На самом деле у нас есть своё правило, которое звучит так: «Храни копии так, чтобы ты всегда смог из них восстановиться».

Можно бесконечно много проектировать инфраструктуру так, чтобы у тебя был переизбыток, но это не всегда оправдано, т.к. бэкапы не ограничиваются 3 копиями. Обычно это длинные цепочки полных и промежуточных копий, которые хранятся месяцами и важно осознанно подходить к тому, что тебе нужно хранить, а что нет. И тебе обязательно нужно учитывать как оно хранится: в каком виде, как получить доступ к этим копиям, а как получить доступ, если доступа не будет. И это не правило резервного копирования — это серьёзная задача к построению отказоустойчивости и катастрофоустойчивости всей инфраструктуры.

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

Сейчас важно лишь понимать, что в нашем случае есть несколько типов сетей: вычислительная сеть (LAN/WLAN), через которую проходит связь компонентов и взаимодействие протоколов, обеспечивающих мониторинг, управление, да в принципе любое привычное взаимодействие компьютеров, серверов и периферии; и сеть хранения данных (SAN), через которую осуществляется выделенная высокоскоростная передача данных между системами и устройствами хранения.

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

В нашей работе мы придерживаемся традиционных планов РК (резервного копирования), в которых любое взаимодействие с данными продуктивных систем происходит в наименее загруженные часы. Как правило, это время с 20:00 до 08:00 в будние дни и выходные дни целиком, если это компания с базовым 5-дневным графиком. Однако для каждой компании могут быть свои исключения вплоть до определённой информационной системы.

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

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

Копия прошла проверку? — Хорошо, однако это всё равно не гарантирует нам того, что в нужный момент мы сможем из неё восстановиться. Почему? — Потому что в нашей работе на всё нужно смотреть пессимистично. Чем больше ты найдёшь для себя причин «почему это сломается» — тем больше ты проработаешь моментов, которые увеличат шансы на успех. Поэтому мы всегда в первую очередь обращаем внимание не на то, сколько копий мы храним, а как мы это делаем.

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

Поэтому несмотря на все мемы — к бэкаперам обращаются чаще всего тогда, когда либо кто-то что-то нажал и всё пропало (в случае с плохим мануал-терапевтом мы тут вам не поможем), либо когда всё сломалось настолько, что спасут только бэкапы.

Увидимся в новых сериях!