Что такое снэпшот сервера

Снэпшоты для Облачных серверов

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

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

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

Стоимость хранения снэпшота — 3 рубля за 1 ГБ в месяц. Скорость создания снэпшота напрямую зависит от объема данных.

Доступно 2 способа создания снэпшотов:

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

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

Работа с облачными серверами происходит через панель управления. Перейдите в панель по ссылке или:

На открывшейся странице выберите услугу «Облачные серверы»:

Как сделать снэпшот

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

Как создать снапшот виртуальной машины

Готово, созданный снэпшот появится в разделе Снэпшоты:

Как развернуть снэпшот

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

Как развернуть снапшот диска

Готово, снэпшот будет распакован на сервере.

Как удалить снэпшот

Напротив снэпшота, который нужно удалить, нажмите на корзину:

Как удалить снапшот системы

Готово, снэпшот будет удалён и исчезнет из списка.

Облачные серверы нового поколения

Виртуализация KVM, почасовая оплата, резервные копии, готовые шаблоны, 8 доступных ОС на выбор!

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

Источник

Снапшоты для виртуальных машин в облаке

Summary: Пост рассказывает о том, что такое снапшоты в облаке, как их использовать, и как они устроены.

Одна из самых заметных новых фич в облаке, появившаяся в этом году — снапшоты. Всё, что мы делаем, делится на три категории — то, что полезно нам (биллинг, сервисные утилиты и т. д.), то, что полезно клиентам, но визуально не заметно (например, СХД, смена версий гипервизора, уже ранее запущенных серверов), и то, что полезно клиентам и визуально заметно — и вот снапшоты как раз из этой третьей категории).

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

Как использовать снапшоты?

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

Снапшот может быть выполнен в любой момент времени, на включенной или выключенной машине. В момент выполнения снапшотов дисковая активность машины слегка приостанавливается (речь идёт о чём-то порядка секунды), после чего продолжается «как ни в чём ни бывало». Методов сделать снапшот два: в свойствах диска на странице с виртуальными машинами (там же есть кнопка «откатиться на предыдущий снапшот») и в списке снапшотов на странице с дисками. Там же есть список всех снапшотов диска. Заметим, для виртуальной машины мы обычно не даём возможности создать снапшот во время установки. Особо пронырли внимательные клиенты могут найти, что кнопка «создать снапшот» на странице дисков всё-таки активна (и работает). Ничего интересного (кроме полу-установившегося линукса) в таком снапшоте не будет, но мы решили не забирать у людей возможность стрелять себе в ногу делать то, что они хотят со своими машинами.

Итак, созданный снапшот содержит в себе копию диска на момент создания. По размеру он чаще всего значительно меньше, чем диск. Если кому-то интересно, как высчитывается размер снапшота — смотрите вторую часть. Снапшоты образуют цепочку (если снапшоты делаются подряд) или дерево (как такое получается — см. раздел про откат на снапшот). Если удалить снапшот, то он начинает «растворяться» — объединяться с соседними (при этом общий объём снапшотов уменьшается). Процесс довольно быстрый (несколько минут — и снапшота нет).

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

Более того, снапшот можно подключать к любому количеству машин одновременно. (Сразу отвечаю на вопрос — можно ли грузиться с снапшота — формально, да, фактически файловая система очень нервничает от read only на root’е — мы работаем над этим вопросом).

Второй по важности функцией является откат диска на снапшот, то есть восстановление состояния диска. При этом изменения теряются, так что лучше перед откатом на старый снапшот сделать новый. В этом случае диск можно будет «переключать» между снапшотами (откатывать туда/обратно). У процесса отката на снапшот есть некоторые мелкие неудобства — становится недоступна статистика по дисковым операциям и неправильно показывается потребление машины в прошлом. Общее потребление по акаунту при этом высчитывается правильно, но так как образовывается новый VBD (блочное устройство), то данные для VM показываются для нового VBD. (Мы знаем про эту не очень очевидную особенность нашего биллинга и планируем его поменять на более удобную в обозримом времени).

Для удобства использования в последние несколько дней перед анонсом мы добавили «последний штрих» — если диск откатывается из снапшота, то у него появляется поле reverted_at (то есть «восстановлен из снапшота»). Мелочь, но полезная. Это поле будет преследовать диск до самой его смерти (и после, хе-хе, мы данные об объектах не удаляем).

Важный момент: каждый раз, когда делается или откатывается снапшот, наблюдается синдром «COW» (copy-on-write) — первая запись будет медленнее последующих. Так что на очень нагруженных серверах с большим количеством записи с созданию снапшотов следует относиться аккуратно.

Если сделать у диска несколько снапшотов, потом откатить диск на снапшот в «середине», потом сделать несколько снапшотов, потом откатить его на другой снапшот, потом снова откатить его, то образуется дерево снапшотов. Мы храним в нашей БД отношения — какой снапшот чьим является. К сожалению, визуализация пока в работе (программисты сильно протестуют, получив задачу «нарисовать дерево на JS», и пусть им будет стыдно при чтении этого поста).

Лимиты. К сожалению, вся эта роскошь не безгранична. Наши ограничения: длина цепочки снапшотов не более 20 дисков, максимальное количество снапшотов в дереве (с учётом ветвлений) — не более 60 шт. По нашим оценкам этого более чем достаточно для нормальной работы.

