что такое снапшот простыми словами

Snapshots — «фото на память (дисковую;)»

Всегда странно представлять себе времена, когда чего-то не было. Сложно сегодня представить себе, как мы жили без персональных компьютеров, без интернета, без торрентов, mp3, или без электрокопировальных аппаратов, в просторечии «ксероксов». Тем не менее всегда были времена, когда что-то привычное нам еще не существовало. Также обстояло дело и с понятием «снэпшота данных». Но сперва — что же такое «снэпшот»?

«Снэпшот» (дословно — «фотография», «моментальный снимок», здесь и далее под этим словом мы будем понимать конкретно, не уточняя, «снэпшот данных») это моментальная копия состояния данных в системе хранения, или программе, зафиксированная на определенный момент времени. Это может быть моментальное состояние содержимого файла, базы данных, или файловой системы (как частного случая «базы данных»).
В применении к системам хранения данных этот термин появился вместе с первыми системами хранения NetApp и был, на тот момент первой и главной их «фичей».

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

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

Inode, напомню, это блок данных, определяющий содержимое файла. Он может ссылаться либо прямо на конкретные блоки, либо, для больших файлов, на промежуточные inodes, образуя «дерево» от «корня», единственного на всю файловую систему тома, так называемого «корневого» inode.
Таким образом, создав копию ровно одного блока, корневого inode данной файловой системы, мы получим, обратившись к нему, вместо текущего «корня», «псевдо-файловую систему», хранящую без изменений (read-only) все данные на момент времени, когда мы скопировали этот inode. Ведь, как вы помните, однажды записанные блоки данных файлов в дальнейшем не изменяются.

Каким же образом это выглядит на практике?
Для упрощения рассказа я буду рассматривать NAS-вариант работы NetApp, хотя, как вы знаете, аналогичным образом тот же самый сторадж может работать и как SAN-устройство.

