Как составить резервный план

Статьи о бэкапе данных

Пожалуй, нет другой такой темы, которая бы была столь заезжена – о резервном копировании не писал только ленивый. Она с завидной постоянностью поднимается во всех технических обсуждениях, про нее слагают анекдоты. Но, парадокс! Как только дело доходит до восстановления, то выясняются очень неприглядные вещи, начиная от отсутствия резервной копии и заканчивая тем, что копия вроде бы как есть, только вот… А работа стоит, предприятие несет убытки… Поэтому сегодня мы предлагаем вам поговорить о резервном копировании: что это вообще такое и как правильно организовать этот процесс, чтобы потом можно было спать спокойно.

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

Основной причиной написания данной статьи стал пожар в датацентре крупнейшего европейского хостинг-провайдера OVH. В ночь на 10 марта 2021 года огонь полностью уничтожил датацентр SBG2, частично выгорел SBG1, еще два датацентра не пострадали, но были отключены. Список пострадавших крайне широк: это правительственные ресурсы Франции, Великобритании, Польши, крупные европейские медиа-ресурсы, промышленные предприятия, спортивные клубы, разработчики ПО и т.д. и т.п. Последствия тоже различные: так, например, шахматный интернет-сервис Lichess.org отделался “легким испугом”.

В Twitter-аккаунте шахматного сайта Lichess.org сообщается, что в пожаре сгорело несколько серверов Lichess. Впрочем, благодаря усердию сисадмина, который позаботился о резервном копировании, потери данных удалось минимизировать – утрачена история шахматных задач только за последние 24 часа.

А вот некоторым повезло меньше, разработчик игр Rust потерял все свои данные:

“Мы подтверждаем полную потерю серверов из-за пожара в центре обработки данных OVH. Мы изучаем возможность замены оборудования. Восстановление данных невозможно”, – сообщение Rust в Twitter.

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

Резервная копия, архив и синхронизация – в чем разница?

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

Еще раз – резервная копия предназначена только для восстановления данных и ни для чего иного. Очень часто резервную копию путают с архивом, но это принципиально разные сущности. Что такое архив? Это срез данных на определенную дату, который предназначен для хранения и контроля, к вопросу восстановления данных он никакого отношения не имеет. Время от времени мы слышим, что нужно делать копии данных каждый квартал, полугодие, год и хранить их в течении трех – пяти лет. Многие администраторы воспринимают это как создание еще одного набора резервных копий, хотя на самом деле фактически речь идет о создании архива.

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

Еще одна популярная технология, которая используется для создания копии данных – синхронизация. Как правило – это быстро и удобно. Но является ли это резервным копированием? Нет! Почему? Для ответа на этот вопрос подумаем, что может произойти с нашими данными. Они могут быть уничтожены, а могут быть повреждены или искажены, в том числе и неумышленно. В случае с использованием синхронизации в копию попадут искаженные или поврежденные данные и восстановить информацию из нее не будет представляться возможным.

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

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

Как часто и в каком объеме копировать?

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

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

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

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

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

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

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

Если же речь идет о крупной фирме, с большим количеством сотрудников, отделов и филиалов – то даже незначительный простой будет для нее очень болезненным, а потери данных за сутки могут потребовать гораздо большее количество времени на восстановление. Также мы столкнемся с большим объемом данных и высокой скоростью их изменения.

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

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

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

Как часто нужно создавать такую копию? Здесь все зависит от того объема информации, который допустимо потерять с одной стороны и затратами на создание и хранение копий с другой. Допустим, в качестве такого интервала мы выбрали час. Сколько копий нам нужно хранить? Немного. По большому счету нам будет нужна только одна копия – последняя, ну может быть одна из предпоследних, если изменения в данных заметили не сразу. Копия давностью в сутки для целей восстановления фактически бесполезна. Хорошим вариантом будет делать резервную копию каждый час в период рабочего времени и перезаписывать их по кругу.

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

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

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

Это как раз та область, где простота только приветствуется, чем сложнее схема – тем больше ошибок может в ней возникнуть и тем сложнее ее контролировать. Набор простых заданий хорош тем, что даже если сломается одно из них – остальные будут продолжать работать. Ну и не забывайте про ресурсы. Вместо одного общего хранилища выделите под каждый набор данных собственное: отдельные диски, разделы, виртуальные или iSCSI-диски, дисковые лимиты в конце концов.

Что именно копировать?

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

Возьмем следующий пример: у нас есть виртуальная машина с некоторым сервисов внутри, скажем сервером СУБД. Какие варианты резервного копирования нам доступны? Прежде всего копирование самой виртуальной машины. Вариант хороший, многие на этом и останавливаются, забывая о сценариях, когда восстановить виртуалку будет невозможно. Аптайм серверных систем достаточно велик, а многие ошибки проявляют себя только после перезагрузки, таким образом можно получить копии, которые сняты с работоспособной машины, но загрузиться они не смогут. Да, в большинстве случаев ОС можно восстановить, но это дополнительные затраты времени в и без того критической ситуации, одним словом пожар во время наводнения. Да и все может оказаться гораздо проще – нет запасного гипервизора.

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

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

И наконец то, о чем многие забывают. Настройки! Мы многократно были свидетелями возникновения аварийных ситуаций только от того, что администратор пошел вносить изменения в настройки работающего сервиса, не сделав их копии. А теперь представим, что у вас были достаточно сложные персонализированные настройки для СУБД или веб-сервера, без них восстановить работоспособность сервиса в полной мере не удастся, даже при наличии всех остальных данных.

