Продолжение «опытных мелочей». Предыдущие части: раз, два, три.Сегодня я расскажу о принципах делания бэкапа, которые выстроились в результате проб и ошибок, и не раз спасали ситуацию в самый, казалось бы, неожиданный момент.
Бэкапы — это страховка компании от несчастного случая. Делать бэкапы — это даже не правило, это аксиома. Какой бы ни был прожженный админ, и у него иногда может «дрогнуть рука», и с ошибкой написанный скрипт, или случайно нажатая кнопка способны наворотить много бед, что уж говорить про посыпавшиеся HDD, пожар и прочие катаклизмы. Да, бэкапы затратны (время, ресурсы, оборудование), их сиюминутный эффект неочевиден, но главное что они дают — страховка рисков компании. А это — дорогого стоит. Казалось бы, утверждения понятные всем, но при этом нередко возникает ситуация, когда сервер упал, бэкап есть, а сделать ничего нельзя, система не восстанавливается. И начинаются пляски для бубна с оркестром, вытаскивание хоть каких-то данных и т.п. радости.
Для начала давайте введем и четко разделим такие понятия как архивирование и бэкап. Например вот так:
- Архивирование — это резервное копирование с ДОЛГОСРОЧНЫМ хранением данных. Процедура, когда один раз скопировали, и унесли в банковский сейф. Обращение в архив, это скорее исключение чем правило, и процедура это может быть довольно длительной (в зависимости от того где и как хранятся архивы).
- Бэкап — это резервное копирование с КРАТКОСРОЧНЫМ хранением данных. Процедура, когда копирование происходит регулярно, носители перезаписываются, есть понятие «глубина хранения». При этом доступ к бэкапу обычно должен быть максимально быстрым.
Архивирование
Архивирование нужно не всем и не всегда. Чаще всего этот вопрос встает, когда компания выходит за рамки «я, мой друг, жена и курьер», и касается обычно только файлов, финансовых баз, почтовых баз, т.е. тех документов, которые и неэлектронной жизни принято хранить в архивах (письма, приказы, бухгалтерская первичка и т.п.).
Архивы обычно делаются раз в год и хранятся на внешних носителях где-нибудь в сейфе, в банковской ячейке, на даче у гендиректора (нужное подчеркнуть). Тут все в целом понятно, главное не забывать хотя бы раз в год проверять состояние архива (например одновременно с записыванием нового восстановить часть данных из старого), и следить за носителями, чтобы вы всегда могли прочитать архив любой глубины (например, у меня была ситуация, когда потребовался архив, который был сделан 5 лет назад, и хранился на ленте, стример для которой не только был сломан и списан, но и уже давно не выпускался. Архив конечно прочитали, но сколько нервов и связей для этого потребовалось — лучше не вспоминать).
Последние пару лет, кстати, все чаще для архивов используем не ленты, а банальные HDD. Их объемов- хватает, скорость работы — достаточна для архива, цена — в рамках разумного, а единый интерфейс подключения (раньше IDE, сейчас SATA) устраняет проблему «сломанного стримера», что немаловажно, т.к. данные можно прочитать практически на любом компьютере, без привлечения спец оборудования (как в случае с лентами). Когда IDE совсем пропадет, вероятно скопируем на SATA (или что там будет после).
Бэкап
Задача бэкапа как такового — хранить свежие резервные копии, для быстрого восстановления «случайно\специально удаленного», или «сгоревшего», или «неправильно сконфигурированного». Если архивы обычно хранятся столько сколько живет организация, а иногда и дольше, то для бэкапов уже можно ввести понятие глубина хранения, т.е. время по истечение которого бэкап будет устаревать, и его можно перезаписать более свежими данными. Бэкап в целом можно разделить на две основные части: бэкап данных и бэкап систем, и отдельно стоящий бэкап содержимого систем. Последнее очень обширная и конкретная тема, сильно зависящая от того, содержимое каких именно систем вы хотите бэкапить (почтовый сервер, БД, CRM, настройки ПО и т.п.), здесь ее описывать не будем.
Бэкап систем
Бэкап систем — это когда вам нужно бэкапить не отдельные файлы, а целиком всю систему, которая может состоять из нескольких компонентов (например, спец-ПО, база SQL, файловые данные), и восстанавливать ее лучше целиком, нежели по частям. Тут все довольно просто: выбираете устраивающий вас бэкап-софт (цена, функционал, удобство) и бэкапите систему так, чтобы вы гарантированно могли восстановить ее, даже в случае полной поломки сервера. Подходят всевозможные Acronis'ы, Symantec System Recovery и т.д. Важно помнить вот что:
- вы должны УМЕТЬ восстанавливать из бэкапа. Тренируйтесь где угодно, когда угодно, но вы ДОЛЖНЫ УМЕТЬ это делать.
- продумывайте что именно вы бэкапите. Это значимо для универсальных серверов, когда, например, на одном сервере крутится БД, ваш внутрикорпоративный сайт и дополнительно прицеплен том под файловые ресурсы. В такой ситуации не стоит ради бэкапа связки «сложнонастроенный SQL + ваш сайт» бэкапить с ним заодно еще и второй файловый том в 1500 Тб. Вообще стремитесь к ситуации «одна задача — один сервер», не вешайте все-все-все на одну машину, а если уж повесили то бэкапьте его «системно».
- ваш софт должен уметь восстанавливать на другое железо, отличающееся от текущего. И вы должны это хотя бы раз попробовать!
- «системные» бэкапы, особенно систем постоянно используемых, не стоит хранить глубиной более чем неделя. Подумайте сами, зачем вам бэкап вашего контроллера домена давностью в месяц? В случае критической ситуации вам понадобится САМЫЙ свежий бэкап. А все остальные — это подстраховка, на случай если «самый свежий» по каким то причинам не отработал. Отводить на такую подстраховку больше чем 1-2 итерации, на мой взгляд нелогично и излишне расходует место.
- есть системы, которые сложно взаимосвязаны со всей инфраструктурой, и восстановить их, даже имея под рукой свежий «системный бэкап» конкретного сервера, бывает нелегко. Навскидку: Active Directory, Exchange и т.д. Выделите время, изучите документацию, и в тестовой среде, хотя бы раз — но попробуйте восстановить АБСОЛЮТНО ВСЕ! Лучше научитесь это делать в спокойной обстановке с Интернетом под рукой, чем с разъяренным начальником над головой.
Бэкап данных
Бэкап данных, это бэкап отдельных, самостоятельных данных (в основном это содержимое вашего корпоративного файлохранилища). Здесь много мудрости не нужно — бери да копируй, можно разве что поразмышлять над схемой бэкапа. Я, например, придерживаюсь следующей схемы:
- По выходным делается полный бэкап всех данных. Глубина хранения 28 дней, т.е. есть четыре независимых полных бэкапа. Таким образом за последний месяц мы сможем восстановить данные за любой выходной день.
- По рабочим дням делается дифференциальный бэкап, с глубиной хранения 14 дней. Таким образом за последние две недели мы можем восстановить данные за любой из дней.
- в первые выходные каждого месяца, отдельно от остальных работ, делается месячный бэкап, с глубиной хранения в 12 месяцев. Это нечто среднее между бэкапом и архивом. С одной стороны срок хранения довольно большой, с другой — нередка ситуация когда нужно восстановить данные «пару месяцев назад, максимум полгода». Как вариант, можно не делать месячный бэкап отдельной работой, а просто копировать подходящий недельный.
Кроме того, я стараюсь придерживаться вот каких правил:
- использую дифференциальный, а не инкрементальный бэкап. (Если вы не знаете что это такое — обязательно прочитайте документацию, это весьма важные понятия). Мне важнее выигрыш в скорости восстановления, нежели в объеме резервных копий.
- планирую время бэкапа так чтобы успевать до утра. Если бэкап выполняется дольше — разбиваю его на несколько работ, несколько серверов, или поднимаю вопрос про другое, более скоростное, оборудование.
- в расписании бэкапа стараюсь придерживаться промежутков связанных с неделями(7 дней, 28 дней и т.д.) и не привязываться к «первым\последним дням месяца». Неделя — довольно постоянная величина, 7 дней и в большинстве случаев суббота, воскресенье — это выходные.
- использую диски, а не ленты. Мне не нравится дорогостоящий посредник-стример между данными в бэкапе и данными в файлохранилище. Если он по каким то причинам не работает, то надолго нарушается вся система бэкапа. Если использовать жесткие диски, то этого можно избежать.
- стараюсь чтобы логически самостоятельная часть данных лежала в отдельном бэкапе. Например, если говорить про Symantec Backup Exec, то одна работа=одна media. Очень не люблю ситуацию, когда одна работа «размазана» по нескольким файлам. Это не только вносит сумбур в систему, но и в случае случайного затирани одного из файлов («рука дрогнула») наносит вред не только одной работе но и всем соседним.
- в обязательном порядке использую софт с уведомлениями по почте. Если это самописный скрипт — никто не мешает дописать кусочек, который будет проверять хотя бы наличие нового бэкапа, его размера и слать данные по почте. Это сильно экономит время в мониторинге бэкапа.
Кроме всего прочего модно также использовать т.н. «моментальные» бэкапы, небольшой глубины (1-2 дня) а-ля служба VSS в Windows, когда пользователи сами могу выбирать что восстановить из последних версий документа. Это очень помогает, когда пользователь утром отредактировал документ, а в обед его удалил и прсит восстановить утренний вариант.
Также можно использовать DFS систему в роли постоянного онлайн бэкапа, но это стоит описать в отдельном посте, что я позже и сделаю.
Продолжение следует.
P.S. Напомню, я не устанавливаю правил, а делюсь своим опытом, опытом НЕуниверсальным, полученным в небольших организациях (30-500 ПК). Если у вас принято делать иначе — с удовольствие прочитаю об этом в комментариях.
