Считают ли моментальные снимки + RAID хорошим решением для резервного копирования на месте?

Кажется, о двух основных причинах создания резервных копий я думаю, когда использую и снимки, и RAID вместе с btrfs. (Под RAID я имею в виду RAID1 или 10)

• Случайное удаление данных: снимки покрывают этот случай
• Отказ привода и гниение
  • Полный сбой: RAID покрывает этот случай
  • Диск возвращает неверные данные: функция исправления ошибок RAID + btrfs покрывает этот случай

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

Однако я слышал, что и RAID, и моментальные снимки не считаются правильными резервными копиями, поэтому мне интересно, пропустил ли я что-нибудь.

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

Нет, это не так.

Что происходит, когда ваша файловая система или том RAID поврежден? Или ваш сервер подожжен? Или кто-то случайно форматирует неправильный массив?

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

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

И регулярно проверяйте, можно ли восстановить ваш «снятый снимок».

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

Конечно, лучшая резервная копия всегда вне сайта. Таким образом, после «отправки» снимков в отдельную систему регулярно делайте «снимки» с снимков.

Итак, в моей системе сервер, который получает дельты снимков, регулярно сбрасывает все свои пулы ZFS (включая более ранние снимки) на ленту.

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

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

Что сказал HopelessN00b. Нет.

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

(Предупреждение об анекдоте: однажды я услышал о ком-то, у которого PXE настроен на автоматическую установку последней Fedora. Его ИБП вышел из строя. После отключения питания его сервер перезагрузился и был настроен на загрузку PXE и ​​... установил Fedora поверх своих данных. точка? Причудливые вещи случаются. К счастью, у него были правильные резервные копии.)

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

Правильно реализованные моментальные снимки ДОЛЖНЫ поддерживаться вашим хранилищем, поскольку приличное резервное копирование использует их как самый первый этап создания задания резервного копирования. Тем не менее, использование первичных резервных копий - это плохая идея. Причины:

1) Снимки и внутреннее хранилище МОГУТ сбоить. Таким образом, реальные резервные копии должны использовать отдельный набор шпинделей, иначе существует большая вероятность потери как основного рабочего набора, так и данных резервного копирования @ одновременно.

2) Снимки "жуют" полезное пространство. Имеет смысл использовать дорогостоящее и быстрое хранилище для текущих горячих данных, снимков и резервных копий без нагрузки, которые представляют собой ледяные данные для некоторых более дешевых и более медленных хранилищ. Это работает очень хорошо с 1) Кстати.

3) Снимки обычно замедляют весь процесс. Большинство систем используют Copy-on-Write, и этот подход создает фрагментацию. Redirect-on-Write быстрее, но ест много места. Очень немногие поставщики правильно внедрили снимки. NetApp с WAFL и Nimble Storage с CASL (я не связан ни с одним из них). Практически у всех есть проблемы. Например, Dell Equallogic запускает обновление 15 МБ страниц (и растрату) на каждый отдельный байт. Это дорого.

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

Просто чтобы подтвердить - прежде чем я дам больше советов ... ты работаешь на моего конкурента, верно? Вы действительно делаете, конечно? Нет? Ой.

Извините, ОРЕХИ. Нет, совсем нет. Извини чувак.

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

От чего вы не защищаете:

• Мощный всплеск уничтожает машину. Был там, видел это.
• Какой-то неисправный рейд-контроллер или память, записывающая sh ** на диск - там идет все что угодно.

И длинный список других вещей.

Это - естественно, если вы не работаете на моего конкурента - всегда делайте резервную копию:

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

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

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

Теперь вы можете подумать «о, наводнения не бывает». Убедитесь, что вы уверены. Смотрите видео затопления дата-центра vodaphone от 09.09.09. Я уверен, что вы поймете, где проблема для резервного копирования inite / in computer:

http://www.youtube.com/watch?v=ttcQy3bCiiU

Урок, извлеченный из двух дисков RAID-1, выходящих из строя в течение получаса друг от друга: RAID не является механизмом резервного копирования, ни в какой форме, ни в форме, ни в форме.

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

Многие опытные администраторы используют правило резервных копий 3-2-1:

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

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

• У вас должна быть хотя бы одна внешняя копия ваших данных.

Снимки нарушают все три части:

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

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

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

Следовательно:

• У вас должна быть хотя бы одна резервная копия на отдельной машине в вашей локальной сети.

• У вас должна быть хотя бы одна резервная копия, которая не создается с помощью моментальных снимков. Возможно, старый добрый инкрементальный tarархив может быть в порядке? Или rsyncоснованная копия?

• У вас должна быть хотя бы одна удаленная резервная копия, как можно дальше от вашего текущего местоположения и определенно не в том же здании.

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

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

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

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

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

• RAID плюс снимки на том же оборудовании
• Локальные копии на другом оборудовании (помните: существуют режимы сбоев, которые бы уничтожали всю коробку, контроллер, диски и все сразу)
• Полуотключенные удаленные копии
• и, конечно, правильные офлайн + сторонние копии для настоящих бедствий

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