Таким образом правильная организация резервного копирования предполагает наличие копий данных на разных уровнях абстракции: виртуальная машина, дамп сервера БД, каждая БД отдельно и т.д и т.п. А также обязательное копирование настроек, для этих целей неплохо подходят системы контроля версий (git и т.п.), что позволяет не только иметь их копию, но и отслеживать всю историю изменений, с возможностью быстрого отката.

Где и как хранить копии?

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

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

Все должно следовать той же логике анализа угроз и способов им противодействовать. Резервные копии должны не только храниться в надежном месте, но и быть доступны в случае необходимости. Что толку в копии виртуальной машины на удаленном хостинге если копироваться она оттуда будет несколько часов, а восстановить одну из нескольких СУБД нужно здесь и сейчас.

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

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

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

Теперь о форматах. Копию для непосредственного восстановления данных лучше всего хранить в родном формате защищаемого приложения, желательно без сжатия, так как наша цель не экономия хранилища, а максимально быстрое восстановление. Для баз данных это может быть дамп средствами самой СУБД. Но могут быть ситуации, когда рабочего экземпляра СУБД нет, а данные восстановить надо. Это важно для приложений, которые могут использовать различные СУБД и платформы для работы. Скажем вместо аварийного сервера с PostgreSQL на Linux у вас есть работающий MS SQL на Windows. Для этих целей нужно иметь выгрузку данных в универсальный формат для восстановления на любой платформе, это может быть как родной формат приложения, так и некоторый универсальный, скажем XML.

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

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

Почему? Хороший пример – пожар в датацентре OVH, с которого мы начали статью. Также можно вспомнить “споры хозяйствующих субъектов”, которые привели практически к полной остановке работы хостера Айхор с физическим отключением и вывозом серверов. Также следует иметь ввиду техногенные аварии и природные катаклизмы, которые могут привести к проблемам во всем регионе.

Промежуточный итог

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

Например, мы неоднократно сталкивались, что при достаточном объеме системы хранения и выделенных гигабитных каналах дампы БД хранились сжатыми неэффективным 7Zip, который долго сжимает, долго распаковывает и сильно нагружает при этом процессор. При этом частота резервного копирования была явно недостаточной, т.к. архиватор тратил на упаковку около 20 минут, и пользователи жаловались на снижение производительности системы. Налицо неверный выбор архиватора, основанный на степени сжатия, а не на эффективности и скорости работы.

Другой пример: архив 1С: Предприятия хранится в формате дампов СУБД, а не выгрузки самой 1С. В итоге при необходимости развернуть архивную базу локально или на сервере с иной системой управления базами данных администратору сначала потребуется развернуть дамп, подключить базу и сделать из нее выгрузку в формат 1С:Предприятия.

Зеркальная ошибка – хранение резервных копий только в формате выгрузки 1С (DT-файлы), хотя сам разработчик предупреждает, что данный формат не предназначен для резервного копирования, так как ряд ошибок могут не препятствовать выгрузке, только вот загрузить такую копию уже не удастся. Тоже самое можно отнести и копиям виртуальных машин.

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

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

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

Резервные копии нужно проверять

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

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

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

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

А как насчет плана восстановления?

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

Что такое план восстановления? Это детально и максимально подробно описанная процедура восстановления рабочей копии данных из резервной. Своего рода пошаговая инструкция, дословно выполнив которую любой специалист достаточного уровня сможет произвести восстановление данных. При этом внести в нее нужно всё, в том числе и банальные, очевидные на первый взгляд, вещи. Потому что в условиях стресса это может вылететь из головы, а еще, то что “очевидно” для вас, не всегда является очевидным для ваших коллег.

Простой пример: вы внедрили в качестве архиватора современный и эффективный Zstandard и поехали в отпуск, когда вы были не на связи вашему коллеге потребовалось восстановить данные из копии. Допустим, даже ничего серьезного, нужно было вернуть все назад после неудачных технических работ. Но тут его поджидал сюрприз в виде неизвестного ему формата zst. В итоге время было потрачено на то, чтобы выяснить что это такое и как с этим работать, работы вышли за рамки технологического окна, возник простой и руководство выразило недовольство работой IT-службы. Но всего этого можно было бы избежать, если бы это было где-то отражено в документации.

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

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

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

Выводы

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

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

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

Преимущества планового регулярного резервного копирования очевидны, хотя руководители многих компаний все еще сомневаются и не решаются вкладывать в это время и деньги. Раньше владельцы малого бизнеса возможно вполне резонно “шарахались” от стоимости достаточно сложных систем создания резервных копий. План разервного копирования является своего рода страховкой ваших данных (системы и программы обработки которых постоянно совершенствуются), и выплачиваемая вами “страховая премия” обычно несоизмерима с получаемым уровнем защиты. Имея в наличии современное сетевое хранилище данных (устройство NAS) и удобную в использовании профессиональную утилиту резервного копирования (например, R-Drive Image) создание и функционирование надлежащего плана резервного копирования становится достаточно простой и вполне рентабельной задачей. В данной статье это будет показано на примере небольшого корпоративного сервера.

