Как стать автором
Обновить

Опытные мелочи-4, или «Померяемся бэкапами?»

Время на прочтение 6 мин
Количество просмотров 32K
image Продолжение «опытных мелочей». Предыдущие части: раз, два, три.

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

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

Для начала давайте введем и четко разделим такие понятия как архивирование и бэкап. Например вот так:
  • Архивирование — это резервное копирование с ДОЛГОСРОЧНЫМ хранением данных. Процедура, когда один раз скопировали, и унесли в банковский сейф. Обращение в архив, это скорее исключение чем правило, и процедура это может быть довольно длительной (в зависимости от того где и как хранятся архивы).
  • Бэкап — это резервное копирование с КРАТКОСРОЧНЫМ хранением данных. Процедура, когда копирование происходит регулярно, носители перезаписываются, есть понятие «глубина хранения». При этом доступ к бэкапу обычно должен быть максимально быстрым.

Архивирование



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

Последние пару лет, кстати, все чаще для архивов используем не ленты, а банальные HDD. Их объемов- хватает, скорость работы — достаточна для архива, цена — в рамках разумного, а единый интерфейс подключения (раньше IDE, сейчас SATA) устраняет проблему «сломанного стримера», что немаловажно, т.к. данные можно прочитать практически на любом компьютере, без привлечения спец оборудования (как в случае с лентами). Когда IDE совсем пропадет, вероятно скопируем на SATA (или что там будет после).

Бэкап


Задача бэкапа как такового — хранить свежие резервные копии, для быстрого восстановления «случайно\специально удаленного», или «сгоревшего», или «неправильно сконфигурированного». Если архивы обычно хранятся столько сколько живет организация, а иногда и дольше, то для бэкапов уже можно ввести понятие глубина хранения, т.е. время по истечение которого бэкап будет устаревать, и его можно перезаписать более свежими данными. Бэкап в целом можно разделить на две основные части: бэкап данных и бэкап систем, и отдельно стоящий бэкап содержимого систем. Последнее очень обширная и конкретная тема, сильно зависящая от того, содержимое каких именно систем вы хотите бэкапить (почтовый сервер, БД, CRM, настройки ПО и т.п.), здесь ее описывать не будем.

Бэкап систем

Бэкап систем — это когда вам нужно бэкапить не отдельные файлы, а целиком всю систему, которая может состоять из нескольких компонентов (например, спец-ПО, база SQL, файловые данные), и восстанавливать ее лучше целиком, нежели по частям. Тут все довольно просто: выбираете устраивающий вас бэкап-софт (цена, функционал, удобство) и бэкапите систему так, чтобы вы гарантированно могли восстановить ее, даже в случае полной поломки сервера. Подходят всевозможные Acronis'ы, Symantec System Recovery и т.д. Важно помнить вот что:
  • вы должны УМЕТЬ восстанавливать из бэкапа. Тренируйтесь где угодно, когда угодно, но вы ДОЛЖНЫ УМЕТЬ это делать.
  • продумывайте что именно вы бэкапите. Это значимо для универсальных серверов, когда, например, на одном сервере крутится БД, ваш внутрикорпоративный сайт и дополнительно прицеплен том под файловые ресурсы. В такой ситуации не стоит ради бэкапа связки «сложнонастроенный SQL + ваш сайт» бэкапить с ним заодно еще и второй файловый том в 1500 Тб. Вообще стремитесь к ситуации «одна задача — один сервер», не вешайте все-все-все на одну машину, а если уж повесили то бэкапьте его «системно».
  • ваш софт должен уметь восстанавливать на другое железо, отличающееся от текущего. И вы должны это хотя бы раз попробовать!
  • «системные» бэкапы, особенно систем постоянно используемых, не стоит хранить глубиной более чем неделя. Подумайте сами, зачем вам бэкап вашего контроллера домена давностью в месяц? В случае критической ситуации вам понадобится САМЫЙ свежий бэкап. А все остальные — это подстраховка, на случай если «самый свежий» по каким то причинам не отработал. Отводить на такую подстраховку больше чем 1-2 итерации, на мой взгляд нелогично и излишне расходует место.
  • есть системы, которые сложно взаимосвязаны со всей инфраструктурой, и восстановить их, даже имея под рукой свежий «системный бэкап» конкретного сервера, бывает нелегко. Навскидку: Active Directory, Exchange и т.д. Выделите время, изучите документацию, и в тестовой среде, хотя бы раз — но попробуйте восстановить АБСОЛЮТНО ВСЕ! Лучше научитесь это делать в спокойной обстановке с Интернетом под рукой, чем с разъяренным начальником над головой.

