что значит резервное копирование данных
Как сделать бэкап и для чего он нужен
реклама
Среди айтишников ходит присказка-поговорка: «есть два типа людей – кто еще не делает бэкапы, и кто уже делает». И действительно, один раз потеряв ценную для себя информацию, и с трудом и большими денежными затратами восстановив ее, или вообще не сумев восстановить, вряд ли какой-то здравомыслящий человек захочет столкнуться с подобной ситуацией еще раз. В этой статье я расскажу о бэкапах (резервных копиях) данных – что это такое, зачем они нужны, как и где их делать.
Материал ориентирован не на системных администраторов и не на работников коммерческих фирм, а на пользователей домашних ПК и геймеров, поэтому информация будет подаваться в наиболее доступной форме, а многие профессиональные нюансы не будут затронуты. В этот раз я не стану рассказывать о полностью автоматизированных бэкапах и тому подобных вещах – эта статья о ручном создании резервных копий особо ценных данных и их последующем беспроблемном восстановлении.
Что такое бэкап простыми словами?
Бэкап – это резервная копия каких-либо данных. Например, в вашем компьютере установлены 3 накопителя: SSD и два жестких диска – HDD 1 и HDD 2. На HDD 1 вы храните ценные для вас семейные фотографии, и вдруг он выходит из строя, унося с собой всю имеющуюся на нем информацию. Вы пробуете программы для восстановления данных с поврежденных «винчестеров», но ничего не помогает. Остается только одно – идти в специализированный сервис и отдавать кругленькую сумму. И то не факт, что помогут. А вот если бы эти фотографии были не в единственном экземпляре и хранились где-нибудь еще…
Как сделать бэкап?
реклама
Сделать резервную копию каких-либо файлов очень просто: их нужно скопировать на другой физический накопитель. Подчеркну: именно на другой физический накопитель, а не на другой «локальный диск». Физический накопитель (SSD или жесткий диск) может состоять из нескольких разделов. Простой пример из жизни: физический накопитель – это ящик для столовых приборов, а локальные диски – это разные отсеки; один для ножей, один для вилок, один для ложек и так далее. То есть, если у вас HDD 1 разбит на разделы D и E, а HDD 2 на разделы F и G, то недостаточно скопировать фотографии из раздела D в раздел E – необходимо «забэкапить» их в раздел F или G. Но находясь даже в нескольких экземплярах на одном компьютере или в одной квартире, данные все равно могут потеряться – например, в случае чрезвычайных обстоятельств вроде пожара. Вот простые правила, которые помогут этого избежать.
Главные правила резервного копирования
Правило первое: для действительно важных данных должно существовать как минимум три бэкапа, физически находящихся в разных местах, причем парочка из них – на удаленных серверах. В случае пожара, затопления и других форс-мажорных обстоятельств вы легко можете лишиться всех электронных устройств, находящихся в одной квартире, поэтому бэкапов «по месту жительства» недостаточно. Но почему я предлагаю именно два удаленных сервера? Да потому что, если такой сервер один, с ним тоже может случиться форс-мажор (сгорел дата-центр, закрылась компания, случайно стерли данные), а вы об этом узнаете только если потеряете «оригинальные» данные и их копию по месту жительства.
реклама
Если вы используете для бэкапов бесплатные хранилища, хостинги и файлообменники – будьте готовы, что они в любой момент могут решить стереть ваши данные, и сделайте еще пару удаленных резервных копий. Да, муторно, но лучше так, чем потерять данные. И обязательно защитите свою информацию при помощи шифрования, не заливайте ее в открытом виде. О том, как это сделать, я расскажу в соответствующем разделе.
Правило второе: проверяйте бэкапы. Если бэкап не проверен, то можно считать, что его и нет. Браузер или программа закачки может показать, что все загрузилось успешно, а при попытке скачать, расшифровать или разархивировать – бац, ошибка. После создания бэкапов проведите пару тестовых восстановлений данных из разных источников.
Правило третье: если речь идет о домашнем ПК, делайте резервные копии только действительно важных данных. Нет никакой надобности бэкапить любимые игры или сериалы – если полетит SSD/жесткий диск, их всегда можно скачать заново. А вот уникальные и имеющиеся только у вас данные, такие, как сохраненки для игр, уже вполне можно бэкапить, если вы заядлый геймер. Но чаще всего в случае домашних бэкапов сохраняются копии личных/семейных фотографий и видео, а также заметок.
реклама
Выбор этих важных данных должен быть индивидуальным. Ценные для вас фото, скриншоты заметки, и тому подобное стоит бэкапить всегда (только не забывайте все это шифровать!), а дальше – как говорится, кто на что горазд. Если вы просидели много сотен часов в Скайриме, то стоит сделать резервную копию нескольких сохранений с разных этапов игры, если вы играете в покер на деньги – бэкапьте базу данных с информацией на оппонентов, если храните криптовалюту – бэкапьте кошельки или данные для доступа к ним.
Если говорить о бэкапах для коммерческих фирм, дата центров и т.д., существуют и некоторые другие правила – например, о том, что создание резервных копий должно быть автоматическим и не должно мешать повседневной работе и интересам клиентов, или о том, что необходимо минимизировать дублирование файлов ради экономии места, но подробно на них я останавливаться не буду – все это мало касается резервного копирования «домашней» информации.
Как защитить резервную копию данных на удаленном сервере при помощи шифрования?
Любые чувствительные данные вроде бэкапов личных заметок, фото и криптокошельков, следует защищать при помощи шифрования. Рекомендую использовать VeraCrypt – программу с открытым исходным кодом, которая в свое время стартовала как форк TrueCrypt. В настоящий момент она считается одним из самых надежных бесплатных решений для шифрования и используется журналистами, активистами и лицами, работающими с чувствительной информацией, по всему миру.
Выберите «Тома» – «Создать новый том», далее – «Создать зашифрованный файловый контейнер» – «Обычный том». Подойдет AES с алгоритмом хеширования SHA-512. После этого укажите максимальный размер тома – он должен быть таким, чтобы туда влезли все ваши файлы, резервную копию которых вы хотите создать. Введите подходящий пароль и подтвердите, что собираетесь хранить в контейнере файлы размером более 4 ГБ. Дальше следуйте указаниям программы. Жмите «разметить», а по окончанию шифрования монтируйте созданный контейнер и переносите туда нужные файлы, после чего размонтируйте.
Все, файлы зашифрованы, можно заливать том в облако/на удаленное хранилище! Если хотите, можете перед этим еще и заархивировать контейнер с паролем, чтобы уменьшить его размер, но это необязательно. Главное, не забудьте разархивировать/размонтировать бэкап и проверить его работоспособность перед тем, как начать загрузку, после же загрузки скачайте его и повторите процедуру. Это может занять немало времени, но, поскольку резервные копии домашних данных создаются нечасто – ничего страшного.
Заключение
Не ленитесь и не откладывайте создание бэкапа на потом, не думайте, что уж с вами потеря данных точно не случится – если у вас нет резервной копии какой-либо ценной информации, как можно скорее сделайте ее.
Резервное копирование данных простым языком
Основные принципы
1. Регулярность и частота
Backup данных должен быть таким же регулярным, как прием таблеток. Именно за эту дисциплинированность себя можно будет благодарить, если вдруг произошел какой-то крах. Порой потерять даже всего несколько рабочих дней из-за того, что backup не сделан, — может быть очень болезненным. Ответить на вопрос — как часто делать бэкап возможно, поняв, данные за какой промежуток времени тебе было бы наименее болезненно терять. Один из оптимальных вариантов — backup данных раз в неделю по выходным.
Раздельность
Желательно, чтобы данные сохранялись на отдельный внешний жесткий диск (или другой носитель), хранились в отдельном месте от основных данных. Принцип вполне очевиден — если произошла проблема, она будет локализована в одном месте. Например, если сломался жесткий диск на компьютере, диск с резервной копией будет функционировать отлично. Тем не менее, здесь стоит соблюдать баланс между легкостью доступа и безопасностью. Жесткий диск, стоящий рядом с компьютером, существенно повышает мотивацию использовать его по назначению. И в то же время, это не самый безопасный вариант для очень важных данных, которые терять нельзя ни в каком случае. Именно поэтому различают резервное копирование и архивацию данных.
Перепроверка
Как только сделана первая резервная копия данных, необходимо сразу проверить, что из нее эти данные можно восстановить! Это означает не только то, что файлы становятся видны. Нужно открыть несколько файлов на выбор и проверить, что они не испорчены. Желательно такую проверку потом повторять раз в какой-то период (скажем, раз в год).
Различение
Лучшая практика — различать данные по категориям. Категорией может быть их важности для тебя, частота обновления, или просто тематика.
Зачастую программы резервного копирования делают так называемые «образы» (image). Они выглядят как один единственный файл. Так вот в каждый такой образ лучше сохранять различные данные.
Для чего это нужно. Данные разной важности требуют разного обращения с собой, это очевидно. Свои важные документы, наверняка, захочется хранить более бережно, чем, скажем, коллекцию фильмов. Разделив данные по частоте обновления можно, к примеру, сэкономить время занимаемое резервным копированием. Тематика — какие данные желательно вместе восстанавливать за один шаг? Яркий пример двух типов backup, которые следует делать раздельно:
Резервное копирование данных
Это документы Word, фотографии, фильмы и т.д. Так же к этому относятся, но часто забываются — закладки в браузере, письма в почтовом ящике, адресная книга, календарь со встречами, конфигурационный файл банковского приложения и т.д.
Резервное копирование системы
Речь идет об операционной системе со всеми ее настройками. Такой backup избавляет от необходимости устанавливать операционную систему заново, делать все настройки, устанавливать программы. Однако, это не самый из необходимых типов резервного копирование.
Куда делать backup
1. Внешний жесткий диск. Часто можно купить прямо в коробке. Бывают ноутбучные — такие диски маленькие по размеру, но более дорогие. Обычные жесткие диски можно сравнительно дешево купить объемом в 2 Тб — тогда за место на диске долго не придётся беспокоиться.
+ Достаточно надежный (если не ронять и не трясти чрезмерно)
+ Относительно недорогой
-Необходимо самому не забывать подключать диск для бэкапа
-Не очень удобно переносить (не относится к ноутбучным дискам)
2. USB-stick — подойдет как дополнительное средство, когда данные хотелось бы переносить с одного компьютера на другой и/или иметь под рукой. Так же если сами данные не хочется хранить на компьютере.
Есть одно большое но — у флешки ограничено число записей, так что если на ней хранить данные приложения, которое будет интенсивно записывать, то флешка (usb stick) довольно быстро прикажет долго жить. К тому же, по моему личному впечатлению, они достаточно часто ломаются. Мой знакомый, покупая самые дорогие флешки, которые позиционировались как «не убиваемые», получал сломанную флешку за месяц-другой. Справедливости ради, надо сказать что у меня до сих пор ни одна флешка не сломалась, некоторые работают уже лет 5. Тем не менее, только на одном только usb-stick`e я бы хранить данные не стала.
+Мобильное хранение
+Занимает мало места
+Очень дешево
3. Хранение данных на удаленном сервере ( или в облаке).
Есть свои плюсы и минусы:
+Данные будут доступны не только дома, но и на работе, во время путешествий.
+Локационная раздельность основных данных и резервных копий (например, если случается, не дай бог, пожар данные выживают)
+Нет нужды подключать жесткий диск для бэкапа, как правило, все делается полностью автоматически.
-Желательно шифровать данные, так как неизвестно кто к ним может получить доступ
-Тратится большой объем трафика (если он ограничен, то возникают проблемы)
-Зачастую бесплатно можно хранить только данные до 2 Гб. Так что, такой backup — это дополнительная статья расходов
Список с хорошим описанием сервисов можно найти тут
Чем делать backup
Приведу список приложений, на которые стоит обратить внимание (по моему мнению), при резервном копировании на жесткий диск.
Из бесплатных пользуются популярностью
1. Genie Backup Manager — очень удобная программа, но немного тормозит при работе
2. Handy Backup — простой интерфейс, работает быстро.
Дополнительно
Часто в настройках программ по backup есть опция — сделать инкрементальный или дифференциальный backup. Практическое различие довольно простое. При дифференциальном резервном копировании можно сэкономить на месте которое он занимает. Зато есть только две возможности восстановления: данные в том состоянии, когда был сделан полный backup + данные на тот момент, когда был сделан дифференциальный.
Инкрементальный backup же позволяет откатиться на любой из моментов в прошлом, когда делалось резервное копирование. Однако, особенно если изменения в данных происходили часто, место будет съедаться быстро.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Как правильно организовать резервное копирование и спать спокойно
Основной причиной написания данной статьи стал пожар в датацентре крупнейшего европейского хостинг-провайдера OVH. В ночь на 10 марта 2021 года огонь полностью уничтожил датацентр SBG2, частично выгорел SBG1, еще два датацентра не пострадали, но были отключены. Список пострадавших крайне широк: это правительственные ресурсы Франции, Великобритании, Польши, крупные европейские медиа-ресурсы, промышленные предприятия, спортивные клубы, разработчики ПО и т.д. и т.п. Последствия тоже различные: так, например, шахматный интернет-сервис Lichess.org отделался «легким испугом».
А вот некоторым повезло меньше, разработчик игр Rust потерял все свои данные:
Но это крупная авария, которая у всех на слуху, а сколько инцидентов с потерей данных происходит ежедневно за закрытыми дверями различных организаций? Причем одного такого случая бывает достаточно, чтобы лишиться рабочего места или поставить крест на карьере, независимо от предыдущих заслуг. Поэтому давайте уделим вопросу резервного копирования самое пристальное внимание, а начнем с самого начала.
Значит ли это, что не синхронизацию использовать не следует? Отнюдь, просто нужно понимать, что это не способ резервного копирования, а один из методов повышения отказоустойчивости, как RAID. В случае аппаратного отказа основного узла у нас на руках будет практически на 100% идентичная копия, которая позволит быстро восстановить работу сервиса. Но от ошибочных действий с данными или атаки вируса-шифровальщика синхронизация нас не спасет.
Как часто и в каком объеме копировать?
На первый взгляд тут все просто: копируем всё, как можно чаще и храним как можно дольше. Вроде бы все хорошо? На самом деле не очень. Хотя именно этот подход очень часто используется во многих организациях. А что? Копии есть, копий много, можно спать спокойно. Такие требования могут даже встречаться в договорах и должностных инструкциях. Например, в проект одного из договоров заказчик попытался включить следующее:
Резервное копирование баз данных исполнитель производит не реже одного раза в день. Резервные копии хранятся не менее трех лет.
При этом со стороны заказчика так никто и не смог пояснить, зачем им резервные копии трехлетней давности, просто где-то нашли подобную формулировку, и она показалась им подходящей. Все это приводит к тому, что резервное копирование производится только ради резервного копирования, не учитывая реальных угроз и потребностей предприятия.
В данной ситуации следует отталкиваться от следующего тезиса: стоимость резервного копирования не должна превышать возможный ущерб от потери данных.
Под стоимостью здесь подразумеваются как одноразовые, так и текущие затраты на систему создания и хранения резервные копий. Непонимание этого момента приводит к появлению противоречий между техническим персоналом и владельцами бизнеса, в результате которых последний может остаться без резервного копирования вообще. Если фирма использует базу данных только для вставления счетов и оформления отгрузочных документов, то ее потеря будет, конечно, досадным недоразумением, но не более. Подойдет копия практически любой давности, а остальное можно будет внести заново руками.
Но это не значит, что такие фирмы следует оставлять без резервного копирования, просто его объем и частота должны быть адекватны характеру бизнеса и реальным угрозам. Вполне достаточно будет делать копию в облако допустим раз в сутки. Так как объем изменения данных небольшой, то мы можем позволить себе откат даже на несколько дней назад, скажем, если возникла ошибка по вине человека, и она не была замечена сразу, потому как внести самим документы за несколько дней для организации может оказаться дешевле, чем услуги специалиста по исправлению ошибок в учете. Поэтому мы можем смело хранить неделю, вряд ли больше. В данном случае глубину может дополнительно ограничивать бесплатный тариф облачного хранилища.
Данный пример, может показаться кому-то крайностью, но мы специально привели его для того, чтобы показать, что адекватный угрозам процесс резервного копирования можно организовать и при практически полном отсутствии бюджетов.
Поэтому первоначально нужно составить список угроз и только потом выбирать наиболее эффективный механизм для противодействия им. Начнем с наиболее очевидных: потеря рабочей копии данных по каким-либо причинам. При этом под потерей мы подразумеваем не только физическую утрату копии данных, но и необратимое логическое изменение структуры, которое невозможно устранить в короткие сроки (удаление, изменение реквизитов документов и т.д. и т.п.). В этом случае нам нужно как можно скорее восстановить рабочую копию с минимальной потерей информации.
От физической потери копии без изменения структуры данных (отказ носителя, выход из строя сервера) нас может подстраховать синхронизация, в этом случае у нас будет запасной экземпляра рабочей копии, на который мы можем переключиться немедленно. Но он не спасет нас в случае логического повреждения рабочего набора данных. Для этого нам нужна резервная копия. Она должна быть полной и позволять быстро восстановить работоспособность рабочей копии.
Скажем в мае бухгалтер говорит нам, что поплыли данные за февраль. ОК, разворачиваем архив за первый квартал и анализируем изменения. Однако одного архива может оказаться недостаточно, бывают ситуации, когда данные были изменены в течении более короткого промежутка времени: нескольких дней, недели. Для этого нам потребуется еще один контур резервного копирования, цель которого не быстрое восстановление рабочей копии, а получение ее рабочего экземпляра на предыдущую дату для целей анализа и выборочного восстановления. В этом случае мы можем делать копии каждый день в течении недели, каждое воскресенье за неделю и каждый последний день месяца за месяц.
При этом следует понимать, что это две разных задачи по резервному копированию и они должны выполняться полностью самостоятельно и у каждой из них должны быть свои выделенные ресурсы. Например, чтобы закончившееся место на разделе с ежедневными копиями не могло повлиять на возможность создавать оперативные копии каждый час. Или ошибка в скрипте не оставила вас вообще без резервных копий.
Что именно копировать?
Что именно копировать?На первый взгляд вопрос глупый. Как что? Данные. Но это очень размытое понятие, так как данными является практически все, что хранится на ваших дисках, но разные данные имеют различную критичность, которая может меняться от ситуации к ситуации. Неверное понимание этого вопроса также может привести к ситуации, когда бекапы есть, но воспользоваться ими вы не можете, либо это займет продолжительное время (в ряде случаев это равносильно тому, что бекапов нет). Как так может произойти? Давайте разбираться.
В этом случае нам нужно иметь копию данных из виртуальной машины, в случае с СУБД это может быть полный дамп сервера. После чего нам достаточно поднять экземпляр нужной СУБД и загрузить данные в нее. При этом риски что-то забыть или потерять минимальны, что важно если на вашем сервере большое количество баз, с разными владельцами и разными правами доступа.
Но бывают и иные ситуации, когда нам нужно восстановить одну единственную базу, либо нет возможности поднять новый экземпляр СУБД, но есть уже существующий, в который вполне можно загрузить нужные базы. Для этого нужно иметь дампы баз данных по отдельности. Да, их можно выгрузить располагая полным дампом или образом ВМ, но это снова дополнительное время и необходимость в дополнительных ресурсах.
И наконец то, о чем многие забывают. Настройки! Мы многократно были свидетелями возникновения аварийных ситуаций только от того, что администратор пошел вносить изменения в настройки работающего сервиса, не сделав их копии. А теперь представим, что у вас были достаточно сложные персонализированные настройки для СУБД или веб-сервера, без них восстановить работоспособность сервиса в полной мере не удастся, даже при наличии всех остальных данных.
Таким образом правильная организация резервного копирования предполагает наличие копий данных на разных уровнях абстракции: виртуальная машина, дамп сервера БД, каждая БД отдельно и т.д и т.п. А также обязательное копирование настроек, для этих целей неплохо подходят системы контроля версий (git и т.п.), что позволяет не только иметь их копию, но и отслеживать всю историю изменений, с возможностью быстрого отката.
Где и как хранить копии?
Когда мы говорим об организации хранения копий, то чаще всего вспоминается правило 3-2-1, которое гласит, что нужно хранить три резервные копии, в двух разных физических форматах хранения, одну из них за пределами офиса (существуют разные формулировки этого правила, но общий смысл от этого не меняется). Любое хорошее правило возникает не на пустом месте, а воплощает в себе пользовательский опыт, зачастую негативный. И если говорят, что правила техники безопасности написаны кровью, то правила резервного копирования созданы опытом потери данных.
Но не следует воспринимать данное правило, как догму, также как следовать иным распространённым аксиомам, скажем, не хранить резервные копии на самом же сервере, потому как из любого правила допустимы исключения.
Все должно следовать той же логике анализа угроз и способов им противодействовать. Резервные копии должны не только храниться в надежном месте, но и быть доступны в случае необходимости. Что толку в копии виртуальной машины на удаленном хостинге если копироваться она оттуда будет несколько часов, а восстановить одну из нескольких СУБД нужно здесь и сейчас.
Копии для оперативного восстановления должны располагаться в пределах сети предприятия, но в отдельном хранилище, желательно физически разнесенном с защищаемыми серверами. Либо хранилищ может быть несколько, одно прямо в серверной, с быстрыми каналами связи, другое, более медленное, в другом корпусе или даже в филиале.
Что касается облачных сред и хостинга, то его роль может выполнять хранилище или услуга, предлагаемая самим хостером, что обеспечит высокую скорость восстановления при необходимости.
Теперь о форматах. Копию для непосредственного восстановления данных лучше всего хранить в родном формате защищаемого приложения, желательно без сжатия, так как наша цель не экономия хранилища, а максимально быстрое восстановление. Для баз данных это может быть дамп средствами самой СУБД. Но могут быть ситуации, когда рабочего экземпляра СУБД нет, а данные восстановить надо. Это важно для приложений, которые могут использовать различные СУБД и платформы для работы. Скажем вместо аварийного сервера с PostgreSQL на Linux у вас есть работающий MS SQL на Windows. Для этих целей нужно иметь выгрузку данных в универсальный формат для восстановления на любой платформе, это может быть как родной формат приложения, так и некоторый универсальный, скажем XML.
Таким образом мы уже получаем две резервные копии в двух различных форматах хранения. Одна в сыром виде на самом сервере, вторая в двух форматах в локальном хранилище.
Промежуточный итог
Например, мы неоднократно сталкивались, что при достаточном объеме системы хранения и выделенных гигабитных каналах дампы БД хранились сжатыми неэффективным 7Zip, который долго сжимает, долго распаковывает и сильно нагружает при этом процессор. При этом частота резервного копирования была явно недостаточной, т.к. архиватор тратил на упаковку около 20 минут, и пользователи жаловались на снижение производительности системы. Налицо неверный выбор архиватора, основанный на степени сжатия, а не на эффективности и скорости работы.
Другой пример: архив 1С: Предприятия хранится в формате дампов СУБД, а не выгрузки самой 1С. В итоге при необходимости развернуть архивную базу локально или на сервере с иной системой управления базами данных администратору сначала потребуется развернуть дамп, подключить базу и сделать из нее выгрузку в формат 1С:Предприятия.
Как-то раз мы помогали одному нашему заказчику решать проблему резервного копирования файлового сервера с общим объемом данных около 2 ТБ и весьма серьезными требованиями по глубине хранения копий. Попытка копировать все и сразу вполне ожидаемо не увенчалась успехом, начиная с вопросов, где это все хранить и заканчивая временем необходимым для этой процедуры.
Поэтому мы предложили зайти с другой стороны и посмотреть, что именно там хранится. Оказалось, что большая часть файлов (по размеру) представляет собой архив конструкторской документации, которую вообще следует перевести в режим только чтение, а любые изменения оформлять как новые версии документов. Далее выяснилось, что определенные наборы документов должны быть доступны для записи только для определенных отделов, скажем договора могут корректировать только юристы, остальным они также должны быть доступны только на чтение. Таким образом удалось разделить одну «неподъемную» задачу на ряд более простых, с гораздо меньшими объемами копируемой информации, а также, в качестве «бонуса», упорядочить работу с информацией и правила доступа к ней.
Резервные копии нужно проверять
Этого момента мы несколько раз коротко касались выше, говоря о том, что ряд форматов не обеспечивает гарантированного восстановления информации, при этом, не вызывая ошибок при выгрузке. Кроме того, к повреждению копий могут приводить различные внешние факторы, которые вы можете заметить далеко не сразу. Поэтому копии нужно проверять. И делать это не время от времени, а регулярно. К счастью, это несложно автоматизировать. При ошибках восстановления весь лог должен быть отправлен на почту ответственному лицу.
В другом случае удалось своевременно выяснить, что текущий размер базы не позволяет загрузить ее на 32-битном сервере, это позволило своевременно спланировать и провести апгрейд, не дожидаясь пока это станет причиной нештатной ситуации.
А как насчет плана восстановления?
Что такое план восстановления? Это детально и максимально подробно описанная процедура восстановления рабочей копии данных из резервной. Своего рода пошаговая инструкция, дословно выполнив которую любой специалист достаточного уровня сможет произвести восстановление данных. При этом внести в нее нужно всё, в том числе и банальные, очевидные на первый взгляд, вещи. Потому что в условиях стресса это может вылететь из головы, а еще, то что «очевидно» для вас, не всегда является очевидным для ваших коллег.
Простой пример: вы внедрили в качестве архиватора современный и эффективный Zstandard и поехали в отпуск, когда вы были не на связи вашему коллеге потребовалось восстановить данные из копии. Допустим, даже ничего серьезного, нужно было вернуть все назад после неудачных технических работ. Но тут его поджидал сюрприз в виде неизвестного ему формата zst. В итоге время было потрачено на то, чтобы выяснить что это такое и как с этим работать, работы вышли за рамки технологического окна, возник простой и руководство выразило недовольство работой IT-службы. Но всего этого можно было бы избежать, если бы это было где-то отражено в документации.
Кроме того, сам процесс составления плана позволяет выявить недоработки в системе резервного копирования, узкие места, потенциальные проблемы. В этом нет ничего зазорного или порочащего, ошибаться, либо неверно оценивать необходимые ресурсы свойственно всем, лучше если это будет исправлено еще на этапе планирования, нежели вы столкнетесь в этим в критической ситуации.
И последнее, составив план не забудьте провести по нему «учения», это не только позволит оценить соответствие теории практике, но и получить практические навыки восстановления данных. И даже если учения закончатся неудачей, то это не повод для уныния, а, наоборот, весьма ценный и полезный опыт, анализ которого позволит устранить выявленные недостатки. Такие учения следует время от времени повторять, как для закрепления навыков, так и для проверки того, что текущие условия позволят вам успешно выполнить план.
Выводы
Данный материал получился достаточно обширным и в то же время обобщенным. Мы не касались конкретных сценариев и примеров, стараясь говорить об общих принципах. Понятно, что все вышесказанное не всегда можно воплотить в жизнь в полном объеме, но данная статья должна стать больше информацией для размышления и оценки текущего состояния дел. Мы будем рады, если вы сможете по-новому взглянуть на процесс резервного копирования и привести его в состояние адекватное возникающим угрозам, а не делать копии ради копий.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 