Описанный в этой статье пример демонстрирует возможности R-Drive Image и удобного интерфейса пользователя постороенного по принципу “мастера”. Данный план резервного копирования подходит для небольшой корпоративной информационной системы. После его изучения вы сможете без труда воспользоваться приведенной методологией в ваших конкретных условиях.

Обзор Плана Резервного Копирования

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

Структура дисков копируемого сервера

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

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

В нашем примере мы будет копировать два логических диска на одном физическом: системный диск (C:) и диск с данными (D:).

План резервного копирования

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

План резервного копирования системного диска включает следующее:

• Создавать полный образ первое воскресенье каждого месяца в 14:00.
• Создавать образ в дифференциальном режиме каждое воскресенье в 17:00.
• Резервные копии хранятся в течение трех месяцев.

Данный план позволит произвести “откат” системы на состояние любой недели в течение последних трех месяцев. Например, если критический сбой в работе системы произошел во вторник, то необходимо будет переделать только то что было сделано с момента создания последней резервной копии, т.е. с 17:00 предыдущего воскресенья. Это означает что будут утрачены только около 2 дней работы. Самое большее, что вы можете утратить, это изменения конфигурации системы за последние 7 дней – например, если сбой в работе системы случился в воскресенью до 17:00. Это достаточно приемлемый уровень риска учитывая то что какие-либо изменения системы выполняются не часто.

План резервного копирования диска с данными включает следующее:

• Создавать полный образ первую субботу каждого месяца в 17:00.
• Создавать образ в дифференциальном режиме каждое воскресенье в 17:00.
• Создавать образ в инкрементальном режиме каждый рабочий день в 23:00.
• Резервные копии хранятся в течение трех месяцев.

В соответствии с данным планом состояние данных сохраняется один раз в день, при этом возможно произвести “откат” данных на состояние любого дня в течение последних трех месяцев. Резервная копия создается по субботам а не по воскресеньям и поэтому данное действие не пересекается с копированием системного диска. В этом случае максимум что может быть утрачено это изменения сделанные в течение одного дня – например, если вы сохранили файл во вторник утром и после обеда произошел сбой в работе системы, то можно будет восстановить состояние файлов на вечер понедельника. Если файл был сохранен во вторник вечером до 23:00, а сбой в работе системы произошел на следующее утро, то ничего не будет утрачено.

Режимы Создания Образа: Преимущества и Недостатки

Полный образ	Файл содержащий полный образ всего диска. Преимущества: Для восстановления всего диска необходим только этот единственный файл. Недостатки: Большой размер.
Образ в дифференциальном режиме	Файл содержащий изменения, сделанные на диске от момента создания полного образа до текущего момента. Преимущества: Размер меньше размера полного образа. Недостатки: Размер как правило больше размера инкрементального образа. Для восстановления диска необходим один образ в дифференциальном режиме и полный образ.
Образ в инкрементальном режиме	Файл содержащий изменения, сделанные на диске от момента создания последнего образа (полного, дифференциального или инкрементального) до текущего момента. Преимущества: Меньший размер по сравнению с дифференциальным или полным образом. Недостатки: Для восстановления данных могут потребоваться другие инкрементальные/дифференциальные образы помимо полного образа. Если какой-либо из инкрементальных образов поврежден, то не удастся также восстановить и данные из более поздних инкрементальных копий.

Место хранения резервных копий

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

Рис.1. Рекомендуемая схема сети при резервном копировании небольшого корпоративного сервера
Кликните по изображению для его увеличения

В качестве удаленного сервера не обязательно использовать какое-либо дорогостоящее оборудование. Здесь вполне может подойти экономичное и надежное сетевое хранилище данных (устройство NAS). Его возможно приобрести практически в любом магазине торгующем компьютерами и IT оборудованием.

Обратите внимание, что многие устройства NAS выпускаются с поддержкой внутренних томов RAID. Для хранения резервных копий используйте отказоустойчивые уровни RAID – например, RAID 1, RAID 4, RAID 5 или RAID 6. Не используйте чередующиеся тома (RAID 0) – если один из его дисков выйдет из строя, то все данные будут утрачены.

R-Drive Image совместим с любой серверной платформой поддерживающей сетевой протокол SMB. Среди них Windows, MAC OS и Linux. В большинстве устройствах NAS используются разновидности ОС Linux.

В нашем примере мы будем хранить резервную копию на удаленном сервере в сети (BCK-UBUNTU).

Email уведомления

После завершения создания резервной копии отправляется сообщение электронной почты о результатах операции. Его пример можно посмотреть в разделе Примеры E-mail Уведомления в конце данной статьи.

Копирование Системного Диска

Ежемесячный полный образ системного диска

Первая часть в плане резервного копирования системного диска это ежемесячный полный образ создаваемый в первое воскресенье каждого месяца в 14:00.

1. На этапе Выбор Действия (Action Selection) нажмите Планировщик задач / Создать Скрипт (Scheduler / Create a Script).

Рис. 2. Ежемесячный полный образ системного диска – этап Выбор Действия (Action Selection)
Кликните по изображению для его увеличения

2. На этапе Расписание выполнения Задач (Scheduled Tasks) нажмите кнопку Создать задачу (Create a task).

Рис. 3. Ежемесячный полный образ системного диска – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

3. На этапе Выбор Раздела (Partition Selection) выберите системный раздел резервную копию которого вы будете создавать. В нашем примере системный раздел это C:.

Рис. 4. Ежемесячный полный образ системного диска – этап Выбор Раздела (Partition Selection)
Кликните по изображению для его увеличения

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

