В прошлый раз я рассказал вам, не побоюсь этого слова, кровавую историю, как мы срочно спасали сначала инсталляцию, а потом уже и данные. И такие истории лишний раз дают понять важность наличия бэкапа и правильность его настройки. Сегодня я хочу суммировать свои мысли, накопленные за последние 10 лет опыта работы в системном интеграторе.
1. Бэкап должен быть всегда.
Как бы не развивались технологии, старая добрая резервная копия никогда не потеряет своей ценности, в трудную минуту сохраняя нам нервы, работу, премию, а также успокоительные средства. Она, в случае чего, позволяет нам не паниковать, действовать взвешено, допуская разумный риск.
Даже если в вашем сервере все компоненты дублированы, а данные лежат на дорогом массиве с избыточностью, отгоните от себя ложное чувство безопасности. Никто не застрахован от логических ошибок и человеческого фактора.
Пример из жизни. Недолгое время у одного из наших заказчиков работал некий товарищ, который, хоть был еще не стар, вел себя как Леонид Ильич в рассвете паралитических недугов. Он ходил вразвалку, неторопливо и с наслаждением разговаривал, то и дело причмокивая. Любая деталь подолгу занимала его внимание. Однажды он набирал в юниксовой консоли команду rm -rf, и перед тем, как его отвлекли разговором, он успел еще добавить слэш, после чего переключился на собеседника. Когда разговор закончился, товарищ обернулся к монитору, нахмурился, силясь вспомнить, чем до этого занимался, и решительно прогнал проклятый скринсейвер, нажав на Enter. Надо ли говорить, что в этот момент информация, весело шурша винчестерами, удалялась со всех копий RAID и даже с удаленных реплик массива. Кстати, после этого случая я всегда возвращаю компьютер из режима сна клавишей Alt — так безопаснее.
2. Бэкап должен быть автоматическим.
Только автоматизированный бэкап, выполняющийся по расписанию, дает нам возможность восстановить относительно актуальные данные — например, от вчера, а не от марта месяца. Бэкап нужно делать также перед любыми потенциально опасными операциями, будь то модернизация оборудования, обновление микрокодов, установка патчей, миграция данных. Мы, к примеру, даже можем отказывать заказчику в подобных работах, если накануне не сделана резервная копия.
3. Восстановление из бэкапа — это крайняя мера.
Прибегать к восстановлению надо тогда, когда других шансов уже нет. Потому что это всегда медленно и это всегда спешка и стресс. Были в нашей практике случаи, когда админы у заказчиков накатывали не тот бэкап не на ту систему, только усугубляя ситуацию.
Поэтому восстанавливаться лучше не на исходное место на диске, чтобы не перезаписывать оригинальные данные, а куда-нибудь по соседству, чтобы была возможность проверить, что вы в итоге восстановили.
4. Бэкап нужно хранить отдельно от данных и минимум 2 недели.
Это рекомендуемый срок, чтобы даже нерасторопный бухгалтер успел опомниться, что у него что-то пропало или испортилось. Но можно хранить и дольше, если позволяет место.
Традиционно для хранения бэкапов используется магнитная лента благодаря ее дешевизне.
А еще ею удобно украшать к Новому Году серверную, особенно хорошо смотрятся композиции с оранжевой оптикой.
Для работы с лентой предназначены стримеры и ленточные библиотеки. В стример кассеты загружает человек, а в ленточной библиотеке – робот. Поэтому библиотека предпочтительнее, т.к. позволяет автоматизировать бэкап полностью.
Еще более предпочтительными являются дисковые хранилища, по мере удешевления производства это перестало быть роскошью. СХД отличаются скоростью работы и надежностью, конечно, при условии, что используется RAID. Есть так называемые виртуальные библиотеки – VTL – которые умеют прикидываться ленточной библиотекой, но данные записывают на диски.
5. Бэкап нужно регулярно проверять.
Главные недостатки ленты — последовательный доступ к информации и относительно низкая надежность хранения. Нет способа узнать, восстановится ли бэкап с ленты без ошибок, пока это не проверишь на практике. Дисковые хранилища, в отличие от ленты, защищены от размагничивания и, вообще, более предсказуемы. Тем не менее, регулярная проверка любого бэкапа позволяет спокойнее спать.
6. Полезно дублировать бэкап на удаленную площадку.
Техногенные катастрофы, отключения электричества в целом городе, нашествие зомби и прочие беды подстерегают бизнес на каждом углу. Особенно малоизученными остаются зомби. Поэтому хорошей практикой является наличие удаленной площадки, куда, так или иначе, попадают резервные копии.
Как это можно организовать? В простом случае кассеты извлекаются из библиотеки, и их отвозит куда-нибудь в Химки водитель дядя Вася. Понятно, что при восстановлении также участвует дядя Вася, поэтому он во всей цепочке является самой медленной стадией. Ну а для тех, кто сумел построить или использует на аутсорсинге полноценный резервный ЦОД с хорошим каналом, резервные копии можно автоматически дублировать при помощи современных средств резервного копирования. Например, имея на каждой площадке по АПК Symantec NetBackup Appliance, можно получить полноценный DR-сайт, куда резервные копии с основной площадки попадают при помощи технологии Automatic Image Replication (AIR).
7. Бэкап – это нагрузка на работающую систему.
Во время копирования возможно сильное проседание по производительности основной системы. Поэтому создание резервных копий всегда планируют на период минимальной активности. Однако растет число систем, которые обслуживают запросы круглосуточно. Поэтому для минимизации нагрузки появились продвинутые техники, о которых речь дальше.
В давние времена ночью все пользователи спали, и окно резервного копирования могло длиться, например, с 11 вечера до 7 утра. За это время все данные успевали скопироваться. Когда стало расти число систем, которые обслуживают запросы клиентов и ночью, скорость создания резервных копий стала иметь большее значение. Теперь нужно уложиться в пару-тройку часов, а для систем, работающих 24х7, в минуты. Именно поэтому рынок систем резервного копирования продолжает активно развиваться, изобретая все новые подходы.
8. Данные можно копировать по SAN, а не по LAN.
Большой поток копируемых данных нагружает сеть. Существует техника, которая называется LAN-free backup. Если СХД с данными и библиотеки подключены в SAN (сеть хранения данных), то вполне разумно передавать данные между СХД и библиотекой напрямую по SAN, при этом исключив загрузку локальной сети. Это часто бывает и быстрее, потому что далеко не везде локальная сеть построена на 10G, а обычный 1GB ethernet сильно уступает по пропускной способности даже не самой современной SAN.
9. Приложения можно бэкапить на ходу…
Создать консистентную копию данных, например, СУБД Oracle или MS Exchange без остановки работы невозможно: информация непрерывно меняется, часть ее находится в буферах, в оперативной памяти. У серьезных продуктов промышленного класса, таких как Symantec NetBackup, EMC Networker, CommVault Simpana и др., есть широкий спектр агентов для работы с различными бизнес-приложениями. Эти агенты умеет перевести приложение в режим, когда буфер сбрасывается на диск, а файлы с данными на время перестают меняться.
10. …и минимизировать нагрузку на основную систему.
Чтобы не держать приложение долго в таком режиме работы, эту технику можно скомбинировать с создание снапшотов — мгновенных снимков данных. Снапшот создается быстро, после чего приложение можно «отпустить», а копировать консистентные данные уже со снапшота. Для создания снапшотов применяются в свою очередь свои агенты, которые также могут входить в состав программного обеспечения для резервного копирования.
Если создать не просто снапшот данных, а клон, то его можно отсоединить от исходного диска с данными и передать через SAN на другой хост. И уже на другом хосте программа резервного копирования увидит эти данные и будет передавать их на резервное хранилище. Это техника называется Offhost backup.
11. Виртуальные машины нужно стараться бэкапить средствами гипервизора.
Современные гипервизоры, такие как VMware ESXi, предоставляют инструменты по созданию образов виртуальных машин на лету, без остановки их работы. По сути — те же снапшоты. Такой образ виртуалки бэкапится как файл, а вот топовым функционалом средств резервного копирования является возможность восстанавливать из этого образа гранулярно любой объект, например, единичное письмо электронной почты, если внутри виртуалки работал почтовый сервер. Самыми продвинутыми возможностями тут, по моему мнению, обладают продукты от Symantec.
12. Нужно избавляться от дублей.
Например, каждая виртуалка имеет компоненты операционной системы, которые одинаковы для всех виртуальных машин, на файловых помойках хранится множество копий одного и того же, почтовые рассылки могут дублировать в разных почтовых ящиках одинаковые письма и вложения. Дедупликация позволяет бэкапить только уникальные фрагменты данных и, причем, однократно. Степень дедупликации оказывается часто весьма впечатляющей, цифры достигают 90-98%. Об этом стоит задуматься.
Дедупликация на клиенте. Если поначалу дедупликация выполнялась только на уровне сервера или хранилища (например, DataDomain является аппаратным решением по дедупликации), то сейчас некоторые производители реализовали дедупликацию уже на уровне клиента резервного копирования. Это позволяет не только уменьшить объем хранимой информации, но и объем информации, передаваемой от клиента. В этом случае объем между клиентом и сервером состоит преимущественно из потока контрольных сумм.
Есть много других нюансов, все невозможно покрыть одной статьей. Главная заповедь – уделите бэкапу достаточно внимания, не откладывая на потом. И постарайтесь не доводить до того, чтобы он когда-то понадобился. И еще берегите пальцы )
Вот такую руку мне выдали по страховке взамен порезанной. Пальцы толстоваты, но в целом нормально. Они держат чистящую кассету для ленточной библиотеки.
Автор: adubskiy
