Когда я использую как моментальные снимки, так и RAID вместе с btrfs, я могу думать о двух основных причинах создания резервных копий. (Под RAID здесь я подразумеваю RAID1 или 10)
Так что, как решение для резервного копирования на месте, это работает нормально, и для него даже не требуется отдельное устройство хранения данных!
Однако я слышал, что и RAID, и моментальные снимки не считаются правильными резервными копиями, поэтому мне интересно, не упустил ли я что-нибудь.
Помимо того, что btrfs еще не является зрелой технологией, можете ли вы вспомнить что-нибудь, что я пропустил? Или я правильно считаю, и это действительное решение для резервного копирования на месте?
Нет, это не так.
Что произойдет, если ваша файловая система или том RAID будет поврежден? Или ваш сервер загорелся? Или кто-то случайно форматирует не тот массив?
Вы теряете все свои данные и не настоящие резервные копии, которые, как вы думали, у вас есть. Вот почему настоящие резервные копии находятся в совершенно другой системе, чем данные, которые вы копируете, - потому что резервные копии защищают от того, что происходит с рассматриваемой системой, что может привести к потере данных. Храните свои резервные копии в той же системе, в которой вы выполняете резервное копирование, и потеря данных в этой системе также может повлиять на ваши «резервные копии».
Для на месте резервное копирование, снимок мощь будь достаточно хорошим, при условии, что вы регулярно «экспортируете» свой снимок в другое место, где он существует как пассивные данные.
И регулярно проверяйте, можно ли восстановить ваш «отправленный снимок».
Вот как я реализовал быстрое резервное копирование некоторых из моих серверов: сохраняю данные на ZFS, делаю снимок ZFS, отправляю дельта на другой сервер, где вся файловая система воссоздается заново (за вычетом самой запущенной службы).
Конечно, лучшая резервная копия - это всегда за пределами площадки. Таким образом, после «отправки» моментальных снимков в отдельную систему регулярно снимайте их с ленты.
Итак, в моей системе сервер, который получает дельты снимков, регулярно выгружает все свои пулы ZFS (включая более ранние снимки) на ленту.
И, конечно же, проверьте свои кассеты, чтобы убедиться, что их можно восстановить.
Примечание: вы хотите, чтобы моментальный снимок создавался во время приостановленной активности диска, и желательно в координации с базой данных (если есть) для обеспечения согласованности; иначе лекарство может быть хуже болезни. Вот почему очень полезна функция NetApp & EMC «live snapshot»: они откладывают моментальный снимок LUN до тех пор, пока база данных, использующая LUN, не укажет, что создание моментального снимка безопасно.
Что сказал HopelessN00b. Нет.
Правильные резервные копии находятся на отдельном устройстве, а не на устройстве, для которого выполняется резервное копирование. Что произойдет, если вы потеряете два или более дисков? Что произойдет, когда ваша серверная комната сгорит? Что произойдет, если кто-то случайно уничтожит ваш массив?
(Предупреждение анекдота: однажды я слышал о человеке, у которого PXE настроен на автоматическую установку последней версии Fedora. Его ИБП вышел из строя. После отключения электроэнергии его сервер перезагрузился и был настроен на загрузку PXE и ... установил Fedora поверх своих данных. Мои случаются странные вещи. К счастью, у него были надлежащие резервные копии.)
Желательно, чтобы у вас было по крайней мере три копии ваших данных, одна из которых хранится полностью вне офиса на случай, если центр обработки данных выйдет из строя.
Да, это так. Это идеальный способ хранить резервные копии. Ничего другого не нужно, черт возьми, даже проверка на честность - пустая трата времени.
Просто чтобы подтвердить - прежде чем я дам еще один совет ... вы работаете на моего конкурента, верно? Вы действительно уверены? Нет? Ой.
Простите, ОРЕХИ. Нет, совсем нет. Извини чувак.
Проблема в том, что вы полностью открыты для любых ошибок, которые происходят в (а) системе и (б) на уровне операционной системы. Вы в основном защищаете только от того, кто-то удалит некоторые данные. Ницца. Это часто встречающаяся ошибка.
Вы не защищаетесь от:
И длинный список других вещей.
Это - естественно, если вы не работаете на моего конкурента - всегда делайте резервную копию:
Вот почему ленты качаются - они не связаны, и ничто, кроме пожара или наводнения, им не повредит. Скачок мощности - там идет считыватель лент и, возможно, робот, но ленты не в считывателе не пострадают.
ЛУЧШИМ было бы резервное копирование за пределами объекта (я уже упоминал такие вещи, как пожар и наводнение?) (Опять же, когда вы работаете на конкурента - нет такой вещи, как пожар в здании, он совершенно не нужен, как и страхование от пожара, пожалуйста, сэкономьте деньги).
Теперь вы можете подумать: «Ой, наводнения никогда не бывает». Убедитесь, что вы уверены. Смотрите, вот видео 09.09.09, затопление датацентра водофона. Я уверен, что вы поймете, в чем проблема при резервном копировании компьютера:
Правильно реализованные моментальные снимки ДОЛЖНЫ поддерживаться вашим хранилищем, поскольку достойные резервные копии действительно используют их в качестве самого первого этапа создания задания резервного копирования. Однако использовать моментальные снимки для первичного резервного копирования - плохая идея. Причины:
1) Снимки и внутреннее хранилище МОГУТ выйти из строя. Таким образом, при реальном резервном копировании необходимо использовать отдельный набор шпинделей, иначе существует большая вероятность одновременной потери как основного рабочего набора, так и данных резервного копирования.
2) Снимки «съедают» полезное пространство. Имеет смысл использовать дорогое и быстрое хранилище для текущих горячих данных, а также моментальные снимки и резервные копии без нагрузки, которые являются ледяными данными для более дешевого и медленного хранилища. Он очень хорошо работает с 1) Кстати.
3) Снимки обычно замедляют весь процесс. Большинство систем используют копирование при записи, и этот подход создает фрагментацию. Redirect-on-Write быстрее, но потребляет МНОГО места. Очень немногие производители правильно реализовали снимки состояния. NetApp с WAFL и Nimble Storage с CASL (я не связан ни с одним из них). Проблемы есть почти у всех. Например, Dell Equallogic запускает обновление страницы 15 МБ (и отходы) на каждый измененный байт. Это дорого.
Урок, извлеченный из двух дисков RAID-1, выходящих из строя в течение получаса друг от друга: RAID не резервный механизм, ни в каком виде, ни в какой форме.
RAID - это механизм доступности, который сокращает время простоя в случае аппаратного сбоя, но он вам совсем не поможет в случае, например, Вирусы, удаление / изменение данных или просто катастрофический отказ оборудования.
Само по себе это совсем не резервное решение. Это уменьшит или устранит простои в определенных сценариях сбоя, но не защитит вас. вообще от многих других
Конечно, это может быть очень ценной частью более комплексного решения для обеспечения доступности и резервного копирования:
Также: регулярно проверяйте свои резервные копии. Худшее время, чтобы обнаружить, что ваши резервные копии не работают, - это когда вам нужно что-то из них извлечь ...
Многие опытные администраторы следуют так называемому правилу резервного копирования 3-2-1:
У вас должно быть как минимум три копии ваших данных, включая первичный источник. Т.е. одна резервная копия не достаточно, и копии в одной физической системе не учитываются.
Вы должны использовать как минимум два разных метода резервного копирования.
У вас должна быть хотя бы одна копия ваших данных за пределами сайта.
Снимки нарушают все три части:
Вы используете только одну физическую машину. Все, что влияет на всю машину, например, отказ блока питания, может унести с собой все ваши данные.
Вы используете только один метод для резервного копирования. Если что-нибудь не так, вы узнаете только при восстановлении бэкапа в кризисной ситуации.
У вас нет резервных копий за пределами сайта. Наводнения и пожары случаются только с другими, пока они не случаются с вами ...
Следовательно:
У вас должна быть хотя бы одна резервная копия на отдельный машина в вашей локальной сети.
У вас должна быть хотя бы одна резервная копия не создается с использованием снимков. Возможно, старый добрый инкрементальный tar архив может быть в порядке? Или rsync на основе копии?
У вас должна быть хотя бы одна удаленная резервная копия, как можно дальше от вашего текущего местоположения и определенно не в том же здании.
Следует также отметить, что моментальные снимки на уровне блоков имеют примерно те же гарантии согласованности, что и отключение вашего компьютера с последующим копированием на диски. В общем, вам нужно будет запустить fsck после восстановления или надежды, что журнала хватит.
Моментальные снимки на уровне файловой системы должны быть лучше, но они по-прежнему не гарантируют целостность ваших файлов. Для многих приложений (на ум приходят серверы баз данных) копирование файлов живого экземпляра может быть совершенно бесполезным, поскольку они могут находиться в несогласованном состоянии. Вам нужно будет использовать их собственный механизм резервного копирования на уровне приложений, чтобы гарантировать существование чистой копии - для которой также будет применяться правило 3-2-1.
Наконец, имейте в виду, что сейчас мы говорим только о копиях ваших ток данные. Чтобы защититься от сбоев (или нарушений безопасности, если на то пошло), которые остаются незамеченными в течение некоторого времени, вам также необходимо иметь несколько прошлых копий ваших данных на некоторое время назад.