Узнайте, как автоматически создавать резервные копии озера данных с помощью моментальных снимков больших двоичных объектов и инкрементных резервных копий фабрики данных

1. Резервное копирование хранилища Azure - Введение

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

  • Создание моментального снимка: в случае добавления или изменения большого двоичного объекта создается моментальный снимок из текущей ситуации. Из-за природы капель это эффективная операция O (1). Снимки можно восстановить быстро, однако восстановление не всегда может быть выполнено (например, удаленные капли), см. Следующую стратегию.
  • Инкрементное резервное копирование: в случае добавления или изменения большого двоичного объекта инкрементная резервная копия создается в другой учетной записи хранения. Копирование больших двоичных объектов - дорогостоящая операция O (N), но ее можно выполнить асинхронно с помощью фабрики данных Azure. Восстановление может быть выполнено путем копирования больших двоичных объектов.

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

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

  • Сценарий на основе событий, запускаемый производителем для создания моментальных снимков и запросов инкрементного резервного копирования после приема / изменения данных
  • Сценарий триггера очереди, который создает инкрементные резервные копии с помощью ADFv2
  • Сценарий на основе времени, запускаемый администратором для согласования отсутствующих снимков / добавочных резервных копий

Обратите внимание, что моментальные снимки больших двоичных объектов поддерживаются только в обычных учетных записях хранения и еще не поддерживаются в ADLSgen2 (но ожидается, что они также станут доступны в ADLSgen2). Таким образом, сценарии основаны на обычных учетных записях хранения, подробное объяснение сценариев можно найти ниже. Также обратите внимание, что скрипты предназначены для создания снимков / резервных копий, а не для их восстановления.

2. Запросы на моментальные снимки / инкрементные резервные копии на основе событий

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

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

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

Внутреннюю работу скрипта HttpSnapshotIncBackupContainerProducer можно объяснить следующим образом:

  • 0. Скрипт инициализации моментального снимка / резервного копирования проверяет наличие измененных / новых больших двоичных объектов в контейнере учетной записи хранения, сравнивая ETag большого двоичного объекта с предыдущими снимками (если есть). В случае обнаружения измененного / нового большого двоичного объекта выполняются следующие 2 шага:
  • 1а. Создать снимок из измененного / нового большого двоичного объекта
  • 1b. Отправить сообщение с запросом инкрементного резервного копирования в очередь хранилища. Сообщение запроса резервного копирования содержит только метаданные измененного большого двоичного объекта.

Суть скрипта такова:

# Get all blobs in container
prev_blob_name = ""
prev_blob_etag = ""
blob_list = container.list_blobs(include=['snapshots'])                           for blob in blob_list:                                                       if blob.snapshot == None:
    # Blob that is not snapshot
    if prev_blob_name != blob.name: 
        # New blob without snapshot, create snapshot/backup                                        
        create_snapshot_backup(blob.name, blob.etag)
    elif prev_blob_etag != blob.etag:
        # Existing blob that has changed, create snapshot/backup
        create_snapshot_backup(blob.name, blob.etag)
    prev_blob_name = blob.name
    prev_blob_etag = blob.etag

Обратите внимание, что только управляемое удостоверение поставщика ADFv2 и управляемое удостоверение функции Azure имеют доступ на запись в этот контейнер. Триггеры BLOB-объектов не работают в этом сценарии, поскольку при изменении BLOB-объектов не запускаются никакие события.

Асинхронное создание инкрементной резервной копии обсуждается в следующей главе.

3. Создание инкрементной резервной копии

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

  • Разверните следующий скрипт как функцию Azure, запускаемую очередью в Python. Можно использовать тот же план службы приложений, что и на шаге 2.
  • Убедитесь, что все необходимые настройки приложения заполнены правильно, см. Здесь
  • Разверните конвейер ADFv2, который создает инкрементные резервные копии путем копирования больших двоичных объектов из исходной учетной записи хранилища в учетную запись хранилища резервных копий.
  • Убедитесь, что вы назначаете Управляемую идентификацию вашей функции Azure и что функция Azure имеет роль RBAC Участник для ее запуска.

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

Работу скрипта QueueCreateBlobBackupADFv2 можно объяснить следующим образом:

  • 2а. Очередь хранилища получает новое сообщение запроса резервного копирования для большого двоичного объекта. Обратите внимание, что сообщения могут обрабатываться параллельно.
  • 2b. Функция Azure забирает сообщение из очереди хранилища и проверяет, не устарел ли запрос на резервное копирование. Затем он запускает конвейер ADFv2, используя REST API и управляемую идентификацию функции Azure.
  • 2c. ADFv2 запускает операцию копирования, копируя большой двоичный объект из исходной учетной записи хранилища в учетную запись хранилища резервных копий.