На странице «дисков» у каждого диска есть вкладка «снапшоты», где приводится список всех снапшотов диска. Снапшоты можно называть и давать им многострочное описание (но все ленивые, да, я тоже люблю, когда эти поля заполнены, но заполнять их обычно очень лень). В любом случае снапшот может быть уникально идентифицирован по абсолютно бесполезному номеру (англ. universally useless ID, uuid) и (частично) по дате создания.

Немного о поле «итого». В силу некоторых особенностей работы системы информация о снапшотах обновляется неравномерно — список снапшотов обновляется сразу после создания снапшотов, а вот поле «итого» может запаздывать некоторое время — до двух минут. В отличие от остальных ресурсов, которые мы обсчитываем в реальном времени, диски и снапшоты учитываются с (примерно) двухминутным интервалом. Поле «итого» высчитывается в момент вычисления объёма потребления, так что «итого» сразу после создания снапшота будет некорректным (но точно придёт в норму к следующему тику списания).

Как это устроено?

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

Наши снапшоты (как и диски) основываются на VHD-формате, который был придуман microsoft, отдан в публичное пользование и использован citrix. Он поддерживает очень эффективные снапшоты (они много эффективнее, чем снапшоты LVM, которые увеличивают количество записей пропорционально числу снапшотов). Когда выстраивается цепочка снапшотов, там неявным образом подразумевается «нулевой» снапшот, относительно которого фиксируются изменения всех остальных (без этого «нулевого» снапшота становится не понятно — что за «изменения» хранятся в первом снапшоте). Нулевой снапшот, разумеется, не оплачивается (т.к. физически места на диске не занимает).

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

Что происходит при создании снапшота? (Техническая часть).

Текущий диск объявляется так называемым ‘base copy’, то есть read only копией состояния машины. Так как у диска могли быть предшественники в цепочке снапшотов, то base copy ссылается на другие base copy (заметим, base copy всегда ссылается только на base copy). Кроме этого делается ещё «снапшот» — это read/write копия текущего состояния (то есть отличия снапшота от base copy). В общем случае в снапшоты можно писать, но мы это запрещаем, так как в этом случае получится thin provision, а мы не можем его допустить из соображений гарантированности зарезервированного пространства (см раздел ниже). Но даже «незаписанный» снапшот содержит в себе 8Мб мета-данных. Таким образом, каждый снапшот состоит из двух половинок: метаданных (8Мб) и содержимого base copy. Диск ссылается одним видом ссылок на base copy предыдущего снапшота, а вторым видом ссылок на «снапшот». Когда происходит откат диска, то снапшот клонируется (не копируется — отсюда и нюансы с COW), ссылаясь на тот же самый base copy, на который ссылался снапшот, который был клонирован.

Если же кто-то два-три раза подряд сделает снапшот (без изменений данных), то получится одна base copy и три снапшота с мета-данными.

Когда снапшот удаляется (из середины), то происходит следующее: сам снапшот (метаданные) удаляется сразу, а вот base copy начинает расформировываться — данные переносятся либо в «предыдущее» состояние, либо в «будущее», либо вообще выкидываются (если есть альтернативное состояние и в прошлом, и в будущем). Этот процесс и есть «таяние» снапшота, которое происходит не мгновенно. Нужно сказать, что данные фактически не копируются, а всего лишь «перемаркируются» в рамках LVM (LE перекидываются между разными LV), либо удаляются (если в предыдущей копии есть другая версия блока).

Немного о thin provision

Один из вопросов, который нам задают по СХД, связан с thin provision. Что такое thin provision? Это когда потребителю декларируется некоторый объём места, а реально занятое место меньше — и увеличивается по мере фактической записи. Это отлично ложится на нашу модель с снапшотами, COW из «пустого места», да и в XCP реализовано отлично. Фактически, thin provision — это «запись в снапшот», то есть запись в «пустое место», которое от этого начинает занимать место в реальности.

Однако, thin provision опасен. Обратная сторона thin provision — overselling (он же oversubscription). Грубо говоря, есть у нас 100Тб места. Мы разрешили создать на таком хранилище 200 дисков по 1Тб. Фактический размер дисков в начале — гигабайт по 30-50, так что свободного места вволю. Но, вдруг, клиенты начинают писать на диски. Диски-то им уже выделены. Проходит немного времени, и… да, среднее заполнение дисков подползает к 500Гб. А потом… Потом кто-то хочет записать очередной гигабайт, но получает ошибку. Потому что место закончилось.

Мы не властны над дисками клиентов, и если мы им предоставили ресурсы — эти ресурсы их, и не наше дело говорить «сейчас можно, а сейчас нет». Если в отношении других ресурсов может быть компромисс (кому-то 3% процессора не дали, кого-то мигрировали на другой хост, чтобы обеспечить запас производительности), то есть незначительная «недопоставка» просто не ощутима, то в отношении дискового пространства такое не получится. Не дали записать хотя бы один сектор — по всему блочному устройству фиксируется ошибка.

Так что по здравому размышлению мы решили так не делать.

Из-за того, что снапшоты делаются в R/O, а после создания только уменьшаются, мы можем отказать в создании нового снапшота (всякое бывает — может и место внезапно кончиться), но мы точно не откажем в работе уже созданных дисков и снапшотов.

Источник

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. Одна копия должна храниться отдельно от двух других, в другом здании.

Источник