4. На этапе Месторасположение Образа (Image Destination) выберите месторасположение файла образа и имя файла.

В нашем примере мы выберем находящийся в сети сервер для резервных копий BCK-UBUNTU и папку Backups. Может потребоваться ввести имя пользователя и пароль для получения доступа к папке сетевого диска.

Рис. 5. Ежемесячный полный образ системного диска – этап Месторасположение Образа (Image Destination)
Кликните по изображению для его увеличения

5. Задайте параметры резервных комплектов на этапе Режим Создания Образа (Imaging Mode) как показано на нижеприведенном рисунке.

Рис. 6. Ежемесячный полный образ системного диска – этап Режим Создания Образа (Imaging Mode)
Кликните по изображению для его увеличения

Введите 3 в поле Максимальное число резервных комплектов (Maximum number of backup sets) и установите радиокнопку Создать новый полный образ (Create a new full image). Более подробную информацию об остальных параметрах можно найти в R-Drive Image online Справке – раздел Резервные Комплекты (Backup Sets).

6. Задайте необходимые параметры на этапе Параметры Образа (Image Options) как показано на нижеприведенном рисунке.

Рис. 7. Ежемесячный полный образ системного диска – этап Параметры Образа (Image Options)
Кликните по изображению для его увеличения

Более подробную информацию об остальных параметрах можно найти в R-Drive Image online Справке – раздел Создание Образа (Create an Image).

7. Задайте необходимые параметры на этапе Параметры Резервного Копирования (Backup Options) как показано на нижеприведенном рисунке.

Рис. 8. Ежемесячный полный образ системного диска – этап Параметры Резервного Копирования (Backup Options)
Кликните по изображению для его увеличения

Более подробную информацию об остальных параметрах можно найти в R-Drive Image online Справке – раздел: Создание Образа (Create an Image).

8. Задайте необходимые параметры на этапе Время/Событие (Time/Event) как показано на нижеприведенном рисунке.

Рис. 9. Ежемесячный полный образ системного диска – этап Время/Событие (Time/Event)
Кликните по изображению для его увеличения

9. Задайте необходимые параметры на этапе Пользователь/Пароль (User/Password).

Рис. 10. Ежемесячный полный образ системного диска – этап Пользователь/Пароль (User/Password)
Кликните по изображению для его увеличения

10. Задайте параметры E-mail уведомления на этапе E-mail Уведомления/Внешние Утилиты (Mail Notification/AUX Applications) как показано на нижеприведенном рисунке.

Рис. 11. Ежемесячный полный образ системного диска – этап E-mail Уведомления/Внешние Утилиты (Mail Notification/AUX Applications)
Кликните по изображению для его увеличения

На этом же этапе можно проверить настройки e-mail нажав кнопку Проверка E-mail… (Test mail account…).
R-Drive Image отправит тестовое e-mail сообщение на указанный в настройках адрес.

11. Подтвердите корректность параметров задачи на этапе Обработка (Processing) и нажмите кнопку Сохранить (Save).

Рис. 12. Ежемесячный полный образ системного диска – этап Обработка (Processing)
Кликните по изображению для его увеличения

Чтобы изменить какой-либо параметр задачи нажмите кнопку Назад (Back) и вернитесь на соответствующий этап.

Если вы нажмете кнопку Сохранить (Save), то созданная задача появится в списке на этапе Расписание выполнения Задач (Scheduled Tasks).

Рис. 13. Ежемесячный полный образ системного диска – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

Еженедельный образ системного диска в дифференциальном режиме

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

1. Нажмите кнопку Создать задачу (Create a task) на этапе Расписание выполнения Задач (Scheduled Tasks), выберите системный раздел на этапе Выбор Раздела (Partition Selection) и выберите на этапе Месторасположение Образа (Image Destination) тот же самый файл образ что и при создании полного образа.

2. Задайте параметры резервных комплектов на этапе Режим Создания Образа (Imaging Mode).

Рис. 14. Еженедельный образ системного диска в дифференциальном режиме – этап Режим Создания Образа (Imaging Mode)
Кликните по изображению для его увеличения

Введите 3 в поле Максимальное число резервных комплектов (Maximum number of backup sets) и установите радиокнопку Добавлять изменения дифференциально к последнему образу в резервном комплекте (Append changes differentially to the last image in the backup set).
Если созданный полный образ диска был защищен паролем, то вам потребуется его ввести.

3. Задайте необходимые параметры на этапах Параметры Образа (Image Options) и Параметры Резервного Копирования (Backup Options) также как и при создании полного образа.

4. Задайте необходимые параметры на этапе Время/Событие (Time/Event).

Рис. 15. Еженедельный образ системного диска в дифференциальном режиме – этап Время/Событие (Time/Event)
Кликните по изображению для его увеличения

Проверьте чтобы Время начала (Start time) не совпадало со временем создания полного образа. В нашем примере ежемесячный полный образ создается в 14:00 и еженедельный образ в дифференциальном режиме в 17:00.

5. Задайте необходимые параметры на этапе Пользователь/Пароль (User/Password).

6. Задайте необходимые параметры на этапе E-mail Уведомления/Внешние Утилиты (Mail Notifications/AUX Applications) также как и при создании полного образа.

Рис. 16. Еженедельный образ системного диска в дифференциальном режиме – этап E-mail Уведомления/Внешние Утилиты (Mail Notifications/AUX Applications)
Кликните по изображению для его увеличения