Каждый том на системе хранения NetApp является отдельной файловой системой. На каждой файловой системе можно создать до 254 снэпшотов ее состояния, по методике, описанной выше.
Все созданные снэпшоты автоматически доступны через директорию /.snapshot (или /

snapshot) в корне тома. Зайдя туда, мы увидим имена созданных снэпшотов (они могут носить либо «собственное имя», например «/lets_fix_this_small_bug…oh_shit. «, будучи созданными вручную, либо, если создаются по расписанию, будут располагаться в поддиректориях hourly.0(1,2,3…), daily.0(1,2,3) и так далее.

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

Причем это даже выглядит несколько странно, на первый взгляд.
Допустим, что у вас есть том, размером 1TB, на котором лежит файл базы данных, размером 750GB. Для этого тома вы создаете снэпшоты каждый час по расписанию. Войдя в /.snapshot вы увидите в ней поддиректории /hourly.0, /hourly.1, и так далее, причем в каждой из них будет лежать «файл размером 750GB». При этом на собственно томе, емкостью 1TB, на котором как бы и лежат эти 24 (каждый час) копии базы по 750 гиг размером каждая, еще будет гигабайт 200 свободного места.
При этом любой из этих 24 «файлов» мы можем скопировать в резервную копию на внешнее хранилище, смонтировать как независимый read-only и использовать (читать) эти данные, как если бы это была реальная база данных, восстановить из нее данные, скопировав ее на место «активной», например в случае «все сломали, надо откатится на состояние час назад», и так далее.

Где же все это хранится?
Дело в том, что все эти «файлы», это просто ссылки на одни и те же блоки неизмененных данных. Место же на диске занимают только изменения, между снятыми снэпшотами. Допустим, что за сутки мы наменяли в этой базе блоков на 50 гигабайт. Тогда занятое место на дисках, в томе размером 1TB, на котором лежит файл базы на 750GB, и снэпшоты каждый час, будет 1TB — 750GB файл — 50GB изменений = 200GB свободно.
Если изменений за час между двумя снэпшотами (hourly.0 и hourly.1) получилось на 1% объема базы, то hourly.1 займет 7,5GB места на диске, указывая своими inodes на измененные, по сравнению с предыдущим снэпшотом, блоки. Все же остальные inodes по прежнему будут ссылаться на прежние, неизмененные блоки.

Чем удобно использование снэпшотов?
Простейший пример я уже привел. Допустим мы, или наши пользователи, «все сломали». Это может быть база данных, или же, допустим, экселевский файл, в котором, случайно, грохнули не те данные, успели записать, а потом обнаружили это, а восстановить надо срочно, «или нас всех убьют». Но мы знаем, что час (два, три, сутки, неделю, месяц назад, все зависит от частоты и регулярности снэпшотов) нужный нам файл был исправен.
Мы (это может сделать, кстати, даже сам пользователь) просто заходим в папку /.snapshots и вытаскиваем оттуда простым копированием нужный нам файл, на нужный момент времени, час, два, сутки, и так далее назад.
Либо, если у нас есть специальная лицензия SnapRestore, одной командой из консоли стораджа, «откатываем» состояние тома на нужный момент времени целиком (что удобно, если нужно восстановить не отдельный одиночный файл, а содержимое всего тома, в целом).

Таким образом, снэпшоты это, для пользователя, очень оперативная резервная копия, доступная тут же, на этом же сторадже. Кстати, в случае использования Windows XP или 7, вы будете видеть файлы в снэпшоте в панели «Previous versions» свойства файла или папки, NetApp интегрируется в этот механизм Windows как VSS-provider.

Теперь рассмотрим более сложный вариант. Допустим, мы эксплуатируем большую, ответственную, mission-critical SQL-базу данных предприятия.
Разумеется, каждый вечер, эта база данных бэкапится на ленту, для создания резервной копии.
База большая, и резервная копия копируется на ленту примерно час.
«Ничто не предвещало беды», но однажды, посреди рабочего дня, допустим в 3 часа дня, база необратимо портится.

Какие действия предпринимает сисадмин, для того, чтобы базу восстановить?
Мы считываем резервную копию по состоянию на конец прошлого рабочего дня (читаться она будет, допустим, столько же, сколько писалась — час), а затем нам следует «накатить» на нее redo-log-и, от момента создания бэкапа, вечером, и до момента, предшествующего сбою, то есть до 3 часов следующего дня. Этот «накат» часто довольно объемен, и также занимает какое-то время, ведь операции в SQL происходят не мгновенно. Допустим, через 30 минут, после окончания считывания бэкапа, база восстановлена в рабочем состоянии на момент предшествующий сбою, и мы готовы продолжать работу. Итого — 1:30.

В случае использования снэпшотов дела будут происходить следующим образом. У нас также делается ежедневная копия на ленту для обеспечения безопасности хранения, например на случай полного выхода из строя системы хранения, но у нас хранилище живо, повреждены только данные на нем. Мы знаем, что час назад база была жива и здорова. Мы восстанавливаем базу по состоянию на 2 часа дня, и так как снэпшот создается и восстанавливается практически мгновенно, то это занимает не час, а всего несколько секунд, и накатываем на нее redo-logs, но не со вчерашнего вечера, как в предыдущем случае, а всего за один час, с 2 часов, то есть момента создания снэпшота, до момента аварии, в 3 часа дня. Это занимает также не полчаса, а всего несколько минут.
Итог: спустя несколько минут, а не полтора часа, как обычно, наша база вновь в рабочем состоянии.

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

В чем же принципиальное отличие «настоящих снэпшотов» (Название Snapshots ™ для систем хранения это зарегистрированная торговая марка NetApp) от всех остальных, «контрафактных копий». 😉

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

Эта технология носит название Copy-on-Write (COW), и широко применяется в системах хранения других производителей, в их реализации снэпшотов.
Как вы видите из описания выше, даже само наличие включенного механизма снэпшотов для тома превращает одну операцию записи для системы хранения в три (чтение исходного содержимого, запись исходного содержимого на новое место, запись измененного содержимого на старое место).
Результат не заставляет себя ждать. Использование COW-snapshots резко ухудшает производительность системы хранения его использующего. Это разительный контраст с системами NetApp, в которых снэпшоты вообще никак не влияют на производительность, ведь никакого копирования при записи в них не происходит, все данные остаются на своих местах.
(демонстрация результатов производительности на тесте SPC-1)

Следствием такого неприятного поведения при использовании COW-snapshots является рекомендация вендоров свести использование таких «неправильных снэпшотов» к минимуму, или не использовать их вовсе на primary-системах, предъявляющих повышенные требования к производительности.
Однако системы NetApp такой проблемой не страдают и никаких ограничений на использование снэпшотов не предъявляют.

Кроме этого, часто (по той же причине) общее количество снэпшотов на таких системах ограничено всего парой десятков максимум, отмечу, для контраста, что на системах NetApp можно использовать до 254 снэпшотов на каждый том, что, при общем количестве томов, допустимых систему, равного 500, достигает теоретического максимума в 127 тысяч.
Это позволяет, при использовании классической «ротации» резервных копий, хранить в 254 снэпшотах резервные копии данных тома до года включительно.

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

Практика показывает, что люди, попробовавшие простоту и удобство использования снэпшотов, очень скоро уже просто не представляют себе жизни без них, считая это «само собой разумеющейся» возможностью любой системы хранения. Попробуйте и вы.
Напомню, что взять на тестирование систему хранения NetApp можно у любого партнера, список которых можно посмотреть на российской странице вебсайта NetApp.
www.netapp.com/ru/how-to-buy/resellers/distributor-ru.html
www.netapp.com/ru/how-to-buy/resellers/platinum-ru.html
www.netapp.com/ru/how-to-buy/resellers/gold-ru.html

PS: На традиционном «фото для привлечения внимания» в заголовке — задняя часть контроллера самой младшей модели NetApp — FAS2020. Самой младшей, но, тем не менее, обладающей всеми возможностями хранилищ NetApp, в том числе и работой со снэпшотами.
На фото, слева направо — два порта FC 4Gb/s, порт последовательной консоли, порт out-of-band микроконтроллера удаленного администрирования, и два порта Gigabit Ethernet.

PPS: А еще можно было бы написать на этой неделе про 5 место NetApp в Fortune’s list Best Plaсes to Work, вон Intel стррашно гордится аж 51-м местом (из ста), но мне показалось, что все эти радости пиар-отдела Хабру не очень интересны, поэтому упомяну об этом «бегущей строкой» в самом конце. Да, пятое место в сотне лучших работодателей США, и пятнадцатое (выше Google (30) и Apple (20), кстати) по списку сайта Glassdoor, оценивающего компании не «снаружи», как Fortune, а изнутри, анонимными голосами самих работников. «Пустячок, а приятно».

Источник

Что такое снапшот

Что такое снапшот?

Снапшот (английское snapshot – моментальный снимок) используется в сфере VDS/VPS, а также в облачном хостинге.

При восстановлении сервера из снапшота он продолжит свою работу ровно с того момента, когда был создан снимок.

Разница между снапшотом и резервным копированием

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

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

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

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

Использование технологии снапшотов у хостинг-провайдеров

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

Пример: У провайдера Vdsina снапшоты виртуального сервера в личном кабинете называются резервными копиями:

Другое часто используемое название для снапшота у провайдеров хостинга это “снимок”. Например, у провайдера Nic.ru в панели управления есть специальный раздел “Снимки”:

Вот так выглядит создание снимка (снапшота) сервера в панели управления хостингом у провайдера ServerSpace:

Выводы

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

Источник

Backup и Snapshot: что это?

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

Резервное копирование (backup)

Резервные копии нужны для восстановления утраченной или испорченной информации. Также резервное копирование применяется для архивирования (сохранения данных для использования их в будущем).

Копировать можно:

Виды резервного копирования

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

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

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

Дифференциальное копирование

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

Инкрементное копирование

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

Время резервного копирования

Для того чтобы правильно планировать резервное копирование, необходимо рассчитать два показателя: RPO и RTO.

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

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

Инструменты резервного копирования

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

Встроенные инструменты резервного копирования

Современные операционные системы уже включают в себя инструменты резервного копирования. Например, для Windows, начиная с Microsoft Vista, доступна программа Windows Backup And Restore (Архивация и Восстановление). Эта программа позволяет создавать полный бэкап операционной системы с возможностью инкрементного копирования. Windows Backup And Restore позволяет создавать автоматический полный бекап на сменный носитель, оптические диски или в специальное место на удаленном сервере.

Для копирования небольшого количества файлов и каталогов часто используется команда xcopy. Эту команду можно использовать с планировщиком Windows.

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

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

Бесплатные и платные программы резервного копирования

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

Главное – это перед использованием на реальных данных проверить на тестовой копии тех же самых данных. Кроме того, необходимо проверить можно или восстановить данные из архива.

Облачное резервное копирование

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

Такие системы, как CommVault или Veeam позволяют делать резервные копии в облако для:

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

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

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

Shapshot – снимки системы

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

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

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

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

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

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

Рассмотрим виды создания снэпшотов.

Файловые службы

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

Вот важные особенности теневых копий:

В UNIX-системах можно использовать файловую систему ZFS, которая предоставляет широкие возможности по созданию и управлению снимками файловой системы.

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

Снэпшоты в виртуальных машинах

Такие гипервизоры, как Hyper-V или Wmware vSphere содержат встроенные средства создания снэпшотов. Использование СХД для размещения виртуальных машин и их снэпшотов позволяет снизить влияние снимков на производительность виртуальных машин, благодаря особенному устройству дисковых массивов.

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

Выводы

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

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

Бэкап важных данных следует делать в соответствии с правилом 3-2-1:

1. Создавайте три копии важных данных.

2. Две копии должны быть сохранены на различных физических носителях.

3. Одна копия должна храниться отдельно от двух других, в другом здании.

Источник