Что нужно для полноценной системы резервного копирования?

Мы создаем системы резервного копирования для одной цели: для восстановления. Никто не заботится о резервных копиях; они заботятся о восстановлении.

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

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

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

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

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

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

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

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

Это было очень краткое изложение части главы 26 книги. Практика системного и сетевого администрирования, второе издание, который любой, кто является или стремится стать системным администратором, должен владеть, читать и запоминать.

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

1. DropBox - опасный способ резервного копирования. Нет SLA / QoS, и, вероятно, это противоречит их обычным TOS автоматически выгружать такой объем данных на их серверы. Они специально отказываются от какой-либо ответственности за доступ к вашим данным - они могут перекрыть доступ, уничтожить данные или обанкротиться по своему усмотрению и без предупреждения.
2. Никакая процедура резервного копирования не считается «действительной», пока вы не восстановите ее, это единственный способ убедиться в этом. Большинство программ для резервного копирования предоставляют функцию «проверки», что для большинства людей хуже, чем бесполезно, поскольку только проверяет, что что-то был записан на резервный носитель, не что что-то действительно полезен при восстановлении операционной системы.
3. Безупречно полная документация гарантирует, что вы сможете выполнить процедуры восстановления в случае аварии - документация по тестированию должна быть частью тестирования восстановления вашей системы. Кроме того, что кто-то другой сможет завершить процедуры, если вы попадете в автобус (закон Мерфи и все такое).
4. Восстановление полезно только в том случае, если оно может быть выполнено в значимый период времени. Например, если бы на восстановление ваших данных ушел год, это было бы бесполезно. Вы должны определить, какие временные рамки необходимы в вашей ситуации для трех уровней функциональности: минимальная функциональность, ежедневные операции, полная. Протестируйте предложенное решение, посмотрите, подходит ли его время.

Нет. Ты сейчас в порядке. По крайней мере, с концептами ...

• Подумайте о состоянии вашей системы во время резервного копирования. Возможно, вы не хотите делать резервную копию живой базы данных ...
• Или подумайте о своем оборудовании. Вы делаете все возможное, чтобы сделать машину максимально устойчивой? Например, я хочу, чтобы восстановление из резервной копии было ПОСЛЕДНИМ делом, которое мне нужно делать в экстренной ситуации.
• Сбои в работе и небольшие перебои в обслуживании могут быть сокращены за счет использования качественного оборудования, поэтому убедитесь, что вы используете RAID, оборудование серверного класса и ищите более локальный подход к защите данных.
• Подумайте о типах сбоев и ситуациях, от которых вы защищаетесь.
• Я бы не стал использовать DropBox, но идея офсайтовой защиты правильно.

Моя предпочтительная, испытанная и надежная система резервного копирования:

1. Ежечасные снимки всех баз данных (и один снимок архивируется в день в течение двух недель, один снимок архивируется в неделю в течение года).
2. Одноразовые серверы. То есть все резервные копии серверов хранятся в git и развертываются автоматически (очень похоже на то, что вы говорите с марионеткой, но наш предпочтительный инструмент - chef). По сути, новый сервер можно создать с нуля, используя только имеющийся у вас код. в git, что означает, что все хосты разработки построены так же, как ваши производственные серверы.

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

С другой стороны, если у вас больше пары серверов, хостов и т. Д., Стоит вложить средства в использование центрального сервера журналов. Если они размещены (и имеют резервную копию) из одного источника, это избавит вас от головной боли, связанной с накоплением журналов на остальных ваших хостах и ​​занимающих место. Данные журналов - это золото, но если у меня есть 20 серверов api, обслуживающих трафик, и я сталкиваюсь с чем-то вроде DDoS, отсутствие агрегации моих журналов означает, что я ищу иголку в стоге сена. Если вы собираетесь хранить журналы инфраструктуры (а вам следует это делать!), Сохраните их один раз на одной надежной платформе резервного копирования.

Удачи ~!

RAID и такие сервисы, как Dropbox "резервное копирование" все ваши изменения. Включая ошибки, от которых вы хотите исправить с помощью резервной копии.

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

Резервная копия должна быть моментальным снимком того, что было на момент создания резервной копии, а не постоянно перезаписываемым живым журналом всех хороших и плохих вещей, которые происходят с вашими данными по мере их возникновения. Есть облачные провайдеры, которые предоставят вам реальную резервную копию, если вы посмотрите, и они работают иначе, чем сервисы типа dropbox / skydrive.

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