Измените Тему уведомления: (Custom subject:) на Server1:
differential system disk backup.

7. Подтвердите корректность параметров задачи на этапе Обработка (Processing)
и нажмите кнопку Сохранить (Save).

Рис. 17. Еженедельный образ системного диска в дифференциальном режиме – этап Обработка (Processing)
Кликните по изображению для его увеличения

Созданная задача появится в списке на этапе Расписание выполнения Задач (Scheduled Tasks).

Рис. 18. Еженедельный образ системного диска в дифференциальном режиме – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

Копирование Диска с Данными

Ежемесячный полный образ диска с данными

Данный процесс во многом схож с копированием системного диска за исключением того, что в этом случае создается образ раздела с данными (D:).

1. На этапе Расписание выполнения Задач (Scheduled Tasks) нажмите кнопку Создать задачу (Create a task).

2. Выберите раздел с данными (D:) на этапе Выбор Раздела (Partition Selection).

Рис. 19. Ежемесячный полный образ диска с данными – этап Выбор Раздела (Partition Selection)
Кликните по изображению для его увеличения

3. На этапе Месторасположение Образа (Image Destination) выберите месторасположение файла образа и имя файла.

Рис. 20. Ежемесячный полный образ диска с данными – этап Месторасположение Образа (Image Destination)
Кликните по изображению для его увеличения

4. Задайте параметры резервных комплектов на этапе Режим Создания Образа (Imaging Mode).

Рис. 21. Ежемесячный полный образ диска с данными – этап Режим Создания Образа (Imaging Mode)
Кликните по изображению для его увеличения

Установите 3 в поле Максимальное число резервных комплектов (Maximum number of backup sets) и установите радиокнопку Создать новый полный образ (Create a new full image).

5. Задайте необходимые параметры на этапах Параметры Образа (Image Options) и Параметры Резервного Копирования (Backup Options) также как и при создании полного образа системного диска.

6. Задайте необходимые параметры на этапе Время/Событие (Time/Event).

Рис. 22. Ежемесячный полный образ диска с данными – этап Время/Событие (Time/Event)
Кликните по изображению для его увеличения

7. Задайте необходимые параметры на этапе Пользователь/Пароль (User/Password).

8. Задайте параметры E-mail уведомления на этапе E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications).

Рис. 23. Ежемесячный полный образ диска с данными – этап E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications)
Кликните по изображению для его увеличения

9. Подтвердите корректность параметров задачи на этапе Обработка (Processing) и нажмите кнопку Сохранить (Save).

Рис. 24. Ежемесячный полный образ диска с данными – этап Обработка (Processing)
Кликните по изображению для его увеличения

Созданная задача появится в списке на этапе Расписание выполнения Задач (Scheduled Tasks).

Рис. 25. Ежемесячный полный образ диска с данными – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

Еженедельный образ диска с данными в дифференциальном режиме

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

1. На этапе Расписание выполнения Задач (Scheduled Tasks) нажмите кнопку Создать задачу (Create a task), выберите раздел с данными (т.е. D:) на этапе Выбор Раздела (Partition Selection) и выберите месторасположение файла образа и имя файла (то же файл образ что и при создании полного образа диска с данными) на этапе Месторасположение Образа (Image Destination).

2. Задайте параметры резервных комплектов на этапе Режим Создания Образа (Imaging Mode).

Рис. 26. Еженедельный образ диска с данными в дифференциальном режиме – этап Режим Создания Образа (Imaging Mode)
Кликните по изображению для его увеличения

Введите 3 в поле Максимальное число резервных комплектов (Maximum number of backup sets) и установите радиокнопку Добавлять изменения дифференциально к последнему образу в резервном комплекте (Append changes differentially to the
last image in the backup set).

3. Задайте необходимые параметры на этапах Параметры Образа (Image Options) и Параметры Резервного Копирования также как и при создании полного образа диска с данными.

4. Задайте необходимые параметры на этапе Время/Событие (Time/Event).

Рис. 27. Еженедельный образ диска с данными в дифференциальном режиме – этап Время/Событие (Time/Event)
Кликните по изображению для его увеличения

5. Задайте необходимые параметры на этапе Пользователь/Пароль (User/Password).

6. Задайте параметры E-mail уведомления на этапе E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications).

Рис. 28. Еженедельный образ диска с данными в дифференциальном режиме – этап E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications)
Кликните по изображению для его увеличения

7. Подтвердите корректность параметров задачи на этапе Обработка (Processing) и нажмите кнопку Сохранить (Save).

Рис. 29. Еженедельный образ диска с данными в дифференциальном режиме – этап Обработка (Processing)
Кликните по изображению для его увеличения

Созданная задача появится в списке на этапе Расписание выполнения Задач (Scheduled Tasks).

Рис. 30. Еженедельный образ диска с данными в дифференциальном режиме – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

Ежедневный образ диска с данными в инкрементальном режиме

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

1. Нажмите кнопку Создать задачу (Create a task) на этапе Расписание выполнения Задач (Scheduled Tasks), выберите раздел с данными на этапе Выбор Раздела (Partition Selection) и выберите на этапе Месторасположение Образа (Image Destination) тот же самый файл образ что и при создании полного образа диска с данными.

2. Задайте параметры резервных комплектов на этапе Режим Создания Образа (Imaging Mode).