На шаге 2b также можно решить запустить режим blob_lease, который исключительно блокирует файл и гарантирует, что правильная версия файла будет добавлена ​​в учетную запись хранилища резервных копий. Использование аренды больших двоичных объектов зависит от множества факторов (например, максимально допустимого времени аренды, размера файла, количества заданий, неизменности).

Суть скрипта такова:

USING_BLOB_LEASE = True                       
# check if source blob has not changed in the meantime
if source_blob_changed(blob_name, blob_etag) == True:
    return
# Start copying using ADFv2
try:                               
    if not USING_BLOB_LEASE:
        # Copy without locking the file
        copy_adf_blob_source_backup(blob_name, blob_etag)
    else:      
        # Copy with blob lease locks the file
        copy_with_lease(blob_name, blob_etag)                           except:                               
    logging.info("copy failed")

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

4. Запросы на моментальные снимки / инкрементные резервные копии, запускаемые по времени.

В главе 2 обсуждается, как производитель может создавать моментальные снимки на основе событий / запросы инкрементного резервного копирования. Однако также необходим сценарий согласования, который может создавать отсутствующие снимки состояния и / или отсутствующие резервные копии. Это может произойти, если производитель забывает добавить функцию Azure в свой конвейер приема и / или скрипт не запускается. Для создания функции, основанной на времени, должно быть развернуто следующее:

  • Разверните следующий скрипт как функцию Azure в Python. Можно использовать тот же план службы приложений, что и на шаге 2.
  • Убедитесь, что все необходимые настройки приложения заполнены правильно, см. Здесь

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

Внутреннюю работу скрипта HttpSnapshotIncBackupStorageReconciliation можно объяснить следующим образом:

  • 0. Сценарий инициализации моментального снимка / резервного копирования проверяет наличие измененных / новых больших двоичных объектов в учетной записи хранения, сравнивая ETag большого двоичного объекта с предыдущими снимками (если есть). В случае обнаружения измененного / нового большого двоичного объекта выполняются следующие 2 шага:
  • 1а. В случае обнаружения измененного / нового большого двоичного объекта, у которого еще нет снимка, создается новый снимок:
  • 1b. В случае обнаружения измененного / нового большого двоичного объекта, у которого еще нет инкрементной резервной копии, отправляется сообщение с новым запросом на резервное копирование.

Суть скрипта такова:

# Get all containers in storage account
container_list = client_source.list_containers()
for container in container_list:
    # Get all blobs in container
    prev_blob_name = ""
    prev_blob_etag = ""
    blob_list = container.list_blobs(include=['snapshots'])
    for blob in blob_list:
        if blob.snapshot == None:
            # Blob that is not snapshot
            # 1. Check if snapshot needs to be created
            if prev_blob_name != blob.name: 
                # New blob without snapshot, create snapshot
                create_snapshot(blob.name, blob.etag)
            elif prev_blob_etag != blob.etag:
                # Existing blob that has changed, create snapshot
                create_snapshot(blob.name, blob.etag)
            # 2. Check if incremental backup needs to be created
            # Check if blob exists in backup
            blob_exists = check_blob_exists(blob.name, blob.etag)
            if blob_exists == False:         
                # Not in backup, put backup request message on queue
                queue_json = "{" + "\"container\":\"{}\",
                \"blob_name\":\"{}\", \"etag\":\"{}\""
                .format(container.name, blob.name, blob.etag) + "}"
                queue_service.put_message(queue, queue_json)                

        prev_blob_name = blob.name
        prev_blob_etag = blob.etag

5. Заключение

В службе хранилища Azure всегда хранится несколько копий ваших данных, а геоизбыточное хранилище (GRS) дополнительно хранит копии в парном регионе. Однако хранилище GRS не защищает данные от повреждения из-за ошибок приложения. Поврежденные данные затем просто реплицируются в другие зоны и регионы. Два измерения, которые могут защитить от повреждения данных, следующие:

  • Создание моментального снимка: после добавления или изменения большого двоичного объекта создается моментальный снимок для текущей ситуации.
  • Инкрементное резервное копирование: после добавления или изменения большого двоичного объекта создается инкрементная резервная копия большого двоичного объекта для другой учетной записи хранения.

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