Snapshot что за программа

Backup или Snapshot?

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

• Сбой программного обеспечения.
• Выход из строя оборудования.
• Человеческий фактор.
• Действие злоумышленников, вирусы, шифровальщики.
• Пренебрежение резервным копированием, ошибки при организации безнес-процессов.
• Форс-мажор. Пожары, наводнения, стихийные бедствия.
• Нашествие инопланетян, война, рейдерский захват, политические баталии, действия правоохранительных органов.
• Статическое электричество, космическая радиация.

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

Что такое ссылка Snapshot (Снапшот)

Так что среди системных администраторов есть две основные группы: те кто не делает резервные копии и те кто уже делает. Есть ещё третья подгруппа: те, кто проверяет, что резервная копия восстанавливается, но это уже отклонение от нашей темы.

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

Backup

Backup (бэкап) — автономная копия данных системы, которая может храниться на отдельных носителях, в том числе геораспределённых.

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

Бэкап рекомендуется хранить на геораспределённом носителе, чтобы обеспечить возможность восстановления данных в случае выхода из строя ЦОД. Если канал передачи данных медленный, то рекомендуется хранить дополнительный бэкап рядом с основной системой, это позволит быстрее восстановить данные в случае сбоя.

Работоспособность бэкапа следует периодически проверять.

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

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

Snapshot

Snapshot (снапшот) — мгновенный снимок состояния и данных системы.

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

Что такое Snapshots и как ими пользоваться?

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

• Делается моментально, быстро восстанавливается.
• Маленький размер (при небольшом сроке хранения). Содержит только изменения между состояниями системы.
• Не передаёт данные по сети.
• Не требует отдельной машины для хранения резервных копий, что удобно при разработке.
• Сохраняет состояние системы, в том числе оперативной памяти.

• Несколько снапшотов могут сказываться на производительности системы, поэтому много снапшотов не сделаешь.
• Не является полноценной резервной копией. В случае выхода из строя гипервизора или хранилища не сможет восстановить виртуальную машину.
• Увеличивается в размере при интенсивном изменении данных.
• Хранится на том же сервере, требуя места.
• Недоступно на аппаратных платформах, работает только в среде виртуализации.
• Не подходит для долговременного хранения. Рекомендуется не использовать снапшоты дольше 72 часов.
• Не подходит для создания копии системы.
• При изменении характеристик виртуальной машины снапшоты могут быть скомпрометированы.

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

Резюме

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

Используйте бэкапы для хранения полноценных резервных копий на геораспределённых хранилищах, а также для создания клонов исходной системы.

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

Кроме бэкапа и снапшота есть и другие инструменты для предотвращения потери данных:

• Репликация.
• Зеркалирование.
• Теневые копии.
• Обновление ПО, шифрование, информационная безопасность, антивирусы, распределение прав доступа.
• Профилактика оборудования.

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

Если вам понравилась статья, то ставьте каналу.

Пишите комментарии, задавайте вопросы, подписывайтесь.

Источник: dzen.ru

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, а изнутри, анонимными голосами самих работников. «Пустячок, а приятно».

Источник: habr.com