Рис. 31. Ежедневный образ диска с данными в инкрементальном режиме – этап Режим Создания Образа (Imaging Mode)
Кликните по изображению для его увеличения

Введите 3 в поле Максимальное число резервных комплектов (Maximum number of backup sets) и установите радиокнопку Добавлять изменения инкрементально к последнему образу в резервном комплекта (Append changes incrementally to the
last image in the backup set).

3. Задайте необходимые параметры на этапах Параметры Образа (Image Options) и Параметры Резервного Копирования (Backup Options) также как и при создании полного образа диска с данными.

4. Задайте необходимые параметры на этапе Время/Событие (Time/Event).

Рис. 32. Ежедневный образ диска с данными в инкрементальном режиме – этап Время/Событие (Time/Event)
Кликните по изображению для его увеличения

5. Задайте необходимые параметры на этапе Пользователь/Пароль (User/Password).

6. Задайте параметры E-mail уведомления на этапе E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications)

Рис. 33. Ежедневный образ диска с данными в инкрементальном режиме – этап E-mail Уведомления/Внешние Утилиты (Mail
Notification/AUX Applications)
Кликните по изображению для его увеличения

7. Подтвердите корректность параметров задачи на этапе Обработка (Processing)
и нажмите кнопку Сохранить (Save).

Рис. 34. Ежедневный образ диска с данными в инкрементальном режиме – этап Обработка (Processing)
Кликните по изображению для его увеличения

Созданная задача появится в списке на этапе Расписание выполнения Задач (Scheduled Tasks).

Рис. 35. Ежедневный образ диска с данными в инкрементальном режиме – этап Расписание выполнения Задач (Scheduled Tasks)
Кликните по изображению для его увеличения

Структура Файлов Плана Резервного Копирования

Теперь план резервного копирования готов. Вы начнете получать уведомления о завершении операций резервного копирования. Описание уведомления (примеры) вы найдете далее в этой статье.

Созданные R-Drive Image файлы образы будут иметь следующие имена:

• Полный образ: <имя_файла>_<дата_первого_образа>_<время_первого_образа>_1.rdr
• Образы в инкрементальных и дифференциальных режимах: <имя_файла>_<дата_первого_образа>_<время_первого_образа>_N+1.rdr

где N это число ранее созданных инкрементальных или дифференциальных образов.

В описанном выше примере R-Drive Image создаст следующие файлы:

Образ системного диска

