it-swarm.com.ru

Каков наилучший способ резервного копирования содержимого хранилища BLOB-объектов Azure

Я знаю, что объекты хранилища Azure (большие двоичные объекты, таблицы и очереди) имеют встроенную отказоустойчивость, что означает, что они реплицируются на 3 разных сервера в одном центре данных. Кроме того, они также могут быть полностью скопированы в другой центр обработки данных, который физически расположен в другом географическом регионе. Вероятность потери ваших данных в этом случае близка к нулю для всех практических целей.

Однако что произойдет, если неаккуратный разработчик (или тот, кто находится под влиянием алкоголя :)) случайно удалит учетную запись хранения через портал Azure или инструмент обозревателя хранилищ Azure? Что еще хуже, что если хакер завладеет вашей учетной записью и очистит хранилище? Есть ли способ восстановить гигабайты удаленных BLOB-объектов или это так? Каким-то образом я думаю, что здесь должно быть элегантное решение, которое предоставляет инфраструктура Azure, но я не могу найти никакой документации.

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

С Уважением,

Леканора

37
Archil Kublashvili

В зависимости от того, где вы хотите сделать резервную копию ваших данных, доступны две опции:

  1. Локальное резервное копирование данных. Если вы хотите выполнять локальное резервное копирование данных в своей инфраструктуре, вы можете: A. Напишите свое собственное приложение, используя либо клиентскую библиотеку хранилища, либо используя REST API или B. Используйте сторонние инструменты, такие как Командлеты управления Cerebrata Azure (Раскрытие информации: я работаю для Cerebrata). 

  2. Резервное копирование данных в облаке. Недавно группа хранения Windows Azure анонсировала функциональность асинхронного большого двоичного объекта, которая по существу позволит вам копировать данные из одной учетной записи хранения в другую, не загружая данные локально. Суть в том, что ваша целевая учетная запись хранения должна быть создана после 7 июня 2012 года. Подробнее об этой функции можно прочитать в блоге Windows Azure: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/06. /12/introduction-asynchronous-cross-account-copy-blob.aspx .

Надеюсь это поможет.

24
Gaurav Mantri

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

Я собрал решение, которое сейчас использую в производстве. Я раскрываю метод от Backup() до Web Api, который затем вызывается Azure WebJob каждый день (в полночь).

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

  • это не было актуально, поэтому я изменил несколько имен методов
  • добавлена ​​защита операции повторного копирования (не удается после 4 попыток для одного и того же большого двоичного объекта)
  • добавлено немного ведения журнала - вы должны поменять его со своим.
  • выполняет резервное копирование между двумя учетными записями (репликация контейнеров и BLOB-объектов)
  • добавлена ​​очистка - он удаляет старые ненужные контейнеры (сохраняет данные за 16 дней). Вы всегда можете отключить это, так как пространство дешево.

источник можно найти по адресу: https://github.com/ChrisEelmaa/StackOverflow/blob/master/AzureStorageAccountBackup.cs

и вот как я использую его в контроллере (обратите внимание, что ваш контроллер должен вызываться только веб-заданием Azure - вы можете проверить учетные данные в заголовках):

[Route("backup")]
[HttpPost]
public async Task<IHttpActionResult> Backup()
{
    try
    {
        await _blobService.Backup();
        return Ok();
    }
    catch (Exception e)
    {
        _loggerService.Error("Failed to backup blobs " + e);
        return InternalServerError(new Exception("Failed to back up blobs!"));
    }
}

примечание: я хотел добавить этот код как часть поста, но потратил впустую 6 минут, пытаясь вставить этот код в этот пост, но не смог. форматирование вообще не сработало и полностью сломалось.

4
Erti-Chris Eelmaa

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

  1. Мягкое удаление для BLOB-объектов хранилища Azure Сначала лучше включить мягкое удаление, которое теперь находится в GA: https://Azure.Microsoft.com/en-us/blog/soft -delete-for-Azure-хранилище-blobs-ga

  2. Доступ для чтения с гео-избыточным хранилищем Второй подход - включить гео-репликацию для RA-RGA, поэтому, если первый центр обработки данных не работает, вы всегда можете прочитать из вторичной реплики в другом регионе, вы можете найти больше информации здесь: https://docs.Microsoft.com/en-us/Azure/storage/common/storage-redundancy-grs

1
Anass Kartit

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

https://docs.Microsoft.com/en-us/Azure/storage/storage-blob-snapshots

Снимок - это версия блоба, доступная только для чтения, которая берется в точке в время. Снимки полезны для резервного копирования BLOB-объектов. После создания снимок, вы можете прочитать, скопировать или удалить его, но вы не можете изменить его. + Снимок BLOB-объекта идентичен его базовому объекту, за исключением того, что URI блоба имеет значение DateTime, добавленное к URI блоба для обозначения время, когда был сделан снимок. Например, если URI блоба страницы is http://storagesample.core.blob.windows.net/mydrives/myvhd , URI снимка похож на http://storagesample.core.blob.windows.net/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000Z .

0
TWilly