Что такое снапшот базы данных
Как правильно работать со снапшотами виртуальных машин
«Snapshot» в переводе с английского означает «выстрел» или «мгновенный фотоснимок». Снапшот — это своего рода фотоснимок виртуальной машины (ВМ), слепок её конкретного состояния. Виртуальная машина может использоваться для различного рода экспериментов, или в нее могут вноситься изменения, которые затем нужно быстро откатить назад. Именно для того, чтобы каждый раз не мучиться восстановлением предыдущего состояния ВМ и существуют снапшоты, возвращающие ВМ к исходному состоянию. Снапшоты — не такая уж простая операция, во всяком случае, делаться она должна по правилам, о которых мы сегодня и расскажем.
Что такое снапшот?
Снапшот сохраняет состояние виртуальной машины и данные по ней в определенный момент времени.
Лучшие практики
Чтобы получить максимальную пользу от снапшотов, необходимо следовать нескольким правилам, которые позволят использовать снапшоты по максимуму и предотратить возникновение проблем.
Используйте отдельные инструменты для резервного копирования. Делайте снапшот, вносите изменения в виртуальную машину и удаляйте снапшот, как только будет подтверждено ее корректное состояние.
2) Снапшоты образуют цепочки или деревья.
VMware советует делать в одной цепочке только 2–3 снапшота:
a. Большее число снапшотов или снапшоты большого размера могут вызвать уменьшение производительности виртуальной машины и хоста.
b. Создание большого файла снапшота может заполнить доступное пространство хранилища, отключив таким обазом все виртуальные машины до тех пор, пока не будут внесены коррективы. Другими словами, снапшот на каждом отдельно взятом хосте может оказывать влияние на все виртуальные машины, использующее данное устройство хранения.
c. Файл снапшота может оказаться поврежденным.
d. Размер диска снапшотов оказывает непосредственное влияние на продолжительность времени, которое потребуется на удаление снапшота, относящегося к данной виртуальной машине.
Деревья снапшотов на Windows и Linux
3) Не делайте снапшотов памяти виртуальной машины:
a. Продолжительность времени, которое занимает у ESX хоста запись памяти на диск, коррелирует с объемом памяти, на использование которого настроена виртуальная машина. Это может увеличить время на завершение операции, что в свою очередь может замедлить производительность виртуальной машины.
b. Если нет острой потребности в возвращении виртуальной машины к конкретному состоянию памяти, отключите опцию «Память». Состояние памяти редко может потребоваться.
4) Используйте более одного снапшота для промежутка времени в 24–72 часа.
Хотя 2–3 дня — это рекомендуемый период, иногда снапшот хранится 5 дней, а затем автоматически удаляется:
a. Это предотвращает снапшоты от разрастания до такого большого размера, который может вызвать проблемы при удалении его с диска виртуальной машины.
b. Сделайте снапшот и удалите его сразу после того, как внесете необходимые коррективы.
c. Будьте аккуратны со снапшотами высокозагруженных виртуальных машин, таких как серверы баз данных и почтовые серверы. Такие снапшоты могут быстро увеличиваться в размерах, заполняя пространство хранилища. Удаляйте снапшоты с виртуальных машин, как только они перестают быть необходимыми.
5) Виртуальные машины с несколькими дисками:
a. Снапшот может повлиять на дочерний или резервный диск: чем больше операций совершается с диском, тем больше он становится.
b. Требования к свободному пространству дочернего диска дополняют требования к родительскому диску, от которого он зависит.
c. Дочерний диск может вырасти до такого размера, что заполнит все пространство для хранения.
d. Существует правило «Без снапшотов» для дополнительных дисков размером 100 Гб и больше, поскольку есть вероятность заполнения хранилища данных и прекращения работы всех виртуальных машин, которые используют одно и то же хранилище.
e. Дополнительные диски более 100 Гб размером считаются независимыми — это предотвращает переход влияние снапшота с родительского диска на дочерний.
Вместо заключения
Снапшот позволяет запечатлеть состояние виртуальной машины в конкретный момент времени. Снапшоты полезны в том случае, если требуется вернуться к одному состоянию виртуальной машин без необходимости создавать новые.
Снапшот несет следующую информацию:
Snapshot и Backup: в чем разница?
Рано или поздно все мы сталкиваемся с таким неприятным явлением, как потеря данных. Причины могут быть разными — от выхода из строя оборудования до сбоя программного обеспечения. Последствия потери данных могут быть тоже самыми разными — от потери времени до потери огромных средств. Для предотвращения потерь данных платформа xelent.cloud предоставляет два инструмента: Snapshot и Backup. В этой статье мы разберемся, в чем между ними разница.
Резервное копирование
Инструмент резервного копирования (backup) в своей классической интерпретации известен всем. Администратор может настроить резервное копирование файлов, папок, всей операционной системы и даже целых дисковых томов (поблочно).
В случае необходимости из созданной резервной копии можно восстановить данные, операционную систему или даже весь диск.
Цели резервного копирования могут быть самыми разными, например, простое архивирование данных на случай их использования в будущем, создание бэкапа для восстановления данных в случае их повреждения или утери, для восстановления операционной системы и приложений.
Нужно понимать, что данные постоянно меняются и созданная резервная копия устаревает сразу же после ее создания. Скажем так, пусть в 7:00:00 вы инициировали создание резервной копии и в 7:30:00 она была создана. Если вы в 7:30:01 инициируете восстановление данных, то есть огромная вероятность, что система после восстановления в 8:00:00 все равно не будет такой, какой она была в 7:30:00 — на момент создания резервной копии. В некоторых случаях это не важно, поскольку нужно восстановить только содержимое файлов данных. В некоторых случаях — очень важно, поскольку будут потеряны все данные с момента создания резервной копии. Все просто: пусть вы создали резервную копию файла в 7:00, а в 17:00 случайно удалил этот файл. Вы можете его восстановить, но только по состоянию на 7:00 — все изменения за 10 часов работы будут утеряны.
Делать резервное копирование слишком часто — тоже не выход, поскольку создание резервной копии требует вычислительной мощности, занимает дисковое пространство и забивает сетевой канал (нет смысла делать локальную резервную копию, бэкап нужно хранить на другой машине, поэтому при создании бэкапа генерируется сетевой трафик).
Резервное копирование может быть полным и инкрементным. Инкрементное используется для экономии ресурсов. При инкрементном резервном копировании копируются не все данные, а только измененные. Восстановить оригинал при использовании инкрементного копирования возможно только при наличии всей цепочки копий.
При полном резервном копировании сохраняются все данные, но при этом требуется больше дискового пространства для хранения бэкапа и времени — на его создание.
Платформа xelent.cloud предоставляет возможность резервного копирования. Для включения бэкапа нужно перейти в раздел Backup панели управления виртуальным сервером и нажать кнопку Включить. После включения резервного копирования каждый день будет создаваться полная резервная копия всех данных сервера. Резервное копирование выполняется 1 раз в сутки на территориально удаленный дисковый массив.
Рис. 1. Включение резервного копирования виртуального сервера
MVCC-4. Снимки данных
Рассмотрев вопросы, связанные с изоляцией, и сделав отступление об организации данных на низком уровне, мы в прошлый раз подробно поговорили о версиях строк и проследили, как изменяется служебная информация в заголовке версии при различных операциях.
Сегодня мы посмотрим на то, как из версий строк получаются согласованные снимки данных.
Что такое снимок данных
Физически в страницах данных могут находиться несколько версий одной и той же строки. При этом каждая транзакция должна видеть только одну (или ни одной) версию каждой строки так, чтобы вместе они составляли согласованную в ACID-смысле картину данных на определенный момент времени.
Изоляция в PostgreSQL строится на основе снимков данных (snapshot): каждая транзакция работает со своим снимком данных, который «содержит» данные, которые были зафиксированы до момента создания снимка, и не «содержит» еще не зафиксированные на этот момент данные. Мы уже видели, что изоляция при этом получается более строгая, чем требует стандарт, но не лишенная аномалий.
На уровне изоляции Read Committed снимок создается в начале каждого оператора транзакции. Такой снимок активен, пока выполняется оператор. На рисунке момент создания снимка (который, как мы помним, определяется номером транзакции) показан синим цветом.
На уровнях Repeatable Read и Serializable снимок создается один раз в начале первого оператора транзакции. Такой снимок остается активным до самого конца транзакции.
Видимость версий строк в снимке
Правила видимости
Конечно, снимок не является физической копией всех необходимых версий строк. Фактически снимок задается несколькими числами, а видимость версий строк в снимке определяется правилами.
Будет или нет данная версия строки видна в снимке, зависит от двух полей ее заголовка — xmin и xmax, — то есть от номеров создавшей и удалившей транзакций. Такие интервалы не пересекаются, поэтому одна строка представлена в любом снимке максимум одной своей версией.
Точные правила видимости довольно сложны и учитывают множество различных ситуаций и крайних случаев.
В этом легко убедиться, заглянув в src/backend/utils/time/tqual.c (в версии 12 проверка переехала в src/backend/access/heap/heapam_visibility.c).
Упрощая, можно сказать, что версия строки видна, когда в снимке видны изменения, сделанные транзакцией xmin, и не видны изменения, сделанные транзакцией xmax (иными словами, уже видно, что версия строки появилась, но еще не видно, что ее удалили).
В свою очередь, изменения транзакции видны в снимке, если либо это та же самая транзакция, что создала снимок (она сама видит свои собственные изменения), либо транзакция была зафиксирована до момента создания снимка.
Можно изобразить транзакции графически в виде отрезков (от момента начала до момента фиксации):
Все, что мы можем — это узнать текущий статус транзакций при создании снимка. Эта информация есть в общей памяти сервера в структуре ProcArray, которая содержит список всех активных сеансов и их транзакций.
А постфактум мы уже не сможем понять, была ли какая-то транзакция активна в момент создания снимка или нет. Поэтому список всех текущих активных транзакций приходится запоминать в снимке.
Из сказанного следует, что в PostgreSQL нельзя создать снимок, показывающий согласованные данные по состоянию на произвольное время назад, даже если все необходимые для этого версии строк существуют в табличных страницах. Часто приходится слышать вопрос, почему в PostgreSQL нет ретроспективных (или темпоральных; в Oracle это называется flashback query) запросов — вот одна из причин.
Забавно, что изначально такая функциональность была, но позже ее убрали из СУБД. Про это можно прочитать в статье Джозефа Хеллерштейна.
Итак, снимок данных определяется несколькими параметрами:
Также в снимке сохраняются еще несколько параметров, но они для нас не важны.
Пример
Чтобы посмотреть, как видимость определяется снимком, воспроизведем ситуацию с тремя транзакциями, рассмотренную выше. В таблице будут три строки, причем:
Первая транзакция (еще не завершилась):
Вторая транзакция (завершилась до создания снимка):
Создаем снимок в транзакции в другом сеансе.
Завершаем первую транзакцию после того, как создан снимок:
И третья транзакция (появилась позже создания снимка):
Очевидно, что в нашем снимке по-прежнему видна одна строка:
Вопрос в том, как это понимает PostgreSQL.
Все определяется снимком. Посмотрим на него:
создать моментальный снимок базы данных (Transact-SQL)
Единственный способ создания моментального снимка базы данных SQL Server состоит в использовании Transact-SQL. SQL Server Management Studio не поддерживает создание моментальных снимков базы данных.
Перед началом
Предварительные требования
База данных-источник, в которой может применяться любая модель восстановления, должна соответствовать следующим предварительным требованиям.
База данных-источник должна быть в режиме в сети, если база данных не является зеркальной в сеансе зеркального отображения базы данных.
Для создания снимка базы данных в зеркальной базе данных необходимо привести эту базу данных в синхронизированное состояние зеркального отображения.
База данных-источник не может быть настроена в качестве масштабируемой общей базы данных.
Сведения о других существенных соображениях см. в разделе Моментальные снимки базы данных (SQL Server).
Рекомендации
В этом разделе обсуждаются следующие рекомендации:
Рекомендации. Присвоение имен моментальным снимкам базы данных
Перед созданием моментальных снимков важно присвоить им правильные имена. Имя каждого моментального снимка базы данных должно быть уникальным в пределах базы данных. Чтобы упростить управление, моментальному снимку следует присвоить имя, которое позволяет определить базу данных, например:
Определяет имя исходной базы данных.
признак того, что новое имя предназначено для моментального снимка;
дату и время создания моментального снимка, порядковый номер или другие сведения, например время в течение дня, которые позволяют отличить моментальные снимки этой базы данных друг от друга.
Если время создания моментального снимка изменяется, можно использовать менее точные обозначения, например:
Рекомендации. Ограничение количества моментальных снимков базы данных
Благодаря созданию моментальных снимков через определенные промежутки времени формируется последовательность снимков базы данных-источника. Каждый моментальный снимок существует до тех пор, пока явно не удаляется. Поскольку каждый моментальный снимок будет продолжать расти по мере обновления первоначальных страниц, возможно, потребуется освободить место на диске для новых снимков за счет удаления старых.
Примечание. Чтобы восстановить моментальный снимок базы данных, необходимо удалить все другие снимки из базы данных.
Рекомендации. Клиентские соединения с моментальным снимком базы данных
Чтобы подключиться к моментальному снимку базы данных, клиенты должны знать, где его найти. Пользователи могут работать с одним моментальным снимком базы данных во время создания или удаления другого. Тем не менее при замене существующего снимка новым необходимо перенаправить клиентов на новый снимок. Пользователи могут вручную подключиться к моментальному снимку базы данных средствами среды SQL Server Management Studio. Тем не менее в рабочей среде следует создать программное решение, которое неявным для клиента образом направляет приложения, формирующие отчеты, к последнему моментальному снимку базы данных.
Permissions
Как создать моментальный снимок базы данных (с использованием языка Transact-SQL)
Создание моментального снимка базы данных
Пример этой процедуры см. в подразделе Примеры (Transact-SQL)далее в этом разделе.
На основании текущего размера базы данных-источника убедитесь, что на диске достаточно места для хранения моментального снимка базы данных. При создании моментального снимка максимальный размер моментального снимка базы данных равен размеру базы данных-источника. Дополнительные сведения см. в разделе Просмотр размера разреженного файла снимка базы данных (Transact-SQL).
Используйте инструкцию CREATE DATABASE для файлов с помощью предложения AS SNAPSHOT OF. Создание моментального снимка требует указания логического имени каждого файла базы данных-источника. Синтаксис:
CREATE DATABASE имя_снимка_базы_данных
AS SNAPSHOT OF source_database_name
Здесь *имя_*исходной_базы_данных — это исходная база данных, логическое_имя_файла — это логическое имя, используемое в SQL Server при ссылке на файл, имя_файла_ОС — это путь и имя файла, используемые операционной системой при создании файла, а имя_снимка_базы данных — это имя снимка, на основе которого требуется восстановить базу данных. Полное описание этого синтаксиса см. в разделе CREATE DATABASE (SQL Server Transact-SQL).
При создании моментального снимка базы данных файлы журнала файлы в режиме вне сети, восстанавливаемые из копии файлы и нефункционирующие файлы являются недопустимыми в инструкции CREATE DATABASE.
Примеры (Transact-SQL)
Этот раздел содержит следующие примеры.
A. Создание моментального снимка по базе данных AdventureWorks
Б. Создание моментального снимка по базе данных Sales
В чем разница между Backup и Snapshot
Что такое Backup
Backup (бэкап) – это резервная копия данных. Она нужна, чтобы данные можно было восстановить, если они повреждены из-за физической поломки дисков, где они хранятся, атаки вируса-шифровальщика, человеческой ошибки и так далее. Главная цель бэкапов – сохранность данных.
Чтобы сделать бэкап, достаточно перенести файлы на новый носитель. Например, разместить фотоотчет с выпускного в облаке или скопировать его на флешку. Можно сделать резервную копию любых данных: файлов (тех же фото), ключей доступа, содержимого сайта, базы данных, исходного кода приложения.
Бэкапы появились десятки лет назад, тогда копии данных хранили на дисках, магнитных лентах и других физических носителях. Сегодня копии можно хранить и в облаке. Облачное хранение позволяет вернуть данные, даже если там, где установлены серверы и хранятся бэкапы, случится пожар, который уничтожит все носители информации.
Существует несколько видов резервного копирования.
Полный бэкап. Во время создания полного бэкапа сохраняются все данные без исключения. Когда старые бэкапы теряют актуальность, они удаляются, чтобы освободить место.
Такой бэкап занимает столько же места, сколько и оригинальные файлы. Это не страшно, если нужен дубликат исходников небольшого приложения – понадобится лишь несколько гигабайт. Но если необходимо сделать резервную копию всех данных какого-нибудь сервера, понадобится столько же места, сколько занимают эти данные: это еще один сервер с диском такого же размера либо столько же места в облачном хранилище.
Инкрементный и разностный бэкапы. Проблема с занимаемым местом и временем копирования решается с помощью разностного (дифференциального) и инкрементного бэкапов. В обоих случаях сначала создается полный бэкап, а затем производятся бэкапы тех данных, которые были изменены. При этом:
Чем отличаются разностный и инкрементный бэкапы
Недостаток обоих методов − в том, что восстановить информацию невозможно, если повредится первоначальный полный бэкап либо – в случае инкрементного – какой-то фрагмент цепочки. Поэтому чаще всего находят компромисс между полным и частичным бэкапированием. Например, ежемесячно создается полная копия данных, а каждую неделю – инкрементный бэкап.
Что такое Snapshot
Snapshot (снепшот) – это «заморозка» не только данных, но и всего состояния системы. Снепшот также называют моментальным снимком (от английского snapshot – снимок). Главная идея снепшотов − возможность в любой момент легко откатиться к более старому состоянию. Удобнее всего оказалось использовать снепшоты при работе с виртуальными машинами – многие среды виртуализации поддерживают их создание и возвращение к старым снимкам за пару простых действий.
С помощью снепшотов можно смело делать вещи, которые могут «испортить» компьютер или приложения на нем – например, ставить обновления критичных для бизнеса приложений и тестировать их работу. При любых неприятностях можно просто вернуться в определенную точку в прошлом. Это оказалось особенно ценно для разработки и тестирования.
Исходные данные «замораживаются» в виде файла или набора файлов, которые запрещено изменять. Все новые операции записываются в отдельные файлы. В этом отношении снепшот похож на инкрементальные бэкапы, так же можно создавать цепочки (последовательности) или деревья снимков – множество снепшотов системы на определенных этапах, что позволяет обратиться к нужной версии.
Дерево снепшотов. Можно вернуться к любой точке во времени, когда был снят снепшот
Но файлы снепшотов обычно хранятся рядом с «замороженными» исходными данными для быстроты доступа. Поэтому, в отличие от бэкапа, снепшот не требует отдельного хранилища.
Можно сделать как моментальный снимок системы целиком, так и каких-то отдельных данных. Моментальный снимок удастся сделать и с выключенным компьютером – у бэкапа такой возможности нет.
Когда используют бэкап
Создание бэкапа (резервное копирование) позволяет сохранить данные на длительный срок, чтобы их можно было восстановить в случае сбоя, повреждения или утраты носителя.
Лучше всего бэкап подходит в следующих ситуациях:
Когда лучше использовать снепшот
Смысл снепшотов − не в надежности, а в быстром и удобном восстановлении состояния системы. Если бэкапы надо хранить подальше от основной системы, чтобы не складывать все яйца в одну корзину, то есть – застраховаться от физического уничтожения системы вместе с бэкапами, то данные снепшота должны быть как можно ближе, чтобы сама передача данных не затягивала восстановление.
Использовать снепшот можно, чтобы потестировать приложения, обновления, патчи, обезопасить данные, если есть вероятность их повреждения.
Бэкапы и снепшоты работают вместе
Бэкапы и снепшоты − для разного: одни для надежности, другие для гибкости. Но когда нужно и то, и другое, они работают вместе.
Например, полное бэкапирование занимает много времени, это мешает сделать точную копию. В бэкапе может оказаться копия данных, отличная от оригинала, так что его нельзя будет восстановить из бэкапа. Представьте себе три папки: «Кошки», «Еноты» и «Ежи». Кошки уже скопировались в бэкап, сейчас копируются еноты. Если в этот момент взять ежа #8 и из «Ежей» перенести в «Кошек», система создания бэкапов этого не заметит. Когда она дойдет до «Ежей», #8 не попадет в бэкап− копия не будет содержать его ни в «Ежах», ни в «Кошках».
Конечно, на время создания копии можно переключить данные в режим «только для чтения», но в этот момент придется заблокировать работу с данными для всех приложений. Это подходит для домашнего компьютера, но не подходит для систем, которые должны быстро отвечать на запросы. В этом случае сначала создается снепшот системы − а это гораздо быстрее бэкапа. Потом системе разрешают меняться дальше, а бэкап создается уже с файла со снепшотом. Когда бэкап готов, к снепшоту применяются все дальнейшие изменения, после этого он удаляется.
Резюме
Бэкапы − для надежности хранения данных и возможности их восстановления или «клонирования» на другие компьютеры.
Снепшоты − для быстрого и удобного возвращения системы в прошлое состояние. Это помогает проводить «опасные» эксперименты.