Дата/День недели/Время	Файлы Новые создаваемые файлы выделены жирным	Тип образа	Номер Резервного Комплекта
Начало Резервного Комплекта 1
2013-09-01 /Воскресенье / 14:00 2013-09-01 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr	Полный образ Дифф. образ	Резервный Комплект 1
2013-09-08 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr	Полный образ Дифф. образ Дифф. образ
2013-09-15 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ
2013-09-22 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr SystemDisk_20130901_020000PM_5.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ
2013-09-29 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr SystemDisk_20130901_020000PM_5.rdr SystemDisk_20130901_020000PM_6.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ
Начало Резервного Комплекта 2
2013-10-06 /Воскресенье / 14:00 2013-10-06 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr SystemDisk_20130901_020000PM_5.rdr SystemDisk_20130901_020000PM_6.rdr SystemDisk_20131006_020000PM_1.rdr SystemDisk_20131006_020000PM_2.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ	Резервные Комплекты 1,2
2013-10-13 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr SystemDisk_20130901_020000PM_5.rdr SystemDisk_20130901_020000PM_6.rdr SystemDisk_20131006_020000PM_1.rdr SystemDisk_20131006_020000PM_2.rdr SystemDisk_20131006_020000PM_3.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ
2013-10-20 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr SystemDisk_20130901_020000PM_5.rdr SystemDisk_20130901_020000PM_6.rdr SystemDisk_20131006_020000PM_1.rdr SystemDisk_20131006_020000PM_2.rdr SystemDisk_20131006_020000PM_3.rdr SystemDisk_20131006_020000PM_4.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ Дифф. образ
2013-10-27 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr SystemDisk_20130901_020000PM_5.rdr SystemDisk_20130901_020000PM_6.rdr SystemDisk_20131006_020000PM_1.rdr SystemDisk_20131006_020000PM_2.rdr SystemDisk_20131006_020000PM_3.rdr SystemDisk_20131006_020000PM_4.rdr SystemDisk_20131006_020000PM_5.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ
Начало Резервного Комплекта 3
2013-11-03 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr SystemDisk_20130901_020000PM_5.rdr SystemDisk_20130901_020000PM_6.rdr SystemDisk_20131006_020000PM_1.rdr SystemDisk_20131006_020000PM_2.rdr SystemDisk_20131006_020000PM_3.rdr SystemDisk_20131006_020000PM_4.rdr SystemDisk_20131006_020000PM_5.rdr SystemDisk_20131103_020000PM_1.rdr SystemDisk_20131103_020000PM_2.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ	Резервные Комплекты 1,2,3
2013-11-10 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr SystemDisk_20130901_020000PM_5.rdr SystemDisk_20130901_020000PM_6.rdr SystemDisk_20131006_020000PM_1.rdr SystemDisk_20131006_020000PM_2.rdr SystemDisk_20131006_020000PM_3.rdr SystemDisk_20131006_020000PM_4.rdr SystemDisk_20131006_020000PM_5.rdr SystemDisk_20131103_020000PM_1.rdr SystemDisk_20131103_020000PM_2.rdr SystemDisk_20131103_020000PM_3.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ
2013-11-17 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr SystemDisk_20130901_020000PM_5.rdr SystemDisk_20130901_020000PM_6.rdr SystemDisk_20131006_020000PM_1.rdr SystemDisk_20131006_020000PM_2.rdr SystemDisk_20131006_020000PM_3.rdr SystemDisk_20131006_020000PM_4.rdr SystemDisk_20131006_020000PM_5.rdr SystemDisk_20131103_020000PM_1.rdr SystemDisk_20131103_020000PM_2.rdr SystemDisk_20131103_020000PM_3.rdr SystemDisk_20131103_020000PM_4.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ Дифф. образ
2013-11-24 /Воскресенье / 17:00	SystemDisk_20130901_020000PM_1.rdr SystemDisk_20130901_020000PM_2.rdr SystemDisk_20130901_020000PM_3.rdr SystemDisk_20130901_020000PM_4.rdr SystemDisk_20130901_020000PM_5.rdr SystemDisk_20130901_020000PM_6.rdr SystemDisk_20131006_020000PM_1.rdr SystemDisk_20131006_020000PM_2.rdr SystemDisk_20131006_020000PM_3.rdr SystemDisk_20131006_020000PM_4.rdr SystemDisk_20131006_020000PM_5.rdr SystemDisk_20131103_020000PM_1.rdr SystemDisk_20131103_020000PM_2.rdr SystemDisk_20131103_020000PM_3.rdr SystemDisk_20131103_020000PM_4.rdr SystemDisk_20131103_020000PM_5.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ
Начало Резервного Комплекта 4. Резервный Комплект 1 удален.
2013-12-01 /Воскресенье / 17:00	SystemDisk_20131006_020000PM_1.rdr SystemDisk_20131006_020000PM_2.rdr SystemDisk_20131006_020000PM_3.rdr SystemDisk_20131006_020000PM_4.rdr SystemDisk_20131006_020000PM_5.rdr SystemDisk_20131103_020000PM_1.rdr SystemDisk_20131103_020000PM_2.rdr SystemDisk_20131103_020000PM_3.rdr SystemDisk_20131103_020000PM_4.rdr SystemDisk_20131103_020000PM_5.rdr SystemDisk_20131201_020000PM_1.rdr SystemDisk_20131201_020000PM_2.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ	Резервные Комплекты 2,3,4
2013-12-08 /Воскресенье / 17:00	SystemDisk_20131006_020000PM_1.rdr SystemDisk_20131006_020000PM_2.rdr SystemDisk_20131006_020000PM_3.rdr SystemDisk_20131006_020000PM_4.rdr SystemDisk_20131006_020000PM_5.rdr SystemDisk_20131103_020000PM_1.rdr SystemDisk_20131103_020000PM_2.rdr SystemDisk_20131103_020000PM_3.rdr SystemDisk_20131103_020000PM_4.rdr SystemDisk_20131103_020000PM_5.rdr SystemDisk_20131201_020000PM_1.rdr SystemDisk_20131201_020000PM_2.rdr SystemDisk_20131201_020000PM_3.rdr	Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ Дифф. образ Дифф. образ Полный образ Дифф. образ Дифф. образ

Образ диска с данными

Ниже приведен пример структуры файлов одного из резервных комплектов. Показано начало Резервного Комплекта 2.

Дата/День недели/Время	Файл	Тип образа
2013-08-31 /Суббота /5:00 2013-08-31 /Суббота /15:00	DataDisk_20130831_050000AM_1.rdr DataDisk_20130831_050000PM_2.rdr	Полный Дифф.
2013-09-02 /Понедельник /23:00	DataDisk_20130831_050000AM_3.rdr	Инкр.
2013-09-03 /Вторник /23:00	DataDisk_20130831_050000AM_4.rdr	Инкр.
2013-09-04 /Среда /23:00	DataDisk_20130831_050000AM_5.rdr	Инкр.
2013-09-05 /Четверг /23:00	DataDisk_20130831_050000AM_6.rdr	Инкр.
2013-09-06 /Пятница /23:00	DataDisk_20130831_050000AM_7.rdr	Инкр.
2013-09-07 /Суббота /3:00PM	DataDisk_20130831_050000AM_8.rdr	Дифф.
2013-09-09 /Понедельник /23:00	DataDisk_20130831_050000AM_9.rdr	Инкр.
2013-09-10 /Вторник / 23:00	DataDisk_20130831_050000AM_10.rdr	Инкр.
2013-09-11 /Среда /23:00	DataDisk_20130831_050000AM_11.rdr	Инкр.
2013-09-12 /Четверг /23:00	DataDisk_20130831_050000AM_12.rdr	Инкр.
2013-09-13 /Пятница /23:00	DataDisk_20130831_050000AM_13.rdr	Инкр.
2013-09-14 /Суббота /15:00	DataDisk_20130831_050000AM_14.rdr	Дифф.
2013-09-16 /Понедельник /23:00	DataDisk_20130831_050000AM_15.rdr	Инкр.
2013-09-17 /Вторник /23:00	DataDisk_20130831_050000AM_16.rdr	Инкр.
2013-09-18 /Среда /23:00	DataDisk_20130831_050000AM_17.rdr	Инкр.
2013-09-19 /Четверг /23:00	DataDisk_20130831_050000AM_18.rdr	Инкр.
2013-09-20 /Пятница /23:00	DataDisk_20130831_050000AM_19.rdr	Инкр.
2013-09-21 /Суббота /15:00	DataDisk_20130831_050000AM_20.rdr	Дифф.
2013-09-23 /Понедельник /23:00	DataDisk_20130831_050000AM_21.rdr	Инкр.
2013-09-24 /Вторник /23:00	DataDisk_20130831_050000AM_22.rdr	Инкр.
2013-09-25 /Среда /23:00	DataDisk_20130831_050000AM_23.rdr	Инкр.
2013-09-26 /Четверг /23:00	DataDisk_20130831_050000AM_24.rdr	Инкр.
2013-09-27 /Пятница /23:00	DataDisk_20130831_050000AM_25.rdr	Инкр.
2013-09-28 /Суббота /15:00	DataDisk_20130831_050000AM_26.rdr	Дифф.
2013-09-30 /Понедельник /23:00	DataDisk_20130831_050000AM_27.rdr	Инкр.
2013-10-01 /Вторник /23:00	DataDisk_20130831_050000AM_28.rdr	Инкр.
2013-10-02 /Среда /23:00	DataDisk_20130831_050000AM_29.rdr	Инкр.
2013-10-03 /Четверг /23:00	DataDisk_20130831_050000AM_30.rdr	Инкр.
2013-10-04 /Пятница /23:00	DataDisk_20130831_050000AM_31.rdr	Инкр.
Начало Резервного Комплекта 2
2013-10-05 /Суббота /5:00 2013-10-05 /Суббота /15:00	DataDisk_20131005_050000AM_1.rdr DataDisk_20131005_050000AM_2.rdr	Полный Дифф.