Бэкап данных

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

  1. По выходным делается полный бэкап всех данных. Глубина хранения 28 дней, т.е. есть четыре независимых полных бэкапа. Таким образом за последний месяц мы сможем восстановить данные за любой выходной день.
  2. По рабочим дням делается дифференциальный бэкап, с глубиной хранения 14 дней. Таким образом за последние две недели мы можем восстановить данные за любой из дней.
  3. в первые выходные каждого месяца, отдельно от остальных работ, делается месячный бэкап, с глубиной хранения в 12 месяцев. Это нечто среднее между бэкапом и архивом. С одной стороны срок хранения довольно большой, с другой — нередка ситуация когда нужно восстановить данные «пару месяцев назад, максимум полгода». Как вариант, можно не делать месячный бэкап отдельной работой, а просто копировать подходящий недельный.

Кроме того, я стараюсь придерживаться вот каких правил:
  • использую дифференциальный, а не инкрементальный бэкап. (Если вы не знаете что это такое — обязательно прочитайте документацию, это весьма важные понятия). Мне важнее выигрыш в скорости восстановления, нежели в объеме резервных копий.
  • планирую время бэкапа так чтобы успевать до утра. Если бэкап выполняется дольше — разбиваю его на несколько работ, несколько серверов, или поднимаю вопрос про другое, более скоростное, оборудование.
  • в расписании бэкапа стараюсь придерживаться промежутков связанных с неделями(7 дней, 28 дней и т.д.) и не привязываться к «первым\последним дням месяца». Неделя — довольно постоянная величина, 7 дней и в большинстве случаев суббота, воскресенье — это выходные.
  • использую диски, а не ленты. Мне не нравится дорогостоящий посредник-стример между данными в бэкапе и данными в файлохранилище. Если он по каким то причинам не работает, то надолго нарушается вся система бэкапа. Если использовать жесткие диски, то этого можно избежать.
  • стараюсь чтобы логически самостоятельная часть данных лежала в отдельном бэкапе. Например, если говорить про Symantec Backup Exec, то одна работа=одна media. Очень не люблю ситуацию, когда одна работа «размазана» по нескольким файлам. Это не только вносит сумбур в систему, но и в случае случайного затирани одного из файлов («рука дрогнула») наносит вред не только одной работе но и всем соседним.
  • в обязательном порядке использую софт с уведомлениями по почте. Если это самописный скрипт — никто не мешает дописать кусочек, который будет проверять хотя бы наличие нового бэкапа, его размера и слать данные по почте. Это сильно экономит время в мониторинге бэкапа.

Кроме всего прочего модно также использовать т.н. «моментальные» бэкапы, небольшой глубины (1-2 дня) а-ля служба VSS в Windows, когда пользователи сами могу выбирать что восстановить из последних версий документа. Это очень помогает, когда пользователь утром отредактировал документ, а в обед его удалил и прсит восстановить утренний вариант.
Также можно использовать DFS систему в роли постоянного онлайн бэкапа, но это стоит описать в отдельном посте, что я позже и сделаю.

Продолжение следует.

P.S. Напомню, я не устанавливаю правил, а делюсь своим опытом, опытом НЕуниверсальным, полученным в небольших организациях (30-500 ПК). Если у вас принято делать иначе — с удовольствие прочитаю об этом в комментариях.
Теги:
Хабы:
+55
Комментарии 47
Комментарии Комментарии 47

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн