Снэпшоты это: моментальный снимок облачного сервера 1cloud.ru — Главная

Содержание

Моментальный снимок | Snapshot

Главная » База знаний » Моментальный снимок | Snapshot

Дата публикации: 1 июня 2020 г.

Содержание:

Плюсы и минусы Snapshot (-ов)
Создание моментальных снимков
Snapshot Windows
Snapshot Linux
Snapshot VMware

* * *

Моментальный снимок (Snapshot) – это копия диска (тома/раздела) на уровне блоков физических или виртуальных систем, выполненная без остановки системных служб, включает в себя структуру папок, файлов и информацию о состоянии системы на фиксированный момент времени. Snapshot не является резервной копией, применяется/используется как временный источник для создания согласованных резервных копий. Snapshots применяют в резервном копировании баз данных или файловых систем большого объема, работающих в непрерывном режиме 24 на 7.

Плюсы /преимущества моментальных снимков (snapshots)

Высокая производительность
Минимальное влияние на доступность данных и производительность
Позволяет выполнить полное восстановление системы

Минусы / недостатки моментальных снимков (snapshots)

Не является полноценной резервной копией
Ограничен для создания согласованных снимков некоторых приложений и баз данных
Большое количество моментальных снимков замедляет работу системы
Необходимость выделения места на диске для временного хранения Snapshot Snapshots (-ов)

* * *

СОЗДАНИЕ МОМЕНТАЛЬНЫХ СНИМКОВ (CREATE SNAPSHOT)

В зависимости от источника хранения данных (файловая система, менеджер дисков/томов или дисковый массив) для создания моментальных снимков применяют алгоритмы «Копирования при записи» (Copy-on-write) или «Перенаправления при записи» (Redirect-on-write), другое название «Зеркальный снимок».

Процесс создания моментальных снимков файловой системы состоит из следующих этапов:

Сбор метаданных и подготовка к созданию теневой копии (завершение транзакции и очистка кэша)
Временная остановка (заморозка) запросов на запись операций ввода-вывода в файловую систему. Перевод в состояние только чтение.
Создание и запись теневой копии в хранилище
1. На том же томе для Copy-on-write
2. На другом томе для Redirect-on-write
Возобновление (разморозка) запросов на запись операций ввода-вывода в файловую систему (возобновление записи приложениями данных на жесткий диск).

В процессе создания снапшота важную роль играет поставщик моментальных снимков (Snapshots Provider). В зависимости от инициатора, поставщиков делят на Hardware и Software Provider.

* * *

SNAPSHOT PROVIDER

Hardware Provider это утилита в составе системы хранения данных, которая выступает инициатором создания снимка от имени поставщик оборудования. Каждый поставщик систем хранения данных имеет свой уникальный Hardware Provider (NetApp Data ONTAP, HPE RMC, EMC Unisphere и др.). Hardware Provide является посредником между службой теневого копирования томов (VSS) и «железом», работая в связке с сетевым адаптером и контроллером хранения данных. Таким образом, нагрузка по созданию и поддержке теневой копии лежит на системе хранения данных.

В случаи программного снимка (Software Provider) программа-инициатор на системном уровне перехватывает запросы чтения / записи для операций ввода / вывода между файловой системой и менеджером томов.

Так как Software Provider создают теневые копии на уровне операционной системы, это является более универсальным методом в отличие от Hardware Provider.

* * *

SNAPSHOT WINDOWS

Snapshot в системах резервного копирования

Veritas Backup Exec

Commvault

Acronis

В Windows роль Software Provider, выполняет встроенная служба теневого копирования VSS (Volume Shadow Copy Service). VSS по умолчанию встроена в систему Windows и отвечает за создание моментальных снимков на уровне файловой системы NTFS, применяя метод «Копирования при записи» (Copy-on-write). VSS используется, как для физических систем, так и для виртуальных машин Hyper-V, включая файлы конфигурации виртуальных машин, состояние системы (system snapshot) и виртуальные жесткие диски (VHD). Как правило, большинство программ/систем резервного копирования используют службу VSS для создания своих резервных копий в Windows.

* * *

SNAPSHOT LINUX

В Linux системах роль Software Provider и поставщика моментальных снимков в зависимости от типа файловой системы (EXT, JFS, ReiserFS, XFS, Btrfs), как правило, выполняет служба Logical Volume Manager (LVM) или специальные модули ядра Linux (Samba и др.).

* * *

SNAPSHOT VMWARE

В VMware в качестве Software Provider моментальных снимков виртуальных машин отвечает диспетчер снимков (VMware Snapshot Provider).

Моментальный снимок включает в себя информацию о состояние виртуальной машины, а так же все данные, хранящиеся на диске, в оперативной памяти и виртуальных устройствах. Для создания Snapshots в VMware применяется метод «Перенаправления при записи» (Redirect-on-write).
Моментальный снимок состоит из исходного виртуального диска *.vmdk и журнала изменений *delta.vmdk (*sesparse.vmdk, если объем виртуального диска более 2 Тб), а так же служебных файлов *.vmsd и *.vmsn.

Термины и определения

Дедупликация данных

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

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

Аварийное восстановление (disaster recovery)

Моментальный снимок | Snapshot

E-MAIL

[email protected]

ТЕЛЕФОН:

+7 (495) 775-72-94

Снапшоты в VMware vSphere и все о них

Обновлено 13.05.2020

Всем привет сегодня хочу затронуть вопрос снапшотов (snapshots) в VMware vSphere. Поговорим, что это такое, из чего состоит, плохо это или хорошо и где применяется. Думаю это актуальный вопрос и многие хотели бы в нем разобраться, да и я освежу это в памяти, и что то может переосмыслить.

Что такое snapshot

Снапшот (Snapshot — снимок) — это сохранение состояния виртуальной машины в определенной точке, необходимой именно вам, его еще называют снимком виртуальной машины. Еще можно дать вот такое определение: Snapshot VMware — это копия файла диска виртуальной машины (VMDK) в определенный момент времени. Снимки предоставляют журнал изменений для виртуального диска и используются для восстановления виртуальной машины в определенный момент времени, когда происходит сбой или системная ошибка. Снимки сами по себе не обеспечивают резервное копирование, если проще SNAPSHOT это НЕ БЭКАП.

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

Где применим снапшот

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

Как создать снапшот в VMware vSphere

Сама процедура очень простая и сейчас будет описана. Если же вы захотите ее автоматизировать, то советую почитать Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5. 5.

сразу подчеркиваю shapshot это не замена бэкапа, запомните это

Выбираете любую виртуальную машину, щелкаете по ней правым кликом и из контекстного меню выбираете Snapshot > Take Snapshot

В следующем окне задаем имя snapshot и при желании описание в поле description. Обратите внимание на две возможные галки

В ESXI 6.5 и выше, создание снимка виртуальной машины делается подобным образом, но уже из веб-интерфейса. Вы так же выбираете нужный сервер, вызываете его контекстное меню «Snaphots — Tale Snapshot«

Описание параметров снимка

Snapshot the virtual machine’s memory > данная опция нужна для того, чтобы во время снятия snapshot esxi виртуалки было состояние оперативной памяти, что при откате даст работающую виртуальную машину. Если вы ее снимите, то вернувшись из снапшота виртуальная машина будет выключена, но зато такой снапшот будет создаваться быстрее, так как нет необходимости сохранять оперативную память в файл, особенно если память большая и постоянно обновляется.
Quiesce guest file system (need VMware Tools installed) > Это процесс при котором подготавливаются данные на виртуальном диске в состояние требуемое для резервного копирования. Заморозить гостевую файловую систему (требуется установка VMware Tools и ее драйвер Sync Driver) позволяет гарантировать, что данные гостевой операционной системы останутся не поврежденными в снимке.

В итоге VMware Tools с помощью VMware Snapshot Provider запускает создание VSS snapshot внутри гостевой ОС. После чего все VSS writers (смотрим их командой «vssadmin list writers«) в гостевой ОС получают запрос и подготавливают соответствующие приложения к бэкапу (происходит запись всех транзакций из памяти на диск). Когда все VSS writers заканчивают работу, они сообщают службе VMware Tools через VMware Snapshot Provider, который, в свою очередь, говорит VMware о том, что снапшот можно снять.
Таким образом все приложения резервного копирования для VMware vSphere используют следующие комбинации при отдании команды на создание снапшота VMware (заметьте, что процесс непосредственно создания снапшота целиком и полностью контролируется самой VMware)

Если делать бэкап без опции Quiesce guest file system, то могут быть большие проблемы при восстановлении контроллера домена или Exchange сервера.

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

Тут есть две конструкции, которые вы можете использовать в PowerCLI. В первом примере, мы вызываем виртуальную машину «Terminal», а далее создаем там снапшот с именем «Untill Update».

Get-vm -name «Terminal» | New-Snapshot -Name «Untill Update»

Во втором примере, мы воспользовались командлетом New-Snapshot, и обратились к виртуальному серверу, где создали снапшот с именем «Untill Update«.

New-Snapshot -VM «Terminal» -Name «Untill Update»

Структура файлов виртуальной машины при снятии Snapshot

Вот как выглядит структура файлов до снятия снапшота в VMware vSphere. Более подробно о форматах esxi файлов читайте по ссылке.

Теперь посмотрим, что изменится после снятия снимка виртуальной машины esxi 5.5. Как видите добавились файлы с форматом vmsn и добавленным в название 000001. Это и есть жесткий диск новых данных после снапшота.

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

<name VM>-[шесть цифр]-delta.vmdk — файл данных диска отличий от базового диска
<name VM>-[шесть цифр].vmdk — заголовочный файл
<name VM>.vmsd — текстовый файл с параметрами снапшота (связи в дереве, SCSI-нода, время создания и т.п.)
<name VM>.vmsn — файл с сохраненной памятью виртуальной машины

Как можно предположить основной файл это delta, который включает в себя все отличительные данные после снапшота от основного виртуального диска. Данный виртуальный диск состоит из блоков данных хранимых в формате redo-логов (или просто дочерний диск — child disk). Он же sparse-диск, то есть диск, который использует технологию Copy-On-Write (COW) при работе с данными. Идея технологии copy-on-write — при копировании областей данных создавать реальную копию только когда ОС обращается к этим данным с целью записи. Таким образом, этот виртуальный диск содержит только измененные от родительского диска области данных (delta).

файл.vmsd. Это текстовый файл, открыв в редакторе вы увидите все отношения между родительским и дочерними дисками, а также другую интересную информацию

Хочу напомнить, что снапшоты лежат вместе с виртуальной машиной но их расположение можно поменять.

В гостевой ос

Что вы обнаружите например в событиях гостевой системы при создании снапшота без галки Snapshot the virtual machine’s memory и включенной на Quiesce guest file system. Вы в просмотре событий, в журнале Приложения обнаружите ошибку VSS с кодом 12289 (Ошибка теневого копирования тома: Непредвиденная ошибка DeviceIoControl). Можете на нее забить, так как она происходит из за флоппи диска в конфигурации виртуальной машины.

так же если посмотреть через клиента VMware vSphere датастор на котором лежит виртуалка то вы обнаружите файл архив vss_manifests*.zip с конфигами с описанием всех найденных VSS writers в гостевой ОС.

Содержимое vss_manifests*.zip.

если в архиве vss_manifests. zip только файл backup.xml — это означает, что снапшот по факту был сделан без использования VSS

Также стоит добавить некоторые требования к Quiesce guest file system

Поддержка Операционной системой консистентных снимков (VSS)
VSS компоненты VMware Tools установлены
Отсутствие динамических дисков внутри гостевой машины (Если внутри гостевой системы будет присутствовать хоть один динамический диск — не важно системный он или нет, то VSS задействован не будет. Снапшот будет создаваться успешно, но vss_manifests.zip будет пустым, как и логи событий внутри гостевой ОС. Это правило действует для гостевых ОСей Windows 2008 и выше)
Должна работать служба VSS в гостевой ОС

VSS- это сервис, который всего навсего перед бэкапом заставляет базу данных записать все транзакции на диск, далее БД приостанавливает свою работу, затем создаётся теневая копия тома, на что уходит несколько секунд, Далее БД продолжает свою работу в обычном режиме, а бэкап сливается уже с теневой копии. В VMWare теневая копия не создаётся, а создаётся delta vdmk, при этом исходный vdmk становится доступным на чтение и содержит консистентные данные, что позволяет его скопировать в качестве бэкапа.

Чем плохи снапшоты

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

Плюсы снапшотов

Возможность тестирования новых настроек или обновлений с возможностью легкого отката
Резервное копирование виртуальных машин на лету без остановки

Такие снапшоты делаются на небольшой промежуток времени, до суток. Протестировали и удалили.

Минусы снапшотов

snapshot быстро растут особенно при часто обновляемых данных. Растут они блоками по 16 мб. Если у вас например приложение СУБД, которое имеет много транзакций, то оно заполонит ваш датастор очень быстро, и может получиться так что на нем кончится место и виртуальная машина может перестать работать.
Еще большой проблемой являются длинные цепочки снапшотов, сделанных на разных этапах настройки, штук так по 15 или 20. Все это вызывает торможение виртуальной машины и хранилище отжирая лишние iops. Чем больше у вас цепочка тем дольше по ней идти до последнего снимка.

Так же когда снапшот делает или удаляется хранилище испытывает дополнительную нагрузку, так как на датастор сбрасывается память и снимок
Из за снапшотов вы не сможете использовать Fault Tolerance или Storage VMotion, так как привязаны к хранилищу с вашими snapshot.
Вы не сможете расширить виртуальный диск со снапшотом
Снимки виртуальных машин с дисками в режиме RDM или гостевыми операционными системами, использующими инициатор iSCSI в гостевой системе, не поддерживаются.
Снимки не поддерживаются устройствами ввода-вывода PCI vSphere Direct Path
Если виртуальная машина имеет виртуальные жесткие диски размером более 2 ТБ, выполнение снимка может занять значительно больше времени

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

Консолидация и удаление снапшотов / Удаление snapshot vmware

И так рассмотрим процедуру удаления снапшота. Выше мы узнали, что это снимки это зло, и вот еще почему. Не совсем понятное поведение снапшота при его удалении и слиянии с основным виртуальным диском vm машины. Для удаления и слияния вам потребуется свободное место на вашем дисковом массиве VMFS, это еще более актуально когда снимков несколько. Выше я привет снапшот как это может выглядеть. Предположим у вас виртуальная машина с тремя снимками вот таких вот размеров.

10 гб
20 гб
30 гб

Вы допустим хотите удалить все снапшоты и нажимаете «Delete All в Snapshot Manager», далее идет вот такая операция Snapshot 3 сливается со Snapshot 2, но при этом сам Snapshot 3 остается на томе VMFS

В итоге первого шага мы получаем уже 90 гб (60+30). Теперь Snapshot 2 который весит уже 50 гб сливается с Snapshot 1, при этом Snapshot 2 и 3 не удаляются пока. Из этого следует что у нас уже занято 140 гб на хранилище.

Как только результирующий Snaphot 1 в 60 гб сольется с основным виртуальным диском при этом сам виртуальный диск flat в размере не меняется, поскольку он фиксирован (изменяется только содержимое блоков). И только затем все снапшоты удаляются (все 140 ГБ).

так что видите запас нужно всегда иметь, минимум 10 процентов.

Консолидация snapshot vmware

И так consolidation или консолидация, это по сути удаление снапшота со слиянием дисков, чаще всего оставленного каким нибудь средством резервного копирования, например veeam. Процесс consolidation vm я уже описывал, там все просто, но не понятно на сколько это влияет на датастор в плане производительности.

Что влияет на время консолидации в виртуальной машине

Размер delta-дисков — очень важный параметр. Чем больше данных в дельта-диске, тем дольше их нужно применять к основному (базовому) диску.
Число снимков и их размеры. Чем их больше, тем все будет дольше идти по времени. Кроме того, при нескольких снапшотах консолидация происходит в несколько этапов, описано выше.
Производительность подсистемы хранения, включая FC-фабрику, Storage Processor хранилищ, LUN (число дисков в группе, тип RAID массива).
Тип данных в файлах снапшотов (нули или случайные данные).
Нагрузка на хост-сервер ESXi при создании снапшота.
Нагрузка виртуальной машины на подсистему хранения в процессе консолидации. Например, почтовый сервер, работающий на полную мощность, может очень долго находится в процессе консолидации снапшотов.

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

Замирание stun виртуальной машины в VMware vSphere

Если вы как и я долго уже работаете с гипервизором Vmware ESXI 5.5, то наверняка обращали внимание, что бывают случаи, что виртуальная машина подвисает на какое то время, или дико тормозит, а потом работает как ни в чем не бывало. За это в vmware отвечает параметр stun или как мы выше смотрели quiescence. Когда это происходит виртуалка не может ничего делать, она чаще всего падает по Ping и недоступна, и перестает отвечать на операции ввода/вывода. Если сказать по простому то ее как будто поставили на паузу, а на уровне ввода-вывода совершаются только операции, касающиеся выполняемой задачи (например, закрытие прежнего VMDK-диска и переключение операций чтения-записи на новый диск при операциях со снапшотами).

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

Когда может быть заметен stun виртуальной машины

Во время выполнения процедуры приостановки виртуальной машины (suspend). Тут происходит такое подмораживание, чтобы скинуть память VM на диск, после чего перевести ее в приостановленное состояние.
Ну как все уже поняли во время создания снапшота, нужно закрыть старый диск и начать писать в новый.
Консолидация (удаление) снапшота, подробно описано выше.
При выполнении миграции с помощью vMotion. Слегка напомню данный механизм, во первых оперативная память передается от одной машины к целевой VM без подмораживания, но затем происходит такой же stun, как и при операции suspend, с тем только отличием, что маленький остаток памяти (минимальная дельта) передается не на диск, а по сети. После этого происходит операция resume уже на целевом хосте. Пользователь этого переключения, как правило, не замечает, так как время этого переключения очень жестко контролируется и чаще всего не достигает 1 секунды. Если память гостевой ОС будет меняться очень быстро, то vMotion может затянуться именно во время этого переключения (нужно передать последнюю дельту).
Горячая миграция хранилищ Storage vMotion. Здесь stun случается дважды: сначала vSphere должна поставить Mirror Driver, который будет реплицировать в синхронном режиме операции ввода-вывода на целевое хранилище. При постановке этого драйвера происходит кратковременный stun (нужно также закрыть диски). Но и при переключении работы ВМ на второе хранилище происходит stun, так как нужно удалить mirror driver, а значит снова пере открыть диски уже на целевом хранилище.

Как правильно удалить Snapshot в ESXI

У вас существует несколько методов удаления снимков:

Через веб-интерфейс
Через PowerClI
Через команды esxi cli

Как исключить диски из снимка

Могут быть случаи, когда вы не хотите, чтобы диски виртуальной машины подвергались воздействию моментальных снимков. Для достижения этой цели, вам нужно изменить режим жесткого диска виртуальной машины из «Disk Mode» в «Independent – Persistent или Independent – Nonpersistent. Два варианта немного различаются в соответствии с объяснением VMware:

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

Думаю вы теперь чуть больше представляете, что такое снапшот и как и для чего он нужен. Материал сайта pyatilistnik.org

Моментальные снимки базы данных (SQL Server) — SQL Server

Статья
09/26/2022
Чтение занимает 12 мин

Применимо к: SQL Server (все поддерживаемые версии)

Моментальный снимок базы данных — это статическое представление базы данных SQL Server (база данных-источник). Моментальный снимок базы данных согласуется на уровне транзакций с базой данных-источником в момент создания моментального снимка. Моментальный снимок базы данных всегда находится на том же экземпляре сервера, что и база данных-источник. Моментальный снимок базы данных предоставляет представление данных только для чтения в состоянии на момент создания моментального снимка. Размер файла моментального снимка увеличивается по мере внесения изменений в базу данных-источник. Подробные сведения см. в разделе Общие сведения о функциях ниже.

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

Примечание

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

В этом разделе.

Общие сведения о функциях
Преимущества моментальных снимков баз данных
Термины и определения
Обязательные условия и ограничения для моментальных снимков базы данных
Связанные задачи

Общие сведения о функциях

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

Для хранения исходных страниц моментальный снимок использует один или более разреженных файлов. Изначально разреженный файл представляет собой пустой файл, который не содержит никаких пользовательских данных, и ему еще не выделено место на диске для пользовательских данных. По мере обновления страниц в базе данных-источнике размер файла увеличивается. На этом рисунке показано действие двух различных конфигураций обновления на размер моментального снимка. Конфигурация обновления А отражает условия, при которых в течение жизни моментального снимка обновляется только 30% всех исходных страниц. Конфигурация обновления Б отражает условия, при которых в течение жизни моментального снимка обновляется только 80% всех исходных страниц.

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

Моментальные снимки можно использовать для составления отчетов.
Клиент может запрашивать моментальный снимок базы данных, что может потребоваться для создания отчетов на основе данных, относящихся к моменту создания моментального снимка.
Поддержка хронологических данных для создания отчетов.
Моментальный снимок позволяет пользователю получить доступ к данным по состоянию на определенный момент времени. Например, моментальный снимок базы данных можно создать в конце определенного периода времени (например, финансового квартала) для последующего создания отчетов. Отчеты о каждом таком периоде будут создаваться на основе данных из моментального снимка. Если на диске достаточно свободного места, можно создавать такие моментальные снимки для каждого отчетного периода и разрешить запросы результатов по отчетным периодам, что может понадобиться, например для исследования эффективности деятельности организации.
Экономия ресурсов за счет доступности данных, необходимых для создания отчетов, в зеркальных базах данных.
Применение моментальных снимков с зеркальным отображением баз данных позволяет сделать данные на зеркальном сервере доступными для отчетов. Кроме того, выполнение запросов в зеркальной базе данных может освободить ресурсы основной базы данных. Дополнительные сведения см. в разделе «Зеркальное отображение базы данных» и «Моментальные снимки базы данных» (SQL Server).
Защита данных от административных ошибок.
При возникновении пользовательской ошибки в базе данных-источнике эту базу данных можно вернуть к состоянию, в котором она находилась на момент создания определенного моментального снимка базы данных. Потеря данных затронет только изменения в базе данных, произведенные после создания моментального снимка.
Перед серьезными обновлениями, такими как массовое обновление или изменение схемы, следует создать моментальный снимок базы данных для защиты данных. В случае ошибки можно будет восстановить базу данных путем возврата ее в предыдущее состояние с помощью моментального снимка. Потенциально процедура возврата занимает гораздо меньше времени, чем восстановление из резервной копии, но при этом она не поддерживает накат.

Важно!
Восстановление неприменимо к поврежденной базе данных и к базе данных, находящейся в режиме вне сети. Таким образом, создание регулярных резервных копий и тестирование плана восстановления необходимы для защиты базы данных.
Примечание
Моментальные снимки базы данных зависят от базы данных-источника. Следовательно, стратегию резервного копирования и восстановления не следует заменять восстановлением данных с помощью моментальных снимков базы данных. Плановое создание резервных копий остается основным действием. Если необходимо восстановить базу данных-источник на момент времени, в который был создан моментальный снимок базы данных, реализуйте политику резервного копирования, позволяющую это делать.
Защита данных от пользовательских ошибок.
Регулярное создание моментальных снимков базы данных может уменьшить ущерб от серьезных ошибок пользователей, например от удаления той или иной таблицы. Чтобы обеспечить высокий уровень защиты можно создать несколько моментальных снимков баз данных, охватывающих период времени, достаточный, чтобы распознать большинство пользовательских ошибок и устранить их последствия. Например, если достаточно свободного места на диске, то можно поддерживать от 6 до 12 моментальных снимков, охватывающих 24-часовой интервал. При создании следующего моментального снимка самый ранний будет удаляться.
- Для устранения ошибки пользователя можно с помощью моментального снимка вернуть базу данных в состояние непосредственно перед этой ошибкой. Потенциально процедура возврата занимает гораздо меньше времени, чем восстановление из резервной копии, но при этом она не поддерживает накат.
- Кроме того, удаленную таблицу или другие потерянные данные можно восстановить вручную по данным в моментальном снимке. Например, можно выполнить массовое копирование данных из моментального снимка в базу данных и вручную выполнить слияние данных в базе.
Примечание
От причины использования моментальных снимков зависит число параллельных снимков для одной базы данных, частота создания новых снимков и срок их хранения.
Управление тестовой базой данных.
При повторяющемся выполнении тестового протокола в базе данных тестовой среды полезно, чтобы база данных содержала одинаковые данные в начале каждого цикла тестирования. Перед выполнением первого цикла разработчик приложения или тестировщик может создать моментальный снимок тестовой базы данных. После каждого запуска тестирования базу данных можно быстро вернуть в предыдущее состояние путем возврата моментального снимка базы данных.

Термины и определения

database snapshot
Согласованное на уровне транзакций, доступное только для чтения статическое представление базы данных (базы данных-источника).

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

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

Обязательные условия и ограничения для моментальных снимков базы данных

В этом разделе.

Предварительные требования
Ограничения по базе данных-источнику
Ограничения по моментальным снимкам баз данных
Требования к месту на диске
Моментальные снимки базы данных с файловыми группами вне сети

Предварительные требования

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

Экземпляр сервера должен работать в выпуске SQL Server, поддерживающем моментальные снимки базы данных. Дополнительные сведения см. в разделе Функции, поддерживаемые различными выпусками SQL Server 2016.
База данных-источник должна быть в режиме в сети, если база данных не является зеркальной в сеансе зеркального отображения базы данных.
Моментальный снимок базы данных можно создать в любой базе данных-источнике или базе данных-получателе в группе доступности. Ролью реплики должна быть PRIMARY или SECONDARY, она не может находиться в состоянии RESOLVING.
Для создания моментального снимка рекомендуется, чтобы состояние синхронизации базы данных было SYNCHRONIZING или SYNCHRONIZED. Однако моментальные снимки базы данных могут создаваться и в состоянии синхронизации базы данных NOT SYNCHRONIZING.
Дополнительные сведения см. в статье Моментальные снимки баз данных для групп доступности AlwaysOn (SQL Server).
Для создания моментального снимка в зеркальной базе данных эта база данных должна быть в состоянии зеркального отображения SYNCHRONIZED.
База данных-источник не может быть настроена в качестве масштабируемой общей базы данных.
До выпуска SQL Server 2019 база данных-источник не могла содержать файловую группу MEMORY_OPTIMIZED_DATA. Поддержка моментальных снимков базы данных в памяти была добавлена в SQL Server 2019.

Примечание

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

Ограничения по базе данных-источнику

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

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

Ограничения по моментальным снимкам баз данных

Следующие ограничения применяются к моментальным снимкам базы данных.

Моментальный снимок базы данных должен создаваться и оставаться на том же экземпляре сервера, что и база данных-источник.
Моментальные снимки базы данных всегда применяются на всей базе данных.
Моментальные снимки базы данных связаны с базой данных-источником и не являются избыточным хранилищем данных. Они не защищают от ошибок диска или других видов повреждений. Следовательно, стратегию резервного копирования и восстановления не следует заменять восстановлением данных с помощью моментальных снимков базы данных. Плановое создание резервных копий остается основным действием. Если необходимо восстановить базу данных-источник на момент времени, в который был создан моментальный снимок базы данных, реализуйте политику резервного копирования, позволяющую это делать.
Если при обновлении страницы в базе данных-источнике и при записи этого обновления в моментальный снимок не хватает места на диске или возникает какая-либо иная ошибка, моментальный снимок становится подозрительным и должен быть удален.
Моментальные снимки доступны только для чтения. Так как они доступны только для чтения, они не могут быть обновлены. Таким образом, моментальные снимки базы данных не будут работоспособны после обновления.
Создание моментальных снимков баз данных model, masterи tempdb запрещено.
Нельзя изменять любые из характеристик файлов моментального снимка базы данных.
Нельзя удалять файлы из моментального снимка базы данных.
Нельзя выполнять резервное копирование или восстановление моментальных снимков базы данных.
Нельзя присоединять или отсоединять моментальные снимки базы данных.
Нельзя создавать моментальные снимки базы данных в файловой системе FAT32 или в необработанных секциях. Разреженные файлы, используемые моментальными снимками базы данных, предоставляются файловой системой NTFS.
Полнотекстовое индексирование не поддерживается на моментальных снимках базы данных. Полнотекстовые каталоги не распространяются из базы данных-источника.
Моментальный снимок базы данных наследует ограничения безопасности своей базы данных-источника на момент создания моментального снимка. Поскольку моментальные снимки обладают свойством «только для чтения», наследуемые разрешения не могут быть изменены, и изменения, совершенные в отношении источника, не будут отражены в существующих моментальных снимках.
Моментальный снимок всегда отражает состояние файловых групп на момент создания снимка: если файловая группа была в сети, она остается в сети, если же она была отключена, она остается вне сети. Дополнительные сведения см. в подразделе «Моментальные снимки базы данных с файловыми группами вне сети» далее в этом разделе.
Если база данных-источник становится RECOVERY_PENDING, ее моментальные снимки могут стать недоступными. Однако после решения проблемы в базе данных-источнике ее моментальные снимки должны вновь стать доступными.
Восстановление не поддерживается для всех сжатых файлов NTFS или NTFS, сжатых в базе данных. Попытки отмены изменений базы данных, содержащей один из этих типов файловых групп, завершатся неудачно.
В конфигурации доставки журналов моментальные снимки базы данных могут быть только созданы в базе данных-источнике, а не в базе данных-получателе. Если роли переключаются между экземплярами сервера-источника и сервера-получателя, необходимо удалить все моментальные снимки базы данных, перед тем как станет возможным настроить основную базы данных в качестве базы данных-получателя.
Моментальный снимок базы данных не может быть настроен в качестве масштабируемой общей базы данных.
В моментальных снимках базы данных не поддерживаются файловые группы FILESTREAM. Если в базе данных-источнике существуют файловые группы FILESTREAM, они помечаются как вне сети в ее моментальных снимках и их нельзя использовать для восстановления базы в исходное состояние.
Примечание
В инструкции SELECT, применяемой к моментальному снимку базы данных, нельзя указывать столбцы FILESTREAM; в противном случае будет возвращено следующее сообщение об ошибке: Could not continue scan with NOLOCK due to data movement.
Если статистика по моментальному снимку только для чтения отсутствует или устарела, ядро СУБД создает и сохраняет временную статистику в tempdb. Дополнительные сведения см. в статье Managing statistics on tables in SQL Data Warehouse (Управление статистикой таблиц в хранилище данных SQL).

Требования к месту на диске

Моментальные снимки базы данных занимают место на диске. Если для моментального снимка базы данных не хватает места на диске, он помечается как подозрительный и должен быть сброшен. (Однако на базу данных-источник влияния не оказывается; действия в ней продолжаются, как обычно.) В сравнении с полной копией базы данных моментальные снимки намного более эффективны в вопросе использования места на диске. Моментальный снимок требует лишь столько места, сколько необходимо для хранения страниц, изменяющихся в период его существования. В целом, моментальные снимки хранятся ограниченное время, поэтому их размер не является предметом первостепенной важности.

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

Примечание

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

Моментальные снимки базы данных с файловыми группами вне сети

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

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

создать моментальный снимок базы данных (Transact-SQL)
Просмотр моментального снимка базы данных (SQL Server)
Просмотр размера разреженного файла снимка базы данных (Transact-SQL)
Восстановление базы данных до состояния, сохраненного в моментальном снимке
удалить моментальный снимок базы данных (Transact-SQL)

См. также

Зеркальное отображение и моментальные снимки баз данных (SQL Server)

Снэпшот сервера — Snapshot Linux, Windows

Сохранение данных и настроек сервера

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

Сервер упал и сайт перестал работать

Разворачиваем снэпшот

Сайт восстановлен

Шаблоны проектов

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

Настраиваем проект один раз и создаём из него снэпшот

Разворачиваем снэпшот на сервере клиента

Делаем несколько проектов из одного снэпшота

API для создания и удаления снэпшотов

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

Как управлять снэпшотами через API читайте в статьях: Создание снэпшота,
Настройка cron-задания на выделенном сервере, Удаление снэпшота.

Настраиваем сохранение снэпшота через API

Снэпшот сохраняется автоматически

В случае падения сервера разворачиваем снэпшот без потери внесённых изменений

Сколько стоит хранение снэпшота

Стоимость хранения расчитывается от фактически занятого места на диске, а не от размера диска на вашем тарифе. Например, если у вас тариф с 10 ГБ места на диске, но занято только 2 ГБ, вы заплатите только за 2 ГБ.

Стоимость:

3 ₽/ГБ

Скорость записи:

12 ГБ/Мин

Какой объём файлов хранится у вас на диске?

3. 43 ₽ в день

Будет стоить хранение снэпшота

2 мин 40 с

За это время будет создан снэпшот

Панель управленияТарифы облачных серверов

Ответы на вопросы

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

Чтобы создать snapshot VPS/VDS-сервера, выберите в панели управления сервер, для которого нужен снимок, откройте вкладку «Управление» и выберите пункт «Создать снапшот». Подробнее о создании снэпшотов — в нашей Базе знаний.

Нужно ли останавливать сервер для создания снэпшота?

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

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

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

Чем снэпшот сервера отличается от резервного копирования?

org/Answer»>

Резервное копирование (backup), в отличие от снэпшотов:

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

Сколько снэпшотов и в течение какого времени можно хранить?

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

Можно ли делать снэпшоты через API?

org/Answer»>

Да, вы можете сделать моментальный снимок сервера через API. C помощью API можно написать своё веб-приложение, из которого выполнять любые функции, доступные в панели управления — создать снэпшот, перезагрузить сервер, клонировать его и многое другое. Подробнее о том, как использовать server snapshot в собственном приложении — в нашей документации.

Как рассчитывается стоимость снэпшота?

Цена услуги — 3 рубля за 1 ГБ в месяц. Например, за хранение снэпшота размером 1,66 ГБ вы заплатите 4,98 рубля в месяц.

Объяснение механики снапшота в Genshin Impact

Опубликовано 09.10.2021

Статья подготовлена Genshin Academy и размещена с одобрения автора.

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

Быстрая ссылка:
Таблица снапшотов и их таймингов

Таблица активно расширяется и дополняется со стороны Genshin Academy. Список изменений в ней можно найти на одном из листов документа.

Основы

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

В качестве примера рассмотрим Сян Лин. Её взрыв стихии наносит урон в течение 10 секунд (с 4-м созвездием — 14 секунд). На видео Сара даёт ей бонус к силе атаки, который действует лишь 6 секунд.

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

Когда игра создаёт объект Пиронадо, она делает «снимок» характеристик Сян Лин. Созданный объект запоминает эти характеристики и использует на протяжении всей длительности своего существования.

Так, Пиронадо запомнил (заснапшотил) характеристики Сян Лин, у которой была повышенная сила атаки благодаря Саре, и всё время использовал именно их. Когда же длительность бонуса закончилась и сила атаки Сян Лин понизилась, Пиронадо было на это глубоко наплевать и он продолжал использовать старые характеристики.

Таким образом мы можем «продлевать» длительность бонусов!

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

Какие характеристики снапшотятся?

Увеличить

Экран характеристик

Полный список характеристик и бонусов, которые снапшотятся:

Все характеристики с экрана характеристик персонажа.
Бонусы на подобии «Увеличивает (весь) наносимый персонажем урон…» (как у Драконьей кости). Исключения: Охотник во тьме и Гео резонанс.

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

Неполный список бонусов, которые не снапшотятся:

Бонусы к крит. урону, которые не отображаются на экране характеристик (С6 Сары).
Бонусы к урону определённых способностей (например, к урону взрыва стихии Райдэн).

Эти бонусы не временные, а постоянные. Но в качестве напоминания, они тоже не снапшотятся:

Бонусы к урону по противникам с определённым видом статуса (Ступающий по лаве, Драконий рык и др.).
Бонусы к шансу крит. попадания, которые не отображаются на экране характеристик (Крио резонанс, Заблудший в метели и др.).

Какие умения снапшотят?

Увеличить

Таблица снапшотов (находится в разработке)

Как правило, если умение создаёт какой-то объект, то он снапшотит в момент создания этого самого объекта.

Однако не следует полагаться на это правило на все 100%. Некоторые умения могут быть прописаны в программном коде не так очевидно. Например, взрыв стихии Бэй Доу снапшотит, а взрыв стихии Син Цю — нет.

Список умений, которые снапшотят, вы можете найти в таблице Genshin Academy:
Таблица снапшотов и их таймингов

Обратите внимание, что таблица находится в разработке и ещё не со всеми персонажами были проведены тесты. Таблица будет постепенно пополняться. Если Вы хотите помочь с этим, свяжитесь с ее автором.

Элементальные реакции и снапшоты

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

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

Так как Испарение и Таяние умножают урон атаки, то при расчёте урона используется показатель мастерства стихий, который атака заснапшотила.

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

Тайминги снапшотов

Важный вопрос — когда именно происходит снапшот?

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

Знание таймингов снапшотов ваших персонажей позволит вам оптимизировать вашу игру без риска потери важных баффов.

Тайминг, как правило, определяется по тому же принципу, что и прежде: когда создаётся объект, тогда и происходит снапшот. У некоторых умений создание объекта происходит с задержкой, как у Сян Лин, а у других снапшот происходит сразу в момент активации умения, как, например, у Бэй Доу.

Тайминги снапшотов можно посмотреть в таблице:
Таблица снапшотов и их таймингов

Обратим ваше внимание на Беннета. Его взрыв стихии даёт бонус к силе атаки персонажу, стоящему в пределах зоны действия — так написано в описании таланта.

Однако в реальности есть один очень важный нюанс: персонажи получают бонус к силе атаки не постоянно, а 1 раз в секунду, и бонус длится 1 секунду. Например, если персонаж войдёт в круг Беннета (или мы, стоя в круге, переключаемся на этого персонажа), то он получит бонус не сразу, а в пределах 0-1 сек. (как повезёт). Поэтому, в зависимости от умения и его тайминга снапшота, рекомендуем немного подождать, прежде чем активировать умение, стоя в круге Беннета.

В 1-ой части видео Бэй Доу ждёт бонуса Беннета, затем использует взрыв стихии. Во 2-ой части Бэй Доу использует взрыв стихии сразу и не успевает «поймать» бонус.

Заключение

В заключение скажем пару слов о названии механики.

В русскоязычном сообществе часто встречается название «суммон» (от англ. summon — призыв). Несмотря на то, что это название произошло от английского языка, в англоязычном сообществе никто не применяет его. Вместо него используют термин snapshot.

Умения, которые не снапшотят, в русскоязычном сообществе иногда называют «адаптив», а в англоязычном — dynamic (динамичное).

SwiftUI Previews ❤️ Snapshot Tests | by Ilya Lobanov

Как объединить и упростить написание SwiftUI Previews и снэпшот-тестов

Летом 2021 мы повысили deployment target в Кинопоиске до iOS 13. Это позволило нам начать использовать SwiftUI. Одно из главных преимуществ SwiftUI — это Previews.

Когда мы начали писать первые вью на SwiftUI, мы обнаружили, что написание SwiftUI Previews очень похоже на написание снэпшот-тестов. Мы решили попытаться объединить эти два подхода, чтобы с помощью SwiftUI Previews получать готовые снэпшот-тесты.

SwiftUI Previews

Previews — это инструмент SwiftUI для предварительного просмотра вью в боковом меню Xcode. Он позволяет видеть, как изменяется вью прямо во время редактирования кода, и то, как будет выглядеть вью для разных моделей, при разных настройках окружения и для разных устройств.

https://developer.apple.com/tutorials/swiftui

Например, чтобы добавить превью для ContentView, необходимо объявить структуру ContentView_Previews и реализовать протокол PreviewProvider:

А с помощью таких функций, как preferredColorScheme(_:) и previewDevice(_:), можно посмотреть, как будет выглядеть вью, например, в темной теме или на iPad.

SwiftUI Previews for iPhone and iPad

Снэпшот-тесты

В Кинопоиске мы давно используем снэпшот-тесты для UIView.

Снэпшот-тестирование — это тестирование вью с помощью снэпшотов, то есть скриншотов View. При первом запуске сохраняется референсный снэпшот, а при следующих — снэпшоты сравниваются с референсом.

Вот две самые популярные библиотеки для снэпшот-тестирования:

SnapshotTesting
iOSSnapshotTestCase

Снэпшот-тесты похожи на unit-тесты и выглядят так:

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

Они позволяют увидеть результат даже без добавления вью на экран. Это позволяет параллельно разрабатывать UI и бизнес-логику.

Также снэпшот-тесты упрощают ревью кода: скриншоты сохраняются на диск и прикладываются к пул-реквестам. У Github и Bitbucket есть различные инструменты для удобного сравнения двух скриншотов:

view-examples | pull request #1view-examples | pull request #1

Пример такого пул-реквеста можно посмотреть в тестовом репозитории — pull request #1.

SwiftUI Previews и снэпшот-тесты — очень похожие инструменты: они позволяют увидеть внешний вид вью во время разработки до добавления на какой-либо экран.

Описание SwiftUI Previews и снэпшот-тестов тоже очень похоже: мы создаем вью, описываем модель и в конце определяем набор примеров вью с разными моделями, окружением и лэйаутом. Разница будет только в конечном вызове: для SwiftUI Previews нужно определить PreviewProvider, а для тестов — assertSnapshot.

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

Как и раньше, сначала определяем вью и ее модель:

SomeView
SomeViewModel

Затем мы определяем набор примеров для вью:

3. SomeViewExamples

На основе ViewExamples мы кратко определяем превью и тесты:

4. SomeView_Previews: PreviewProvider

5. SomeViewTests: XCTestCase

Теперь нужно определить ViewExamples. Чтобы создать превью или тест, достаточно иметь только View, поэтому для определения примеров нам достаточно массива View:

Мы используем associatedtype ViewType потому что ViewExampleProvider будет использоваться и для SwiftUI и для UIKit (без превью, только для тестов).

Такого простого протокола достаточно для создания тестов и превью. Например, в самом простом случае превью мог бы выглядеть так:

А вызов assert для тестов так:

Эти хэлперы уже можно использовать для превью и тестов.

Пример

FilmographyView

В качестве примера рассмотрим FilmographyView, которая состоит из хэдера PersonView и ячеек MovieView.

Рассмотрим PersonView. Определим ее, как и раньше, вместе с моделью:

Затем определим набор примеров для этой вью с помощью ViewExampleProvider:

Обычно мы определяем примеры для моделей отдельно (в Examples), чтобы потом переиспользовать их в более крупных моделях:

FilmographyView.Model(person: .Examples.default)

Теперь с PersonView.Examples: ViewExampleProvider можно определить превью и тесты за пару строк:

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

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

Эта операция очень похожа на flatMap(_:) у последовательностей. И по аналогии с ней мы можем определить такой же flatMap но для ViewExampleProvider:

Темная тема

С таким модификатором мы можем просто определить модификатор для colorSheme:

И тогда усовершенствуем функцию previews:

Это позволит нам видеть превью сразу и для темной, и для светлой темы:

Previews for the light and dark color scheme

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

Мы добавили testName, чтобы генерировать имена снэпшотов в виде PersonView-dark.2.png.

Теперь с помощью аргумента colorScheme мы можем генерировать превью или снэпшоты для нужных цветовых схем:

Лэйаут

Чтобы упростить создание примеров для разных лэйаутов, определим вспомогательную структуру ViewExampleLayout:

Обычно мы тестируем простые вью в режиме . sizeThatFits, не фиксируя их размер. Экраны целиком удобно тестировать с помощью .device, а, например, ячейки таблицы — с помощью фиксированного размера .fixed. Чтобы не думать, какую ширину задавать ячейкам, добавим такой хэлпер:

Теперь объявим новый модификатор по аналогии с colorScheme:

Функция получилась довольно большая, но зато она значительно упростит написание тестов и превью.

И теперь чтобы усовершенствовать функцию previews, добавим в нее новый модификатор usingLayouts:

Так как PersonView мы планируем использовать как ячейку, хочется увидеть, как она будет выглядеть на маленьком и большом телефоне, и как будет переноситься и обрезаться текст:

Previews for fixed widths

FilmographyView будет использоваться для экрана целиком, поэтому ее хочется посмотреть на разных устройствах:

Preview for iPhone 12 and iPad

Похожим образом настройки лэйаута добавляются в тесты. Я не буду подробно на этом останавливаться, код можно посмотреть в репозитории — ViewExamplesProvider+Snapshots.swift.

Тест для разных устройств будет выглядеть так:

.Examples

В примерах выше мы определяли Examples для моделей и вью. Подобным образом Examples можно добавить и для системных типов, например, String:

Начиная со Swift 5.4 (SE-0287), появилась возможность вместо SomeModel.Examples.default писать просто .Examples.default. Это позволяет использовать .Examples как единую точку входа для всех примеров.

Profile Screen | SwiftUI

Использование SwiftUI кажется нам удачным решением, потому что SwiftUI позволяет быстро реализовывать нативные экраны, а .Examples помогают структурировать код, сразу видеть все корнер-кейсы в SwiftUI Previews и получать снэпшот-тесты почти бесплатно. А снэпшот-тесты, в свою очередь, упрощают код-ревью и помогают нам не сломать UI.

На SwiftUI сейчас реализован раздел «Профиль» с некоторыми внутренними экранами. Вскоре этот раздел будет целиком написан на SwiftUI, а мы продолжим его внедрение в другие части приложения.

—

💎 Большое спасибо Саше Щавровскому за внедрение SwiftUI и Examples в Кинопоиск.

Репозиторий с примером
Пример пул-реквеста со снэпшот-тестами
SnapshotTesting
iOSSnapshotTestCase

Что такое моментальный снимок хранилища?

По

Брайен Поузи
Эрин Салливан, Редактор сайта

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

Как работают моментальные снимки хранилища
Моментальные снимки хранилища часто основаны на использовании разностного диска. Разностный диск — это особый тип виртуального жесткого диска, который связан с родительским виртуальным жестким диском.
Когда администратор создает моментальный снимок хранилища, базовая система создает разностный диск, привязанный к исходному виртуальному жесткому диску. Все будущие операции записи направляются на разностный диск, оставляя исходный виртуальный жесткий диск в неизмененном состоянии. Файловая система совершенно не знает о существовании разностного диска. Файловые системы продолжают функционировать так же, как и на физической машине.
Снимки имеют отношения родитель-потомок и образуют дерево. Каждый сделанный снимок создает еще одну ветвь дерева.
Моментальные снимки обычно создаются для защиты данных, но их также можно использовать для тестирования прикладного программного обеспечения и интеллектуального анализа данных. Моментальный снимок хранилища можно использовать для аварийного восстановления (DR), когда информация потеряна из-за человеческой ошибки. Снимки также могут быть полезны для возврата системы в предыдущее состояние, если было установлено плохое исправление.
Эта статья является частью
Моментальные снимки — это блоки диска, представляющие, как выглядела файловая система в определенный момент времени.
Типы технологии моментальных снимков
Не все моментальные снимки основаны на разностных дисках. Существует несколько других типов моментальных снимков хранилища:
Моментальные снимки с копированием при записи хранят метаданные о расположении исходных данных, не копируя их при создании моментального снимка. Эти моментальные снимки создаются почти мгновенно, практически не влияя на производительность системы, делающей моментальный снимок. Это позволяет быстро восстановить систему в случае сбоя программы.
Данные в моментальном снимке копирования при записи соответствуют точному времени создания моментального снимка, отсюда и название копирование при записи . Однако все предыдущие моментальные снимки должны быть доступны, если требуется полное архивирование или восстановление всех данных в сети или на носителе. Каждый процесс копирования при записи требует одного чтения и двух операций записи; данные должны быть прочитаны и записаны в другое место, прежде чем они будут перезаписаны.
Моментальные снимки клонирования или разделения зеркал ссылаются на все данные на наборе зеркальных дисков. При каждом запуске утилиты создается снимок всего тома, а не только новых или обновленных данных. Это позволяет получить доступ к данным в автономном режиме и упрощает процесс восстановления, дублирования или архивирования всех данных на диске. Это более медленный процесс, и каждый моментальный снимок хранилища требует столько же места для хранения, сколько и исходные данные.
Копирование при записи с фоновым копированием берет данные моментального снимка из операции копирования при записи и использует фоновый процесс для копирования данных в расположение хранилища моментальных снимков. Этот процесс создает зеркало исходных данных и считается гибридом копирования при записи и клонирования.
Моментальные снимки хранилища с перенаправлением при записи аналогичны копированию при записи, но операции записи перенаправляются в хранилище, предназначенное для моментальных снимков, что устраняет необходимость в двух операциях записи. Моментальные снимки с перенаправлением при записи записывают только измененные данные, а не копию исходных данных. Когда моментальный снимок удаляется, эти данные должны быть скопированы и согласованы на исходном томе. Создание дополнительных моментальных снимков хранилища усложняет доступ к исходным данным вместе с данными моментального снимка.
Инкрементальные снимки создают временные метки, которые позволяют пользователю вернуться к любому моменту времени. Инкрементные моментальные снимки могут создаваться быстрее и чаще, чем другие типы моментальных снимков хранилища. А поскольку они занимают не намного больше места для хранения, чем исходные данные, их можно хранить дольше. Каждый раз, когда создается инкрементный снимок, исходный снимок обновляется.
Моментальные снимки VMware копируют файл диска виртуальной машины и могут восстановить виртуальную машину (ВМ) на определенный момент времени в случае сбоя. Технология моментальных снимков VMware используется в виртуальных средах VMware и часто удаляется в течение часа. Администраторы могут делать несколько моментальных снимков виртуальной машины, создавая несколько точек восстановления на определенный момент времени. При создании моментального снимка любые данные, доступные для записи, становятся доступными только для чтения.

Непрерывная защита данных
Непрерывная защита данных (CDP) использует отслеживание измененных блоков и моментальные снимки для резервного копирования системы таким образом, чтобы пользователи могли восстанавливать самые последние экземпляры данных.
CDP работает путем мониторинга устройства хранения на уровне блоков. Каждый раз, когда блок хранения создается или изменяется, для этого блока хранения автоматически создается резервная копия. Это позволяет пользователю восстанавливать данные с включенными самыми последними изменениями, тогда как эти обновления могут быть потеряны, если перед сбоем системы не был сделан обычный моментальный снимок хранилища.
CDP также ведет учет всех происходящих изменений, поэтому всегда можно восстановить самую последнюю чистую копию данных.
Моментальные снимки хранилища и резервное копирование
Хотя моментальные снимки предлагают возможности, подобные резервному копированию, моментальные снимки и резервные копии существенно отличаются друг от друга. Моментальные снимки не предназначены для замены резервных копий, хотя многие современные системы резервного копирования включают моментальные снимки.
Снапшоты против резервных копий
Существует несколько преимуществ использования моментальных снимков хранилища как части более крупной стратегии резервного копирования. Моментальные снимки обеспечивают быстрое и простое восстановление на определенный момент времени и могут использоваться приложениями резервного копирования для включения таких функций, как мгновенное восстановление. Хотя технология моментальных снимков хранилища является полезным дополнением к плану резервного копирования, она не считается полной заменой традиционному резервному копированию.
Существует несколько причин, по которым моментальные снимки не следует использовать в качестве альтернативы резервным копиям. Во-первых, моментальные снимки могут негативно повлиять на производительность системы. Особенно это касается разностных снимков дисков. При каждом создании моментального снимка создается дополнительный разностный диск. Производительность чтения системы снижается с созданием каждого дополнительного разностного диска.
Другая причина, по которой моментальные снимки не являются подходящей заменой резервного копирования, заключается в том, что моментальные снимки зависят от исходных данных. Если исходные данные потеряны, моментальный снимок также исчезнет. В отличие от резервной копии моментальный снимок не содержит копии защищенных данных и ничего не делает для защиты исходных данных от потери из-за аппаратного сбоя или повреждения хранилища.
Резервное копирование Снимок
Защита данных
Резервная копия содержит восстанавливаемую копию защищенных данных.
Моментальный снимок гарантирует, что ранее существующие данные не могут быть изменены, но ничего не делает для защиты от потери из-за сбоя оборудования или других факторов.
Восстановление
Операции восстановления включают копирование данных из резервной копии обратно в основное хранилище.
Требуемое время зависит от объема восстанавливаемых данных.
Снимки можно использовать для мгновенного возврата системы к предыдущему состоянию.
Восстановление моментальных снимков происходит быстро, потому что, в отличие от резервного копирования, данные не копируются.
Производительность
Производительность чтения системы может снизиться во время выполнения резервного копирования, но вернется к нормальному состоянию после завершения резервного копирования.
Резервное копирование CDP может повлиять на производительность системы во время первоначального резервного копирования, но последующие резервные копии обычно оказывают незначительное влияние на производительность.
Разностные снимки дисков отрицательно скажутся на производительности чтения, пока существуют снимки.
Степень влияния на производительность зависит от количества существующих моментальных снимков.
Создание каждого последующего снимка в дереве снимков еще больше снижает производительность.
Совместная работа моментальных снимков и резервных копий хранилища
Современные системы резервного копирования, используемые в производственной среде, часто используют моментальные снимки как часть процесса резервного копирования. Это особенно верно при резервном копировании активной базы данных. Если бы активная база данных была просто скопирована в резервную копию, то данные в базе данных, скорее всего, изменились бы до завершения резервного копирования. Полученная резервная копия будет повреждена.
Современные системы резервного копирования перед запуском резервного копирования делают снимок базы данных. Затем резервная копия создает резервную копию базы данных в том виде, в каком она существовала до момента создания моментального снимка. Когда процесс резервного копирования завершится, моментальный снимок будет удален, а данные, которые были сохранены в моментальном снимке, будут объединены с базой данных.
Последнее обновление: февраль 2021 г.
Продолжить чтение О моментальном снимке хранилища
Когда технология моментальных снимков хранилища работает лучше всего?
Обеспечивает ли ваша система резервного копирования данных защиту данных?
Использование моментальных копий для вашей системы резервного копирования данных
Использование различных типов технологий моментальных снимков хранилища для защиты данных
Моментальные снимки резервных копий и репликация дополняют стандартное резервное копирование
Копайте глубже в области архивирования и резервного копирования на магнитную ленту
виртуальный жесткий диск (VHD)
Автор: Рахул Авати
виртуальный жесткий диск
Автор: Брайен Поузи
резервная копия
Автор: Брайен Поузи
Что такое защита данных и почему это важно?
Автор: Пол Крочетти
SearchDisasterRecovery
Почему план аварийного восстановления HIPAA имеет решающее значение
Аварийное восстановление — сложная операция с высокими ставками. Когда в дело вступают медицинские данные, хороший план аварийного восстановления становится еще более важным…
Используйте ISO 22320:2018 для подготовки плана управления инцидентами
Управление инцидентами имеет решающее значение для обеспечения того, чтобы предприятия могли справляться с незапланированными разрушительными событиями. Узнайте, как ISO:22320:…
Новый генеральный директор Everbridge вступает в должность в критический момент
Новый генеральный директор Everbridge Дэвид Вагнер подробно описывает сферы своей деятельности в компании. Инвестор Ancora предложил частный инвестиционный …
ПоискХранилище
IBM интегрирует хранилище Red Hat для гибридного облака
Хранилище IBM интегрировало Red Hat OpenShift Data Foundation и Ceph в свое новое предложение гибридного облачного хранилища данных. Аналитики . ..
Спот от NetApp exec о поглощениях и сокращении каталога
В этом вопросе и ответе Кевин Макграт из Spot by NetApp рассказывает о будущем Fylamynt, развитии партнерских отношений с гиперскейлерами и о том, как …
Государственная налоговая служба отказывается от медленного резервного копирования жесткого диска в пользу более быстрой флэш-памяти
Департамент доходов штата Миссисипи выбрал систему хранения данных на флэш-дисках и систему резервного копирования, чтобы максимально повысить производительность приложений и минимизировать …
SearchITChannel
Партнерские программы развиваются в условиях цифровой трансформации
Серия перезапусков партнерских программ, которые продолжатся до начала 2023 года, отражают изменение бизнес-результатов, различных …
Новая стратегия выхода на рынок — ключ к продажам HPE GreenLake
Узнайте о новаторском путешествии канадского поставщика услуг с аппаратной и программной платформой как услуга — и . ..
Slack и Workday создают партнерские экосистемы для отраслевых облаков
Поставщики облачных услуг привлекают консультантов и интеграторов — и их знание вертикального рынка — для запуска цифровой трансформации…
моментальных снимков НЕ являются резервными копиями
Введение
Хотя моментальные снимки хранилища широко используются для быстрого создания виртуальных копий данных на определенный момент времени, они также часто позиционируются как действительные «решения для резервного копирования». Это неверное и опасное предположение, поскольку моментальные снимки, если только они не скопированы на вторичный носитель (например, другой массив хранения или ленту), не защищают от сбоев носителя. Несмотря на преимущества использования моментальных снимков для целей разработки или тестирования в непроизводственных системах, их не следует рассматривать в качестве надежной защиты данных или резервных копий баз данных Oracle. Вместо этого клиентам следует обратить внимание на Recovery Manager (RMAN) и Fast Recovery Area (FRA) как на поддерживаемое Oracle решение для создания резервных копий баз данных Oracle и управления ими. Обратите внимание, что, поскольку RMAN и Fast Recovery Area являются встроенными функциями базы данных Oracle, это решение также применимо к Oracle Exadata Database Machine с дополнительным преимуществом чрезвычайно высокой производительности.
В этой статье проводится сравнение технологий моментальных снимков на основе хранилища с резервными копиями RMAN и Fast Recovery Area.
Обзор
— диспетчер восстановления (RMAN) и область быстрого восстановления (FRA)
С момента своего дебюта в Oracle8 Recovery Manager (RMAN) предлагает богатый и развивающийся набор возможностей резервного копирования и восстановления, оптимизированных для баз данных, отвечающих широкому спектру требований к защите данных. Например, в Oracle Database 10g Release 1 введено инкрементно обновляемое резервное копирование, которое позволяет обновлять резервную копию полного образа табличного пространства/файла данных/базы данных на диске с помощью быстрого инкрементного резервного копирования — по сути, создавая более актуальную полную резервную копию. на диске всего за то время, которое требуется для применения инкрементного. Эта стратегия резервного копирования становится еще более эффективной в сочетании с зоной быстрого восстановления (FRA), расположенной на одном диске, где все файлы, связанные с восстановлением (включая резервные копии RMAN), могут храниться и автоматически управляться Oracle, освобождая администратора базы данных от необходимости контролировать пространство для резервного копирования. задачи управления и обеспечение того, чтобы все необходимые файлы, связанные с восстановлением, всегда были доступны в соответствии с определяемой пользователем политикой хранения. На приведенной ниже диаграмме показана эта стратегия резервного копирования:
Рисунок 1. Стратегия резервного копирования, предлагаемая Oracle
Обзор — моментальные снимки хранилища
Моментальные снимки хранилища
в течение многих лет предлагали возможности разработки и контроля качества для баз данных и сред без баз данных, предоставляя возможность быстро создавать виртуальные копии данных с эффективным хранением на определенный момент времени. Для моментальных снимков не требуется начальная копия, поскольку они хранятся не как физические копии блоков, а скорее как указатели на блоки, существовавшие на момент создания моментального снимка. Из-за этой тесной физической связи моментальный снимок хранится в том же массиве хранения, что и исходные данные. Моментальные снимки обычно реализуются как методы копирования при записи или перенаправления при записи.
В случае копирования при записи после создания моментального снимка и при первом изменении блока хранения массив копирует блок до изменения в новое место на диске, таким образом сохраняя блок до изменения для моментального снимка. и новый блок для активной версии базы данных. На диаграмме ниже блок C обновляется, поэтому старый блок копируется в новое место, а затем новый блок (C’) записывается в исходное место.
Рис. 2. Моментальный снимок хранилища с копированием при записи
В случае перенаправления при записи новый блок (C’) записывается непосредственно в хранилище моментальных снимков, как показано на диаграмме ниже. Таким образом, при изменении блока не происходит двойной записи, как в случае копирования при записи, но активная версия блоков со временем становится фрагментированной.
Рисунок 3. Моментальный снимок хранилища с перенаправлением при записи
Моментальные снимки не имеют представления о блочной структуре Oracle (поскольку они работают на уровне блоков хранилища) и, что более важно, они физически отличаются от резервных копий (состоят из указателей, а не блоков). В результате перед использованием моментальных снимков для защиты данных в базе данных Oracle необходимо учитывать значительные компромиссы.
В следующих разделах подробно описаны преимущества и недостатки инкрементально обновляемых резервных копий RMAN и решения FRA по сравнению с моментальными снимками хранилища.
Защита базы данных Oracle
RMAN — это интегрированное решение для защиты данных для базы данных Oracle, обеспечивающее несколько степеней защиты. На уровне отдельных блоков RMAN полностью проверяет блоки Oracle по мере их резервного копирования и восстановления — блоки проверяются путем физического сравнения контрольных сумм и логической проверки внутри самого блока (например, проверка согласованности части строки или записи индекса). Резервные копии можно использовать для восстановления производственных данных до последнего доступного архивного журнала повторного выполнения в любом сценарии потери данных или физического повреждения или до определенного момента времени (согласно политике хранения RMAN). Кроме того, вся база данных или отдельные табличные пространства/файлы данных могут быть проверены на корректность физических и логических блоков по усмотрению пользователя с помощью команды VALIDATE. Точно так же резервную копию можно проверить в любое время, чтобы гарантировать ее успешное восстановление с помощью команды RESTORE VALIDATE. RMAN также предоставляет возможность восстановления блочного носителя, которая позволяет быстро восстанавливать отдельные поврежденные блоки в базе данных, в то время как неповрежденные данные остаются в сети и доступны для пользователя.
Как упоминалось ранее, RMAN в сочетании с FRA формирует основу рекомендуемой Oracle стратегии резервного копирования, включающей одноразовое резервное копирование копии образа на FRA, ежедневное быстрое инкрементное резервное копирование с использованием функции отслеживания блочных изменений RMAN и регулярное обновление копии образа с помощью применение инкрементной резервной копии. При использовании RMAN для резервного копирования файлов FRA или самой базы данных на ленту Oracle Secure Backup обеспечивает оптимизированный для Oracle и интегрированный в RMAN подход к резервному копированию, использующий сжатие неиспользуемых блоков, удаление отмен и буферы разделяемой памяти для обеспечения максимально эффективного резервного копирования базы данных. на ленту. В течение последних нескольких лет многие ведущие сторонние поставщики резервного копирования также предлагали интегрированные в RMAN методы резервного копирования на магнитную ленту.
Моментальные снимки, с другой стороны, не предназначены для защиты данных Oracle. Они ничего не знают о структуре блоков Oracle и, следовательно, не могут и не могут проверять данные Oracle при их создании. Их нельзя использовать для каких-либо сценариев потери данных или физического повреждения. Повреждение блока, которое остается незамеченным, потенциально может повлиять на серию моментальных снимков, если блок не меняется с течением времени. Поскольку моментальные снимки находятся в том же массиве, что и исходная база данных, они уязвимы для сбоев, влияющих на массив хранения. Вот почему снимок, даже если он создается очень быстро, не является резервной копией исходных данных. Чтобы моментальный снимок можно было использовать в качестве допустимой резервной копии, он должен быть преобразован в виде полного набора блоков в другой массив хранения или на ленту, что связано с теми же проблемами производительности, которые характерны для полной копии. Наконец, восстановление моментального снимка имеет побочный эффект, заключающийся в аннулировании всех моментальных снимков, которые были сделаны после него, если только моментальный снимок не будет полностью восстановлен как копия производственных данных в альтернативном месте. Учитывая эти присущие моментальным снимкам недостатки, очевидно, что только резервные копии RMAN с поддержкой Oracle могут обеспечить настоящую защиту данных «спокойствие».
Производительность базы данных
Для метода резервного копирования с инкрементным обновлением RMAN требуется резервная копия исходной копии образа базы данных, т. е. 1X копия базы данных за вычетом временных файлов данных. После создания полной резервной копии единственными необходимыми операциями резервного копирования являются быстрые добавочные резервные копии и добавочное обновление копии. RMAN выполняет последовательное блочное чтение ввода-вывода Oracle в хранилище базы данных во время резервного копирования. Следовательно, производительность базы данных может потенциально снизиться во время резервного копирования из-за дополнительного потребления операций ввода-вывода. Обратите внимание, что быстрое инкрементное резервное копирование снижает потребление операций ввода-вывода за счет чтения измененных блоков только относительно последней полной или инкрементной резервной копии — и это тоже в высокой степени оптимизированным для Oracle способом с использованием возможности отслеживания изменений блоков RMAN. Кроме того, операция добавочного обновления использует ввод-вывод только в хранилище FRA, а не в хранилище рабочей базы данных.
Что касается моментальных снимков, основанных на копировании при записи, влияние на производительность базы данных проявляется двумя способами. Во-первых, после создания моментального снимка первая запись в блок базы данных преобразуется в две записи ввода-вывода в хранилище: одна для копирования исходного блока в новое хранилище моментальных снимков и одна для записи нового блока поверх исходного. блокировать. Повышенное использование операций ввода-вывода может серьезно повлиять на производительность рабочей базы данных. Во-вторых, после возврата тома рабочей базы данных к предыдущему моментальному снимку активная теперь версия блоков хранилища включает ссылки на блоки моментальных снимков, которые, скорее всего, будут фрагментированы по всему диску, а не расположены последовательно (что база данных по-прежнему ожидает). когда выдается ввод-вывод). Например, на предыдущей диаграмме моментального снимка копирования при записи запрос ввода-вывода для блока C перенаправляется на версию моментального снимка блока C, а запросы ввода-вывода для блока B не перенаправляются, поскольку он не измениться относительно времени, когда был сделан снимок. Когда база данных выполняет ввод-вывод объемом 1 МБ, вместо последовательного чтения данных в одном большом чтении она выдает 128 случайных операций ввода-вывода (при условии размера блока 8 КБ). Поскольку с течением времени создается и восстанавливается несколько моментальных снимков, результирующая фрагментированная блочная структура может потенциально привести к снижению производительности базы данных в 10–100 раз.
По этим причинам никогда не рекомендуется создавать и использовать моментальные снимки в хранилище рабочей базы данных. Моментальные снимки, если они используются для целей разработки и контроля качества, должны создаваться на вторичных копиях данных, которые не поддерживают производственную рабочую нагрузку. Группа разработчиков Oracle High Availability (HA) опубликовала высокоэффективный способ достижения этой цели с помощью Oracle Data Guard и ZFS Storage Appliance. Дополнительные сведения см. в этом техническом документе.
Производительность резервного копирования и восстановления базы данных
Как обсуждалось ранее, метод резервного копирования с инкрементным обновлением RMAN требует первоначального резервного копирования копии образа, затем инкрементного резервного копирования и инкрементного обновления копии после этого. Таким образом, время первоначального резервного копирования пропорционально размеру базы данных, а время последующего резервного копирования пропорционально объему измененных блоков между инкрементами. Если перед инкрементным обновлением копию необходимо сохранить для соответствия политике хранения, RMAN может создать резервную копию копии на ленте. Резервное копирование копии и других файлов FRA на ленту также позволяет FRA автоматически освобождать место на диске, когда для новых файлов требуется дополнительное пространство. Когда требуется восстановление, полную копию можно либо восстановить в хранилище производственной базы данных, либо использовать непосредственно в качестве файлов производственных данных с помощью команды RMAN SWITCH (т. е. восстановление без восстановления). Восстановленные файлы данных затем восстанавливаются до согласованного момента времени с помощью процесса повторного применения.
Например, если файл данных 4 случайно удален или серьезно поврежден, администратор базы данных может использовать эти простые команды RMAN, чтобы быстро переключиться на копию файла данных, поддерживаемую в FRA, и сделать ее согласованной с остальной частью базы данных, не влияя на остальную часть. базы данных и без необходимости выполнять трудоемкую операцию восстановления:
ИЗМЕНИТЬ ФАЙЛ ДАННЫХ 4 БАЗЫ ДАННЫХ АВТОНОМНО;
ПЕРЕКЛЮЧИТЬ ФАЙЛ ДАННЫХ 4 НА КОПИРОВАТЬ;
ВОССТАНОВИТЬ ФАЙЛ ДАННЫХ 4;
ИЗМЕНИТЬ ФАЙЛ ДАННЫХ 4 БАЗЫ ДАННЫХ ОНЛАЙН;
Демонстрация этого метода доступна на странице демонстрации OTN HA под названием «Диспетчер восстановления — быстрое восстановление с переключением на копирование».
С другой стороны, создание моментального снимка действительно является почти мгновенной операцией — нет необходимости делать полное или инкрементное резервное копирование. Создание моментального снимка — это, по сути, создание маркера, указывающего, когда блоки до изменения начнут копироваться в новые места хранения (как обсуждалось ранее). Возврат к моментальному снимку также является почти мгновенной операцией — физическое копирование не выполняется, а ввод-вывод перенаправляется на моментальный снимок и текущую версию блоков по мере необходимости. Как и при всех видах восстановления, восстановленный моментальный снимок базы данных должен быть восстановлен до согласованного момента времени, прежде чем его можно будет использовать.
Клонирование базы данных
RMAN клонирует производственную базу данных с помощью команды DUPLICATE. ДУБЛИРОВАНИЕ восстанавливает полную резервную копию на сервер базы данных клона и восстанавливает базу данных клона до согласованной точки, применяя инкременты/повторы по мере необходимости. Начиная с Oracle Database 11g, Active DUPLICATE клонирует базу данных, копируя файлы базы данных и необходимые архивные журналы непосредственно по сети на сервер базы данных клона, устраняя необходимость в промежуточном хранилище резервных копий. При использовании DUPLICATE время создания клона пропорционально размеру базы данных, и клон будет занимать тот же объем памяти, что и рабочая база данных.
С другой стороны, клоны на основе моментальных снимков могут создаваться почти мгновенно и занимать часть хранилища рабочей базы данных, в зависимости от шаблона изменения блоков хранилища. Точно так же, как методы копирования при записи используются для создания моментальных снимков, те же самые методы используются для создания клонов на основе моментальных снимков. Клон моментального снимка физически занимает пространство, эквивалентное объему уникальных блоков, которые изменились с момента создания клона, а не пропорционально размеру самой базы данных. Однако, как и в случае с моментальными снимками, существует дополнительное влияние на ввод-вывод базы данных из-за копирования при записи — это влияние усугубляется для доступных для записи клонов моментальных снимков, где изменения блоков базы данных клонов также отслеживаются с помощью копирования при записи. Из-за серьезного влияния на производительность операций ввода-вывода клоны моментальных снимков рекомендуется использовать не в производственной базе данных, а во вторичной копии базы данных.
Резюме
Технологии моментальных снимков на основе хранилища служат иным целям, чем решения для резервного копирования и защиты данных. Поскольку моментальные снимки находятся в том же массиве, что и рабочая база данных, они уязвимы для сбоев массива и, следовательно, не должны считаться действительными «резервными копиями» данных. Моментальные снимки можно эффективно использовать для разработки/контроля качества/тестирования на вторичной копии рабочей базы данных, но их не следует использовать в самой рабочей базе данных из-за серьезного влияния операций ввода-вывода при копировании при записи. Для резервного копирования баз данных Oracle клиенты должны использовать RMAN и Fast Recovery Area, а также Oracle Secure Backup для встроенных резервных копий на магнитных лентах, чтобы обеспечить полную защиту данных от потери и повреждения.
Тим Чиен (Tim Chien) — главный менеджер по продукту в группе разработчиков Oracle Database High Availability, специализирующийся на резервном копировании и восстановлении.
Полное введение в моментальные снимки Amazon EBS
Технология моментальных снимков является неотъемлемой частью защиты данных как в локальном центре обработки данных, так и в облаке. Снапшоты AWS представлены в виде снэпшотов Amazon Elastic Block Storage.
В этом посте мы подробно рассмотрим анатомию этих моментальных снимков AWS и их ключевые варианты использования, сначала предоставив общий обзор моментальных снимков облачного хранилища, а затем углубившись в особенности этой технологии защиты данных для AWS EBS. объемы хранения.
Введение в моментальные снимки хранилища
Технология моментальных снимков хранилища используется для создания ссылок на определенный момент времени к данным, которые находятся в базовом томе хранилища. Основной вариант использования моментальных снимков — защита данных. Как правило, содержимое моментального снимка хранилища доступно только для чтения и может использоваться администраторами хранилища и различными сторонними приложениями резервного копирования для чтения или восстановления данных, в то время как операции записи продолжаются непрерывно в активном томе хранилища.
Типы моментальных снимков хранилища
Моментальные снимки с копированием при записи
При использовании моментальных снимков с копированием при записи для данных моментальных снимков резервируется выделенная емкость хранилища. В этом хранилище будут храниться все метаданные (например, информация о том, где в файловой системе находятся исходные данные), а также копия исходных данных всякий раз, когда в исходных блоках данных происходят изменения.
Эти моментальные снимки создаются быстро из-за того, что обычно большинству блоков данных требуется только операция копирования метаданных во время создания моментального снимка. Однако, когда исходные блоки данных обновляются или перезаписываются активной файловой системой, содержимое исходных блоков данных копируется в расположение снимка в фоновом режиме. Это может повлиять на производительность последующих операций записи в исходные блоки после создания моментального снимка из-за необходимости ждать, пока исходные блоки данных будут скопированы в расположение моментального снимка.
Моментальные снимки с перенаправлением при записи
Аналогично моментальным снимкам с копированием при записи, но вместо копирования исходных данных в расположение моментального снимка по мере их обновления исходные данные остаются как есть, а изменения в этих блоках перенаправляются и записываются в место, отведенное для моментальных снимков, а метаданные обновляются, чтобы по мере необходимости указывать активную файловую систему на новые блоки. Этот метод имеет наименьший штраф за запись. Создание нескольких моментальных снимков и последующее удаление моментальных снимков может привести к сложности, которая часто усугубляется, когда исходный набор данных становится фрагментированным.
Снимки с разделенным зеркалом (AKA Clone)
Создает идентичную копию исходного тома данных, файловой системы или LUN во время создания моментального снимка. Из-за операции копирования данных создание моментальных снимков может занимать много времени, так как занимает вдвое больше места в хранилище.
Моментальные снимки CDP (непрерывная защита данных)
Моментальные снимки этого типа обеспечивают непрерывное резервное копирование данных, при котором изменения в исходных данных непрерывно и автоматически регистрируются и сохраняются в отдельном месте.
Совместимость с приложениями по сравнению с Crash-Consistent Snapshots
Когда речь идет о моментальных снимках хранилища, которые обычно создаются на уровне системы хранения, данные, хранящиеся в томах хранилища, должны быть согласованы с операционной системой и приложениями, которые их используют, а также быть пригодными для восстановления. целей. Чтобы гарантировать эти вещи, большинство решений для хранения с поддержкой моментальных снимков предоставляют возможности моментальных снимков, устойчивых к сбоям или приложениям.
Стабильные моментальные снимки
Снимки, устойчивые к сбоям, обычно создаются для обеспечения согласованности файлов (на уровне гостевой операционной системы). Непротиворечивость при сбоях обычно означает, что отдельные файлы, зафиксированные и сохраненные на диске, и их зависимости согласованы таким образом, что любой моментальный снимок, сделанный на уровне хранилища, будет иметь то же состояние, что и файловая система на сервере или виртуальной машине, которая была повреждена или повреждена. выключен без плавного выключения. Программное обеспечение для резервного копирования, которое использует моментальные снимки, устойчивые к сбоям, обычно использует возможности Microsoft Volume Shadow Copy (VSS) для систем Windows, чтобы обеспечить заморозку ожидающих операций ввода-вывода, чтобы обеспечить согласованность данных на уровне файлов гостевой ОС на диске. Непротиворечивость при сбоях не гарантирует какой-либо согласованности для конкретного приложения; поэтому моментальные снимки, устойчивые к сбоям, могут не обеспечивать достаточного решения для файлов, специфичных для приложений, таких как файлы базы данных, когда речь идет о защите и восстановлении.
Снимки, согласованные с приложениями
По своей природе моментальные снимки, согласованные с приложениями, также устойчивы к сбоям, но на гораздо более глубоком уровне. Снимок, согласованный с приложением, гарантирует, что приложение, обращающееся к данным, знает о снимке, сделанном на уровне хранилища, и, таким образом, данные согласуются с приложением в томе хранилища до создания снимка. Это гарантирует, что незавершенные операции ввода-вывода в памяти будут сброшены на диск, а данные, зафиксированные в томе хранилища, согласуются с приложением. Таким образом, во время сценария восстановления данные могут быть прочитаны приложением (например, SQL, Oracle и т. д.). Эта функция часто необходима для моментальных снимков приложения базы данных.
Введение в AWS Snapshots
Amazon Elastic Block Storage (Amazon EBS) — это конструкция хранилища на уровне блоков, которая обеспечивает надежное и высокодоступное хранилище для инстансов Amazon EC2. Тома Amazon EBS обычно создаются в зоне доступности AWS (AZ), где содержимое тома EBS реплицируется в пределах AZ. Хранилище Amazon EBS рекомендуется использовать для файловых систем, баз данных или любых приложений, которым требуется доступ к неформатированному, гранулированному доступу к хранилищу на уровне блоков.
Что такое моментальный снимок AWS?
Моментальные снимки Amazon EBS обеспечивают долгосрочную защиту и надежность данных, хранящихся на томах EBS, а также могут использоваться для репликации данных в различных регионах AWS, а также для запуска новых томов Amazon EBS. Архитектура AWS гарантирует, что эти моментальные снимки с копированием при записи будут содержать все добавочные изменения, а также все метаданные, необходимые в одном и том же моментальном снимке. В процессе создания моментального снимка EBS данные моментального снимка передаются в сегменты хранилища Amazon S3 (управляемые AWS и невидимые для конечного пользователя) в качестве автоматизированной фоновой задачи.
Основные варианты использования моментальных снимков AWS
Существуют различные варианты использования моментальных снимков EBS в AWS. Вот некоторые из них:
Резервное копирование данных: моментальные снимки Amazon EBS — это рекомендуемый AWS способ создания резервных копий данных AWS за пределами площадки, зоны доступности или региона для инстансов Amazon EC2 и их томов данных. Моментальные снимки Amazon EBS предоставляют удобный способ создания моментальных снимков работающего инстанса EC2 вместе с его данными, которые автоматически перемещаются из тома EBS в Amazon S3 для долгосрочного хранения. Различные сторонние решения для резервного копирования также используют эти моментальные снимки в процессе резервного копирования для защиты инстансов EC2.
Аварийное восстановление: моментальные снимки Amazon EBS можно использовать для репликации данных в различные другие регионы AWS, чтобы обеспечить возможность аварийного восстановления для инстансов Amazon EC2 с помощью возможности копирования моментальных снимков.
Dev/test: моментальные снимки Amazon EBS также можно использовать для удовлетворения различных требований к клонированию данных. Создание клонов для разработки и тестирования различных производственных инстансов Amazon EC2 теперь можно упростить за счет создания копий томов EBS с помощью моментальных снимков.
Как работают моментальные снимки Amazon EBS
Создание и удаление моментальных снимков EBS
Amazon EBS предоставляет возможность создавать моментальные снимки состояния, устойчивые к сбоям, либо для каждого тома, либо для нескольких томов EBS, подключенных к инстансу EC2. Эти снимки можно использовать для резервного копирования данных или в качестве источника для создания новых томов.
Моментальный снимок EBS можно создать с помощью консоли, команды CLI AWS create-snapshot или командлета New-EC2Snapshot (инструменты AWS для Windows PowerShell).
Во время создания базового снимка тома Amazon EBS весь набор данных копируется в Amazon S3. Это может быть трудоемким процессом, который также потребует емкости хранилища для полной копии оригинала. Последующие снимки будут копировать и сохранять только измененные данные, в то время как неизмененные блоки данных, находящиеся в базовом снимке, затем будут использоваться в следующем снимке. Эта ссылка на данные между моментальными снимками продолжает происходить в цепочке моментальных снимков, что помогает уменьшить объем хранилища, занимаемый моментальными снимками, чтобы свести к минимуму затраты организации на хранение.
Создание моментального снимка обычно выполняется немедленно, однако до тех пор, пока все базовые данные не будут полностью перенесены в хранилище Amazon S3, статус будет находиться в режиме ожидания. Это время завершения может варьироваться в зависимости от размера измененных данных, которые необходимо скопировать в фоновом режиме. Несколько ожидающих выполнения заданий по созданию моментальных снимков могут существенно повлиять на производительность динамического тома и его данных. По умолчанию AWS ограничивает количество ожидающих моментальных снимков пятью для одного тома gp2, магнитной ленты или io1 и одним ожидающим моментальным снимком для одного тома sc1 или st1.
Следует также отметить, что моментальные снимки Amazon EBS устойчивы только к сбоям, а не к приложениям. Для томов Amazon EBS, подключенных к инстансам с критически важными приложениями, такими как базы данных, обычно требуются моментальные снимки, согласованные с приложениями, чтобы сохранить целостность данных приложения для резервного копирования базы данных AWS. Для таких томов потребуется либо выключение экземпляра, либо последовательная запись данных приложения на том EBS перед корректным завершением работы приложения и отключением тома, прежде чем будет создан моментальный снимок, согласованный с приложением.
Удаление снимков можно выполнить с помощью консоли или команды delete-snapshot, а также с помощью командлета PowerShell Remove-EC2Snapshot. Обратите внимание, что если том EBS содержит более одного моментального снимка в цепочке, удаление моментального снимка не обязательно приведет к уменьшению потребления хранилища на полный размер этого моментального снимка. Это связано с тем, что ссылки на данные перекрестного снимка могут быть на месте (как описано выше).
Для защиты моментальных снимков AWS представила полностью управляемый сервис резервного копирования, который позволяет создавать резервные копии нескольких типов ресурсов, одним из которых является EBS, который называется AWS Backup. Это довольно простой сервис, который позволяет вам создать план резервного копирования с правилом, определяющим частоту и срок хранения резервной копии для одного или нескольких ресурсов, для которых вы хотите выполнить резервное копирование. В случае с EBS AWS Backup позволяет создавать политики резервного копирования для определения частоты создания моментальных снимков и времени, в течение которого они должны оставаться доступными, прежде чем будут автоматически удалены.
Копирование моментальных снимков Amazon EBS и совместное использование
Можно копировать данные моментальных снимков Amazon EBS в разных регионах AWS. Хотя это обеспечивает простой вариант переноса/репликации данных для клиентов, следует отметить, что первая копия моментального снимка будет полной копией исходного моментального снимка, потребляющего такой же объем базового хранилища с соответствующими затратами на хранение. Любые последующие снэпшоты будут инкрементными копиями.
Снимки можно копировать между регионами с помощью консоли Amazon EC2 или команды copy-snapshot (интерфейс командной строки AWS). Затем эти скопированные снимки можно использовать для создания томов, которые можно присоединить к новым инстансам Amazon EC2 в целевом регионе AWS для доступа к данным.
Копирование моментального снимка Amazon EBS.
Моментальными снимками Amazon EBS также можно поделиться с другими пользователями AWS, изменив разрешения моментального снимка. Снимки также могут быть опубликованы. Обратите внимание, что если они станут общедоступными, все данные, хранящиеся в моментальном снимке, будут доступны всем.
Изменение прав доступа к моментальным снимкам.
Восстановление из моментального снимка Amazon EBS
Каждый моментальный снимок Amazon EBS можно использовать для восстановления данных при наличии достаточных разрешений и знании идентификатора моментального снимка. Это обеспечивает защиту от злонамеренного или случайного повреждения данных как на уровне отдельных файлов, так и на уровне всего тома.
Восстановление данных из моментального снимка Amazon EBS включает следующие шаги:
Создание нового тома Amazon EBS с использованием существующего моментального снимка.
Присоединение нового тома Amazon EBS к инстансу Amazon EC2.
Копирование или восстановление данных в гостевой файловой системе ИЛИ возобновление работы приложения (при замене старого тома).
При создании нового тома Amazon EBS из моментального снимка том создается и становится доступным для немедленного доступа к данным. Загрузка данных (инициализация) в новый том EBS из корзины Amazon S3, в которой размещен моментальный снимок, выполняется как фоновая задача (также известная как отложенная загрузка). Это может занять много времени в зависимости от размера используемого набора данных в моментальном снимке.
Если экземпляр Amazon EC2 запрашивает блок данных, который еще не перенесен из корзины Amazon S3 в новый том EBS, эти блоки извлекаются непосредственно из корзины Amazon S3 за моментальным снимком. Это может привести к значительной задержке ввода-вывода во время первого чтения. Этого можно избежать, выполнив немедленную инициализацию всего тома с помощью dd (утилита командной строки для копирования и преобразования файлов) или fio (Flexible IO tester, утилита Linux для имитации рабочей нагрузки ввода-вывода и целей эталонного тестирования) перед чтением из нового объем ЭБС. См. дополнительную информацию, доступную для экземпляров Windows и Linux.
Предоставление новых томов Amazon EBS из моментальных снимков
Создание тома Amazon EBS из моментального снимка включает ленивую загрузку данных из моментального снимка в хранилище Amazon S3 в новый том Amazon EBS, аналогично описанному выше процессу. Таким образом, операции чтения из новых томов EBS могут быть подвержены тем же проблемам с задержкой, если инициализация данных не была завершена.
Создание нового тома Amazon EBS из моментального снимка.

Заключительное примечание
Моментальные снимки AWS для томов EBS предоставляют клиентам хорошее решение для защиты и эффективного хранения своих инстансов Amazon EC2 и данных, стоящих за ними. Возможности на основе API обеспечивают различные возможности DevOps, в которых действия по защите данных и обработке данных могут быть организованы по запросу или на основе событий (благодаря интеграции с AWS Lambda).
Но пользователи, которые развертывают Cloud Volumes ONTAP для AWS для определенных случаев использования, могут избежать недостатков отложенной загрузки и полной начальной копии моментального снимка. Используя технологию NetApp Snapshot™, Cloud Volumes и ONTAP способны сократить время, необходимое для создания и хранения данных моментальных снимков. Эти данные хранятся еще эффективнее, если мощные возможности хранения NetApp применяются к исходной копии.
Снимки AWS. Вопросы и ответы
Сколько стоят снимки AWS?
Моментальные снимки EBS предлагаются по разным ценам в разных регионах. Например, в регионе Восток США моментальные снимки оплачиваются по фиксированной цене 0,05 доллара США за ГБ в месяц. В регионе ЕС (Лондон) моментальные снимки оплачиваются по цене 0,053 доллара США за ГБ в месяц.
Можно ли удалить моментальные снимки AWS?
Да, снимок можно удалить через Консоль управления AWS. Вот как это сделать:
Перейти к консоли Amazon EC2
Перейдите на панель навигации и выберите параметр Снимки
Выберите снимок
Найдите список действий
Выбрать Удалить
Нажмите Да , Удалить
В чем разница между изображением и снимком?
В Amazon EC2 образ машины Amazon (AMI) выполняет резервное копирование всего сервера, включая все подключенные тома EBS. Моментальный снимок — это моментальная копия определенного тома. Вы можете делать снимки томов EBS и сохранять их в хранилище S3.
Узнайте больше о моментальных снимках AWS
Узнайте больше об этих преимуществах моментальных снимков и других статьях в нашей полной серии статей о моментальных снимках AWS:
Понимание цен на моментальные снимки AWS: стоимость передачи и хранения данных
Моментальные снимки AWS часто используются для резервного копирования и восстановления Amazon Данные ЕС2. На стоимость моментальных снимков EBS влияют разные факторы. Важно знать их и учитывать, чтобы снизить затраты на облако.
В этом посте рассматриваются некоторые основные параметры, влияющие на стоимость моментальных снимков, такие как передача на S3, шифрование, добавочное резервное копирование и регион. Он разбивает цены на плату за передачу и стоимость хранения на Amazon S3, приводя конкретные подробные примеры. Наконец, в статье также показано, как Cloud Volumes ONTAP может помочь значительно сократить эти расходы.
Прочтите «Понимание цен на моментальные снимки AWS: стоимость передачи и хранения данных» здесь.
Отключение S3: будьте готовы к неизбежным сбоям в облаке с помощью моментальных снимков AWS
Думаете, облако не может выйти из строя? Крупный сбой AWS в 2017 году стал признаком того, что независимо от того, насколько мы уверены в облаке, пользователям по-прежнему необходимо иметь планы на случай непредвиденных обстоятельств на случай, если вся облачная инфраструктура выйдет из строя, а вместе с ней и ваши сайты и приложения.
У пользователей есть варианты. Обращение к облачным решениям NetApp может помочь защитить ваши данные и убедиться, что вы можете работать и восстанавливаться после самых серьезных сбоев в работе облака.
Дополнительные сведения см. в разделе «Отключение S3: будьте готовы к неизбежным сбоям в облаке с помощью моментальных снимков AWS» здесь.
Репликация данных NetApp SnapMirror с AWS
Любой, кто знаком с системами хранения NetApp в центрах обработки данных, знает, что репликация данных SnapMirror упрощает и ускоряет передачу и репликацию данных между хранилищами. Эта мощная функция также является ключевой частью использования хранилища в облаке с Cloud Volumes ONTAP. SnapMirror является неотъемлемой частью миграции в облако, управления решением для аварийного восстановления и организации гибридных или мультиоблачных сред.
SnapMirror основан на высокоэффективной технологии моментальных снимков NetApp, которая требует меньше места для хранения и, следовательно, стоит меньше, чем использование моментальных снимков AWS через Amazon EBS. Вы также увидите, как SnapMirror может переносить моментальные снимки, согласованные с приложением, посредством интеграции с NetApp SnapCenter®.
Подробнее см. в разделе «Репликация данных NetApp SnapMirror с AWS». Моментальные снимки Azure работают в стеке друг против друга. Каковы основные различия между этими двумя технологиями? И подходят ли какие-либо из них для удовлетворения ваших требований к защите данных на уровне предприятия?
Дополнительные сведения см. в разделе «Подробное изучение моментальных снимков Azure и AWS EBS» здесь.
Снимки хранилища Глубокое погружение: снимки облачных томов
Вы много слышали о моментальных снимках AWS, но в этой статье мы углубимся в технологию моментальных снимков NetApp и то, как Cloud Volumes использует ее для упрощения облачных развертываний с AWS и Azure. дорого и лучше защищено. В этой статье мы подробно рассмотрим, как работает эта технология.
Снэпшоты NetApp основаны на технологии WAFL (Write Anywhere File Layout), разработанной NetApp. Как работает WAFL и что он делает? В этой статье вы узнаете об этом и многом другом, например о том, как моментальные снимки лежат в основе нескольких технологий, используемых Cloud Volumes ONTAP, от репликации данных SnapMirror и архивирования данных SnapVault до клонирования данных с помощью FlexClone® и восстановления данных с помощью SnapRestore.
Прочтите «Глубокое погружение в моментальные снимки хранилища: моментальные снимки облачных томов» здесь.
Аварийно-устойчивые резервные копии для приложений в облаке AWS
Понимание того, как работают аварийно-устойчивые резервные копии, означает понимание того, почему они так важны. Для предприятий эти причины в основном сводятся к возможности восстановления их линейки бизнес-приложений, на которые полагаются пользователи. Когда пользователи обновляют данные в важных базах данных во время создания резервных копий, эта информация должна храниться, иначе существует риск ее потери, если когда-либо возникнет необходимость восстановления из этой резервной копии. Но существуют также строгие правила соответствия, требующие создания и хранения таких резервных копий в течение определенных периодов времени, например, в здравоохранении и финансовой сфере. В любом случае финансовые последствия могут быть серьезными.
В AWS ответственность за вашу работу разделена между вами и Amazon. Когда дело доходит до постоянного резервного копирования данных в AWS, ответственность ложится на пользователя. В этом посте вы узнаете о различных методах обеспечения бездействия для создания устойчивых к сбоям резервных копий для ваших баз данных и других приложений, работающих в сервисах AWS.
Прочтите здесь «Резервные копии, устойчивые к сбоям, для приложений в облаке AWS».
См. наши дополнительные руководства по ключевым темам облачного хранилища
Мы разработали подробные руководства по ряду других тем, которые также могут быть полезны при изучении мира облачных хранилищ.
S3 Storage
Изучите основы хранения данных в Amazon Simple Storage Service (S3), первом облачном сервисе Amazon и до сих пор одном из самых популярных.
Хранилище S3: полное руководство
Простое ценообразование S3: полное руководство
Памятка по сертификации AWS
для Amazon S3
Общий доступ к файлам в облаке
Общие файловые ресурсы поддерживают некоторые из наиболее важных рабочих нагрузок, на которые полагаются предприятия, а ресурсы общедоступного облака создали новые интересные возможности. Каждый крупный поставщик общедоступных облачных сервисов теперь предлагает свои собственные облачные службы обмена файлами, каждая со своими целевыми рабочими нагрузками и соображениями. Но не каждое предприятие найдет то, что ищет, в полностью управляемом облачном сервисе.
См. лучшие статьи в нашем руководстве по обмену файлами в облаке:
Проблемы службы общего доступа к файлам в облаке
Облачные службы обмена файлами: решения с открытым исходным кодом
Кошмары облачной доступности и как их избежать при обмене файлами в облаке
Многооблачное хранилище
Стратегии многооблачной среды становятся все более популярными, поскольку организации стремятся оптимизировать свои облачные службы и развертывания. Эти стратегии могут помочь вам предотвратить привязку к поставщику, повысить гибкость и оптимизировать расходы.
В этом руководстве объясняется, что такое многооблачное хранилище, как оно работает, для чего используется, основные требования к этому хранилищу и как оно поддерживается Cloud Volumes ONTAP.
См. основные статьи в нашем руководстве по многооблачным хранилищам:
Одно облако из многих: почему предприятия переходят на многооблачные и гибридные облачные архитектуры
Мультиоблачная архитектура: секционированная, Cloud Burst и аварийное восстановление
Мультиоблачное развертывание: создание плана с использованием облачных томов ONTAP
Службы баз данных AWS
AWS предлагает ряд служб баз данных и поддержку, чтобы попытаться удовлетворить все потребности своих клиентов. Многие из этих служб полностью управляемы, что помогает снизить рабочую нагрузку на ИТ и максимально упростить хранение и использование данных.
В этом руководстве объясняется, какая поддержка баз данных AWS доступна, какие службы баз данных доступны и как вы можете перенести свои базы данных в AWS.
См. основные статьи в нашем руководстве по сервисам баз данных AWS:
База данных AWS как услуга: типы DBaaS и примеры использования
SQL Server в AWS: управляемая служба и управляемое хранилище
AWS Oracle RDS: запуск вашей первой базы данных Oracle на Amazon
Снимки состояния AWS для Amazon EBS
Снимки — это распространенный метод резервного копирования облачных данных и служб. Этот метод позволяет сохранять резервные копии на определенный момент времени, которые можно восстановить при необходимости.
В этом руководстве объясняется, какие типы моментальных снимков хранилища доступны, что такое моментальные снимки AWS и как их использовать.
См. основные статьи в нашем руководстве по снимкам состояния AWS:
Снимки Azure и AWS Подробное описание: Снимки облачных томов
Подробный обзор моментальных снимков
: моментальные снимки AWS и моментальные снимки Azure
Общие сведения о ценах на моментальные снимки AWS: стоимость передачи и хранения данных
Службы баз данных Azure
Почти каждое производственное облачное развертывание имеет одну или несколько баз данных. Эти инструменты обеспечивают поддержку приложений, позволяют выполнять рабочие нагрузки и осмысленно упорядочивают данные. Наличие доступных баз данных, которые поддерживают все ваши потребности, имеет важное значение, и Azure предлагает широкий выбор на выбор.
В этом руководстве объясняется, какие рабочие нагрузки базы данных Azure поддерживаются, как базы данных работают в Azure и какие службы доступны.
См. основные статьи в нашем руководстве по базам данных Azure:
Azure Oracle: ваша первая база данных Oracle в Azure
Служба миграции базы данных Azure: полное руководство
База данных SQL Azure: 18 вариантов для SQL Server в облаке
Хранилище файлов Azure
Хранить данные файлов в Azure очень просто с помощью службы хранилища файлов Azure. Эта служба позволяет хранить файлы в облачных и локальных ресурсах, обеспечивая гибкий и безопасный обмен данными и рабочими процессами.
В этом руководстве объясняется, что такое хранилище файлов Azure, распространенные варианты использования файлов, концепции управления и компоненты службы, способы доступа к данным и архитектура службы, а также некоторые рекомендации по защите ваших данных.
См. основные статьи в нашем руководстве по файловому хранилищу Azure:
Хранилище файлов в Azure
Почему вам следует переносить базы данных в Azure?
Хранилище Azure: за кулисами
Файлы Azure
Файлы Azure — это одна из нескольких служб хранения, доступных пользователям в Azure. Это служба, предназначенная для репликации общих файловых ресурсов, подобных тем, которые обычно используются в локальной среде. С помощью этой услуги вы можете плавно перенести свои файлы в облако и разрешить обмен файлами между вашими командами.
В этом руководстве объясняется, что такое служба файлов Azure, как она дополняет другие службы хранения, цены и варианты использования файлов, а также плюсы и минусы, о которых вам следует знать.
См. основные статьи в нашем руководстве по файлам Azure:
Регистрация файлов Azure NetApp
Общий доступ к файлам SMB
NFS и SMB — простая среда файловой службы в Azure.
Google Cloud Storage
Google Cloud предлагает различные варианты хранения на ваш выбор. Эти сервисы составляют основу многих других сервисов в облаке, и понимание того, какие у вас есть варианты, может помочь вам более эффективно управлять своим облаком.
В этом руководстве объясняется, какие существуют варианты Google Cloud Storage и как они обычно используются.
См. лучшие статьи в нашем руководстве по облачному хранилищу Google:
Облачные службы обмена файлами: Google Cloud Filestore
Шифрование Google Cloud Storage: управление ключами в Google Cloud
Цены на облачное хранилище Google: получите максимальную отдачу от своих ведер
Kubernetes Storage
Разработчики программного обеспечения и инженеры DevOps упаковывают приложения в легкие блоки, называемые контейнерами. Kubernetes помогает управлять контейнерами и масштабировать их в кластерах физических машин.
В этой среде хранилище Kubernetes становится серьезной проблемой. По умолчанию контейнеры эфемерны, что означает, что любые временные данные в контейнере теряются при его завершении работы. Однако Kubernetes предоставляет несколько вариантов постоянного хранилища.
См. лучшие статьи в нашем руководстве по Kubernetes:
Введение в Kubernetes
Общие сведения о подготовке постоянных томов Kubernetes
Постоянное хранилище Kubernetes: почему, где и как
AWS Big Data
Узнайте об обширной экосистеме больших данных Amazon, включая решения для эластично масштабируемых озер данных, решения для анализа данных и базы данных NoSQL.
См. лучшие статьи в нашем руководстве по большим данным AWS:
Озеро данных AWS: сквозной рабочий процесс в облаке
AWS Data Analytics: выбор наилучшего варианта для вас
MongoDB на AWS: управляемый сервис и самоуправляемый
Большие данные Azure
Узнайте о подходе Azure к большим данным, включая решение Azure Data Lake, службы расширенной аналитики и управляемые службы баз данных NoSQL.
См. основные статьи в нашем руководстве по большим данным Azure:
Озеро данных Azure: 4 строительных блока и рекомендации
Azure NoSQL: типы, службы и краткое руководство
Службы Azure Analytics: подробный обзор
Резервные копии и моментальные снимки: различия и примеры
Последнее обновление: 29 апреля 2022 г.
Безопасность хранения данных важна как никогда, независимо от того, в какой отрасли вы работаете. К сожалению, слишком многим предприятиям не хватает эффективных и современных технологий, которые могли бы обеспечить безопасность их данных.
Потеря данных может стать серьезным препятствием на пути к успешному масштабированию и развитию. Независимо от размера компании.
На самом деле, потеря данных может быть вызвана целым рядом различных факторов.
От вредоносных программ и вирусов до перебоев в подаче электроэнергии и случайных повреждений — потеря данных намного проще, чем вы думаете.
Из-за этого необходимо защитить данные предприятия.
К счастью, вариантов масса.
Два популярных варианта включают резервное копирование и моментальный снимок.
Оба эти процесса используются для уменьшения количества сценариев потери данных за счет «резервного копирования» ваших данных.
Однако оба они сильно отличаются друг от друга, и каждый может похвастаться своими вариантами использования.
В этом кратком руководстве мы рассмотрим моментальные снимки и резервные копии и их основные различия.
Содержание
Что такое сервер или резервное копирование файлов?
Плюсы резервного копирования сервера
Минусы резервного копирования сервера
Когда использовать резервное копирование сервера
Что такое снимок?
Плюсы снэпшотов
Минусы снэпшотов
Когда использовать снэпшоты
Резюме: Каковы ключевые различия между снэпшотами и резервными копиями?
Автоматическое резервное копирование файлов и моментальных снимков с помощью SimpleBackups
Что такое сервер или резервное копирование файлов?
Резервная копия сервера (или то, что мы часто называем резервной копией файлов) — это просто копия файлов системы или сервера.
Когда вы создаете резервную копию, она фактически создает архив некоторых или всех файлов вашего сервера.
Эти файлы, объединенные в архив, хранятся в другом месте, чем исходный источник, что делает их весьма надежными в случае повреждения файла или потери данных.
Основное различие между резервной копией и моментальным снимком заключается в том, что резервные копии представляют собой изолированные копии данных.
Они не подключены к вашей виртуальной машине.
Это означает, что они не будут предлагать полный образ виртуальной машины, который вы можете восстановить, а скорее позволят вам восстановить отдельные файлы/папки, которые могли быть скомпрометированы.
Резервные копии можно легко перенести в облако или удаленный центр обработки данных, в отличие от моментальных снимков.
Плюсы резервного копирования серверов
Если вы загружаете резервные копии в облако, к ним можно получить доступ из любого места в любое время.
Их можно легко переместить в облако, за пределы офиса или в центр обработки данных.
Резервные копии серверов очень эффективны, надежны и идеально подходят для долгосрочной защиты центра обработки данных.
Отличный выбор для аварийного восстановления.
Для резервных копий сервера не требуется локальное и внешнее хранилище.
Минусы резервного копирования серверов
Процесс резервного копирования может занять больше времени, в зависимости от объема копируемых данных.
Когда следует использовать резервное копирование сервера
В идеале, если вы хотите инвестировать в долгосрочную защиту данных, всегда следует учитывать резервное копирование файлов.
Если вы размещаете несколько проектов на сервере, это позволяет создавать их резервные копии и, таким образом, восстанавливать их по отдельности, не затрагивая другие проекты
Резервное копирование идеально подходит не только для обеспечения непрерывности бизнеса. Они также могут предоставлять функции, которые просто недоступны снимкам. Подумайте о резервных копиях на уровне образа. Они предлагают множество вариантов восстановления и могут восстанавливать целые виртуальные машины или приложения.
В менее тяжелых сценариях вы можете использовать добавочное резервное копирование, чтобы создавать резервные копии только недавно измененных данных, чтобы вы могли сэкономить место для хранения.
Что такое снимок?
Снимок — это быстрая «фотография» файловой системы вашего сервера за определенный период.
Эта фотография вашей файловой системы обычно используется для восстановления целых серверов в случае потери или повреждения данных.
Моментальные снимки могут быть очень полезны в некоторых сценариях и, безусловно, идеальны в сочетании с резервным копированием сервера.
Плюсы моментальных снимков
Снимки небольшие, их можно сделать быстро и легко, не слишком сильно влияя на сервер.
Они обеспечивают лучшую доступность приложений, быстрое восстановление, упрощают управление резервным копированием больших объемов данных и снижают риск потери данных.
Моментальные снимки можно планировать и использовать при необходимости для резервного копирования системы.
Они могут почти устранить необходимость в окнах резервного копирования и снизить стоимость владения.
Поврежденные или удаленные данные можно восстановить с помощью моментальных снимков. (Кроме того, вы можете вернуться к более старой версии моментального снимка в случае повреждения файла.
Вместо восстановления всей системы можно переключиться на реплицированные копии снэпшотов, поскольку они уже имеют исходный формат.
Вы можете мгновенно запустить восстановление сервера из моментального снимка.
Минусы моментальных снимков
Резервные копии моментальных снимков полагаются на облачного провайдера системы и должны быть только на облачном провайдере сервера. Это означает, что если что-то пойдет не так в центре обработки данных вашего провайдера, вы также рискуете потерять свои снэпшоты.
Для внутренних моментальных снимков: если на сервере слишком много моментальных снимков, система замедлит объем продукта. Стоит отметить, что это происходит только при копировании данных снимка при записи. Большинство систем моментальных снимков имеют незначительное отставание.
Когда использовать моментальные снимки
Когда резервное копирование моментальных снимков имеет свои недостатки, преимущества весьма хороши.
Это очень практичное решение для резервного копирования системы, если оно используется как с локальными, так и с удаленными системами резервного копирования.
Если у вашего стартапа или предприятия уже есть эти системы хранения, моментальные снимки могут стать отличным решением для резервного копирования и безопасности данных. Тем не менее, они лучше всего используются для краткосрочных ситуаций.
Резюме. Каковы основные различия между моментальными снимками и резервными копиями?
Резервная копия — это дубликат файла или любого типа данных, которые обычно хранятся в архиве.
После запуска резервного копирования ваши файлы будут скопированы. Эти копии хранятся в отдельном месте. Время процессов резервного копирования зависит от объема копируемых данных.
Снимки — это своего рода «фотографии» файловой системы вашего сервера. На этой фотографии запечатлено все о сервере именно тогда, когда она была сделана. Моментальные снимки можно использовать для восстановления серверов, возвращая их в состояние, в котором они находились на момент создания моментального снимка.
Подводя итог, вот основные различия между резервной копией сервера/файла и моментальными снимками:
Резервные копии могут храниться в других местах, на том же диске или даже на том же сервере. Они не требуют внешнего и внутреннего хранения. Для моментальных снимков требуется как локальное, так и внешнее хранилище, и они всегда должны храниться в тех же местах, где находятся исходные системные данные.
Резервные копии могут иметь разное время начала и окончания резервного копирования. Снимки — это «фотографии» вашего сервера, которые сохраняют его точно таким, каким он был в данный момент времени.
Процесс создания резервных копий может быть долгим и утомительным. Снимки создаются мгновенно и занимают гораздо меньше времени. Снимки также занимают меньше времени для копирования данных.
Файлы резервных копий включают только файловую систему. Снимки могут быть сделаны для различных типов систем. К ним относятся файлы, приложения, настройки и т. д.
Резервные копии существуют в разных определенных местах и могут быть легко восстановлены. Резервные копии также обычно поддаются проверке. Снапшоты — это не совсем резервные копии. Их можно использовать как часть процесса резервного копирования (и следует), но в основном это краткосрочные решения. Снимки удаляются после завершения резервного копирования.
Как снимки, так и резервные копии имеют свои плюсы и минусы. Однако обычно рекомендуется выбирать резервные копии, если вам нужно долгосрочное покрытие. Снимки предназначены для краткосрочного использования и хранения. Как правило, они полезны только в том случае, если вам нужно вернуться к самой последней версии вашего сервера в той же инфраструктуре.
Когда дело доходит до этого, и моментальные снимки, и резервные копии файлов могут использоваться вместе для разных уровней защиты данных, и на самом деле это наиболее рекомендуемая настройка для стратегии надежного резервного копирования.
Автоматическое резервное копирование файлов и моментальных снимков с помощью SimpleBackups
simplebackups.com SimpleBackups сэкономит вам много времени на настройку моментальных снимков и управление ими. Он помогает планировать моментальные снимки на момент времени для дроплетов DigitalOcean, AWS EC2, Exoscale, Lightsail, Hetzner и других поставщиков. Серверы могут выйти из строя в любое время, примите меры и избегайте безвозвратной потери данных!
Постоянные снимки диска | Документация Compute Engine
Моментальные снимки создают инкрементные резервные копии данных с ваших постоянных дисков. После тебя создать снимок для захвата текущего состояния диска, вы можете использовать его для восстановить эти данные на новый диск. Compute Engine хранит несколько копий каждого моментального снимка в нескольких местах с автоматическими контрольными суммами, чтобы гарантировать целостность ваших данных.
Вы можете создавать моментальные снимки с дисков, даже если они подключены к работающим экземпляры виртуальной машины (ВМ). Жизненный цикл снимка, созданного с диска подключенный к работающим экземплярам ВМ, не зависит от жизненного цикла ВМ пример.
Обратите внимание, что моментальные снимки отличаются от пользовательских образов и образы машин, которые полезны для создание загрузочных дисков экземпляра. Чтобы узнать больше, см. таблицу сравнения использования изображения, снимки и шаблоны экземпляров.
Работа со снимками
Чтобы узнать, как создавать резервные копии дисков с помощью моментальных снимков, см. Создание моментальных снимков. Вы можете создать моментальный снимок своего диска, прежде чем пытаться потенциально опасная операция, так что вы можете отменить изменение в случае, если ваши результаты являются неожиданными.
Чтобы узнать, как восстановить содержимое моментального снимка на новый диск, см. Восстановление снимков.
Если вам больше не нужен конкретный моментальный снимок, вы можете сократить расходы на хранение, удаление снимка.
Чтобы снизить риск неожиданной потери данных, следуйте рекомендациям настройка расписания моментальных снимков для обеспечить регулярное резервное копирование ваших данных.
Доступ к моментальным снимкам
Снимки — это глобальные ресурсы, поэтому любой снимок доступен любому ресурсу в рамках одного проекта.
Вы также можете обмениваться снимками между проектами.
Ограничения
Вы не можете изменить место хранения существующего моментального снимка. См. Выбор место хранения моментального снимка.
Вы можете создавать моментальные снимки своих дисков не чаще одного раза каждые 10 минут. если ты хотите отправить пакет запросов на создание моментальных снимков ваших дисков, вы можете отправить их по адресу максимум 6 запросов за 60 минут. Дополнительные сведения см. в разделе Частота снимков. пределы.
Вы не можете редактировать данные, хранящиеся в моментальном снимке.
Как работают добавочные моментальные снимки
Снимки являются добавочными и автоматически сжимаются, поэтому вы можете создавать обычные моментальные снимки на постоянном диске быстрее и с меньшими затратами чем если бы вы регулярно создавали полный образ диска.
Важно: Моментальные снимки по умолчанию являются добавочными, чтобы вам не избыточных данных и свести к минимуму использование дискового пространства. Однако для обеспечения надежность истории моментальных снимков, моментальный снимок может иногда захватывать полный образ диска. Это происходит автоматически, чтобы оптимизировать пространство для хранения и стоит максимально дорого, и вам не нужно выбирать между созданием добавочные или полные снимки. Когда это происходит, предыдущие добавочные моментальные снимки этого диска не изменились.
Инкрементальные снимки работают следующим образом:
Первый успешный снимок постоянного диска — это полный снимок. который содержит все данные на постоянном диске.
Второй снимок содержит только новые данные или измененные данные с момента первый снимок. Данные, которые не изменились с момента создания снимка 1, не включаются. Вместо этого снимок 2 содержит ссылки на снимок 1 для любых неизмененных данные.
Снимок 3 содержит новые или измененные данные с момента создания снимка 2, но не будет содержат любые неизмененные данные из снимка 1 или 2. Вместо этого снимок 3 содержит ссылки на блоки в снимке 1 и снимке 2 для любых неизмененных данных.
Это повторяется для всех последующих моментальных снимков постоянного диска. Снимки всегда создаются на основе последнего удачного моментального снимка.
Удаление моментального снимка
Compute Engine использует добавочные моментальные снимки, чтобы каждый моментальный снимок содержит только те данные, которые изменились с момента предыдущего снимка. За неизмененные данные, моментальные снимки ссылаются на данные в предыдущих моментальных снимках. Затраты на хранение постоянных моментальных снимков диска взимать плату только за общий размер снимка.
При удалении моментального снимка Compute Engine сразу помечает снимок как УДАЛЕНО в системе. Если снимок не имеет зависимых снимков, он удаляется напрочь. Однако, если у моментального снимка есть зависимые моментальные снимки:
Все данные, необходимые для восстановления других моментальных снимков, перемещаются в следующий снимок, увеличивая его размер.
Все данные, которые не требуются для восстановления других моментальных снимков, удаляются. Этот уменьшает общий размер всех ваших снимков.
Следующий снимок больше не ссылается на снимок, отмеченный для удаления, и вместо этого ссылается на снимок перед ним.
Поскольку для последующих моментальных снимков может потребоваться информация, хранящаяся в предыдущем снимок, имейте в виду, что удаление снимка не обязательно удаляет все данные на снимке. Чтобы окончательно удалить данные из снимков, вы должны удалить все снимки.
Если на вашем диске есть расписание моментальных снимков, вы должны отсоединить расписание моментальных снимков с диска, прежде чем вы сможете удалить расписание. Удаление расписания снимков с диска предотвращает дальнейшее выполнение моментальных снимков. Вы не можете удалить расписание, прикрепленное к диску. У вас есть возможность вручную удалить снимки в любое время.
На следующей диаграмме показан этот процесс:
Размер моментального снимка и удаленные блоки
Моментальные снимки фиксируют части диска, которые были записаны и не удалены. В зависимости от конфигурации файловой системы диска иногда удаленные файлы не сохраняются. отброшен. Если это произойдет, вы можете увидеть, что размер вашего снимка больше, чем используемое пространство на диске, о котором сообщает файловая система. Избегать В этом случае рекомендуется включить параметр discard или запустить 9. 1031 фстрим на ваш диск.
Цепочки снимков
Использование интерфейса командной строки gcloud или API Compute Engine, вы можете создавать снимки в отдельных цепочках снимков, указав моментальный снимок имя_цепи . Когда вы создаете несколько моментальных снимков постоянного диска с помощью имя цепочки, каждый снимок основывается на последнем успешном снимке созданный с этим именем цепи. Это доступно в бета-версии. Используйте это поле, только если вы являетесь продвинутым владельцем службы, которому необходимо создавать отдельные цепочки моментальных снимков, например, для отслеживания возвратных платежей.
Архивировать моментальные снимки
При создании моментального снимка у вас есть возможность создать стандартный снимок или архивный снимок . Архивные моментальные снимки имеют те же преимущества, что и стандартные моментальные снимки, включая: инкрементные цепочки, сжатие и шифрование. Однако архивные снимки дешевле и лучше подходят для случаев, связанных с соблюдением нормативных требований, аудитом и длительное хранение в холодильнике. Если вам требуется хранение моментальных снимков в течение многих месяцев или лет и редко нуждаются в доступе к моментальным снимкам, рассмотрите возможность использования архивных моментальных снимков вместо стандартных снимков.
Место хранения моментальных снимков
При создании моментального снимка можно указать место хранения. Расположение снимка влияет на его доступность и может привести к сетевым затратам при создании моментального снимка или его восстановлении на новый диск.
Снимки могут храниться либо в одном облачном хранилище, адрес, например азия , или один региональное расположение облачного хранилища, например азия-юг2 .
Многорегиональное хранилище обеспечивает максимальную доступность и устойчивость. Региональное хранилище дает вам больший контроль над физическим расположение ваших данных, потому что вы указываете один регион.
Моментальный снимок можно использовать для создания нового диска в любом регионе и зоне независимо от места хранения моментального снимка.
Если у вас есть политика организации который включает ограничение местоположения ресурсов, любое место хранения моментальных снимков, которое вы укажете, должно быть в наборе местоположений. определяется ограничением. См. расположение ресурсов Compute Engine Чтобы получить больше информации.
Если не указать место хранения моментального снимка, Google Cloud использует расположение по умолчанию, в котором хранится ваш снимок в Многорегиональное расположение Cloud Storage, ближайшее к региону источника диск. Если вам нужно выбрать региональное хранилище, или если вам нужно указать другом мультирегиональном местоположении, сохраните свой снимок в пользовательском расположение.
Примечание: Вы не можете изменить место хранения существующего моментального снимка. если ты необходимо переместить снимок из одного региона или мультирегионального местоположения в другой, необходимо создать новый снимок и указать его местоположение, а также удалить предыдущий снимок. При создании снимка можно указать только один многорегиональное местоположение или одно региональное местоположение. Если вам нужно хранить снимок в нескольких местах, необходимо создать снимок в каждом месте.
Местоположение по умолчанию
Если вы не укажете место хранения, ваш снимок будет сохранен в мультирегиональный, географически ближайший к местоположению вашего постоянного диска.
Например, если ваш постоянный диск хранится в us-central1 , ваш моментальный снимок по умолчанию хранится в мультирегионе us .
Однако местоположение по умолчанию, такое как australia-southeast1 , находится за пределами мультирегион. Ближайший мультирегион — азия . Создание или восстановление снимок генерирует сетевые затраты.
Некоторые примеры использования для выбора местоположения по умолчанию для хранения снимков включают следующее:
Расположение по умолчанию в нескольких регионах соответствует корпоративным или государственным политики размещения данных.
Ваш постоянный диск хранится в региональной папке, которая является частью расположение по умолчанию в нескольких регионах. Например, ваш постоянный диск находится в регион us-central1 , поэтому мультирегион по умолчанию — us . В таком случае, более высокая доступность моментальных снимков имеет приоритет с риском более медленных моментальных снимков производительность реставрации.
Вы не ожидаете, что ваши моментальные снимки будут часто восстанавливаться на диски, которые находится за пределами стандартного хранилища моментальных снимков.
Пользовательское местоположение
Выберите пользовательское местоположение для сохранения моментального снимка в региональном местоположении, или если вам нужно указать другое мультирегиональное местоположение.
Некоторые примеры выбора пользовательского места хранения для ваших моментальных снимков являются:
Персонализированное местоположение в нескольких регионах соответствует корпоративным или государственным политики размещения данных.
Ваше приложение развернуто в регионе, который не входит ни в один из Облачное хранилище расположено в нескольких регионах, и вы хотите расставить приоритеты производительность восстановления моментальных снимков выше доступности моментальных снимков.
Вы несколько раз восстанавливаете свои моментальные снимки с диска, расположенного за пределами место хранения моментальных снимков по умолчанию.
Если вам необходимо соблюдать корпоративные или государственные правила размещения данных, сохраните свой снимок в ближайшем региональном расположении, которое соответствует эти политики.
Если ваше приложение не развернуто в части мультирегиона и вы хотите чтобы отдать предпочтение низким сетевым затратам, а не высокой доступности моментальных снимков, хранить ваш снимок в регионе, где находится ваш исходный диск. Хранение вашего моментальный снимок в регионе, где находится ваш исходный диск, сводит к минимуму работу в сети затраты на восстановление и создание моментальных снимков с этого исходного диска.
Однако, в отличие от мультирегионального склада, региональный место хранения не хранит ваши данные избыточно в нескольких данных центров, поэтому ваши данные могут быть недоступны в случае крупномасштабного сбоя имеет место. Чтобы обеспечить доступность ваших данных, вы также можете хранить избыточный снимок во втором месте.
Затраты на сеть
Выбор места для хранения моментальных снимков жизненно важен для минимизации сетевые расходы. Если вы храните снимок в том же регионе, что и исходный диск, без платы за сеть при доступе к этому снимку из того же региона. Если вы получаете доступ к снимку из другого региона, есть стоимость сети.
Если географическое хранилище исходного диска местоположение такое же, как и его мультирегион, плата за сеть отсутствует.
Например, если ваш исходный диск находится в asia-east1-a , вы можете хранить моментальный снимок в регионе asia-east1 или мультирегионе asia . Вы не будете нести затраты на сеть при доступе к своим снимкам.
За межрегиональный доступ взимается плата. Например, если ваш источник диск находится в asia-east1 , и вы храните свои снимки в asia-east2 , вы будете нести затраты на сеть при доступе к моментальному снимку между этими двумя регионами.
Два региона, австралия-юго-восток1 и southamerica-east1 имеют значение по умолчанию расположение хранилища моментальных снимков в нескольких регионах, которое повлечет за собой затраты на сеть если вы не переопределите значение по умолчанию при создании моментального снимка:
Если ваш исходный диск находится в australia-southeast1 , моментальный снимок по умолчанию место хранения находится в мультирегионе азия . Чтобы сократить расходы, переопределите это местоположение по умолчанию и хранить ваши снимки в australia-southeast1 область, край.
Если ваш исходный диск находится в southamerica-east1 , снимок по умолчанию Место хранения находится в мультирегионе us . Чтобы сократить расходы, переопределите это расположение по умолчанию и хранить ваши снимки в южная Америка-Восток1 область, край.
Если вы восстанавливаете моментальный снимок на диск в регионе, который не включены в место хранения моментального снимка, вы понесете расходы на сеть. Например, если вы создаете новый региональный постоянный диск в australia-southeast1 из моментального снимка, хранящегося в Азия , мультирегиональный местоположение, вы понесете расходы на сеть.
Что дальше
Узнайте о работе со снимками.
Ознакомьтесь с рекомендациями по работе со снимками.
Узнайте, как регулярно выполнять резервное копирование дисков с помощью моментальных снимков по расписанию.
Штат Орегон: исследования — снимки высшего образования штата
Перейти к основному содержанию страницы
Координационная комиссия по высшему образованию > Исследования > Моментальные снимки высшего образования штата
Сводка о высшем образовании штата Snapshots — это ежегодный ресурс, в котором освещаются ключевые общедоступные данные о высшем образовании для жителей Орегона. Пятый ежегодный обзор, выпущенный в августе 2022 г., включает 27 удобных для чтения одностраничных визуализаций данных, которые иллюстрируют меры высшего образования, связанные с
зачисление, доступность и результаты для всех учащихся, проживающих в штате Орегон, в 2020–2021 годах с особым акцентом на группы населения с недостаточным уровнем обслуживания. Представлены согласованные данные для всех общественных колледжей вместе взятых, всех государственных университетов вместе взятых, всех государственных учреждений, а также для каждого из 17 общественных колледжей штата Орегон и семи государственных университетов.
Чтобы просмотреть снимки, щелкните интересующее вас учреждение или набор данных на карте ниже, , или просмотрите полный алфавитный список снимков, доступных для загрузки, в списке под картой. Определения визуализаций данных описаны на второй странице каждого снимка и более подробно в нашем Страница определений моментальных снимков высшего образования по всей стране здесь . Читатели, у которых есть вопросы, могут обратиться в Отдел исследований и данных HECC по номеру .
Альтернативные форматы доступны по запросу.

Снимки по всему штату для скачивания: 2020-21
Выпущено летом 2022
Полноцветные версии и версии в оттенках серого доступны для загрузки ниже.
Снэпшоты это: моментальный снимок облачного сервера 1cloud.ru