Вы можете удалять ежедневные инкрементальные образы созданные в период времени между созданием полных и дифференциальных образов не теряя при этом целестности данных. Например, после создания файла DataDisk_20130831_050000AM_8.rdr можно удалить файлы начиная с DataDisk_20130831_050000AM_3.rdr и заканчивая DataDisk_20130831_050000AM_7.rdr.

Протоколирование

Можно сохранить файл журнала операций R-Drive Image. Для этого нажмите кнопку О программе (About) на этапе Выбор Действия (Action Selection), установите флажок Протоколирование (Logging) и задайте имя и путь к файлу.

Рис. 36. R-Drive Image: Протоколирование
Кликните по изображению для его увеличения

Примеры E-mail Уведомления

После завершения операции резервного копирования R-Drive Image будет отправлять E-mail уведомление.

При Успешном завершении операции уведомление будет иметь следующий вид:

Если операция завершилась неудачно, то уведомление будет выглядеть так:

Заключение

Создать план резервного копирования при помощи R-Drive Image можно достаточно быстро, эффективно и экономично. Имея R-Drive Image, устройство NAS и план резервного копирования можно оградить себя ото всех неудобств и значительных финансовых затрат имеющих место при утрате данных. В данном статье было показано насколько просто можно создать план резервного копирования. Для получения более подробной информации обо всех имеющихся параметрах резервного копирования и составления своего плана обратитесь к R-Drive Image online справке.

В 2014 году компании зафиксировали больше утечек данных, чем «Игра престолов» – трагических смертей. Только в прошлом году Target, Home Depot и Sony сильно пострадали от той или иной целенаправленной атаки, и, судя по утечкам больших данных
в этом году,
ситуация станет еще хуже, прежде чем станет лучше. Восстановление после утечки данных требует бесчисленных часов внутренних усилий по восстановлению данных
и может поставить под угрозу деньги и репутацию компании в глазах клиентов.

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

Не могли бы вы объяснить клиенту, что ваш единственный файл для его проекта поврежден? Настоящее обслуживание клиентов означает защиту важной информации ваших клиентов. На самом деле, когда дело доходит до данных, угрозы безопасности – это лишь верхушка айсберга. Если в вашей компании случится бедствие, вы захотите иметь надежный запасной план, который быстро поможет вам встать на ноги. Мы собрали для вас несколько советов:

1. Составьте план резервного копирования

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

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

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

• Насколько важна эта информация? Может ли мой бизнес жить без этого?
  • Определите, какая информация важна для выживания вашего бизнеса. Базы данных, конфиденциальная информация и файлы, которые используются изо дня в день, должны быть приоритетными и защищенными, поскольку от них зависит ваш бизнес.
• Как часто следует выполнять резервное копирование и в какое время планировать их?
  • Частота обновления файлов должна определять, как часто выполняется их резервное копирование. Элементы, которые обновляются ежедневно, должны, естественно, копироваться ежедневно, в то время как элементы, которые обновляются только ежегодно, нуждаются в резервном копировании реже.
• Как быстро мне нужно будет восстановить данные в случае возникновения чрезвычайной ситуации?
  • Снова добиться минимума переезда вашей компании? Корректировка плана резервного копирования в соответствии с этими потребностями может спасти вашу компанию от потери времени, денег и репутации.

Реализуйте свой план резервного копирования

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

Один действительно простой метод, которого придерживаются многие ИТ-профессионалы, – это план 3-2-1
при резервном копировании важных файлов:

3 копии ваших файлов

в 2-х разных форматах

с как минимум 1 копией зарезервированной за пределами сайта

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

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

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

Поддерживайте актуальность резервных копий

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

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

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

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

Изображения Эбби Калер