2012-07-19 11 views
29

Sé que las entidades de almacenamiento de Azure (blobs, tablas y colas) tienen una resistencia incorporada, lo que significa que se replican en 3 servidores diferentes en el mismo centro de datos. Además de eso, también pueden ser replicados en un centro de datos diferente que se encuentra físicamente en una región geográfica diferente. La posibilidad de perder sus datos en este caso es casi cero para todos los propósitos prácticos.¿Cuál es la mejor manera de hacer una copia de seguridad del contenido de Azure Blob Storage?

Sin embargo, ¿qué sucede si un desarrollador descuidado (o el que está bajo la influencia del alcohol :)) elimina accidentalmente la cuenta de almacenamiento a través del Portal Azure o la herramienta Azure Storage Explorer? Lo peor, ¿qué pasa si un hacker se apodera de su cuenta y borra el almacenamiento? ¿Hay alguna manera de recuperar los gigabytes de blobs eliminados o es eso? De alguna manera, creo que tiene que haber una solución elegante que la infraestructura de Azure proporciona aquí, pero no puedo encontrar ninguna documentación.

La única solución que puedo pensar es escribir mi propio proceso (función de trabajador) que periódicamente realiza una copia de seguridad de todo mi almacenamiento en una suscripción/cuenta diferente, lo que básicamente duplica el costo de almacenamiento y transacciones. ¿Alguna idea?

Saludos,

archil

Respuesta

19

Dependiendo de donde desea copia de seguridad de los datos, hay dos opciones disponibles:

  1. Copia de seguridad de datos a nivel local - Si desea una copia de seguridad de datos localmente en su infraestructura, usted podría: a. Escriba su propia aplicación usando Storage Client Library o consumiendo REST API o b. Use herramientas de terceros como Cerebrata Azure Management Cmdlets (Divulgación: yo trabajo para Cerebrata).

  2. Copia de seguridad de datos en la nube: Recientemente, el equipo de Almacenamiento de Windows Azure anunció la funcionalidad Asynchronous Copy Blob que básicamente le permitirá copiar datos de una cuenta de almacenamiento a otra sin descargar los datos localmente. La clave aquí es que su cuenta de almacenamiento objetivo debe crearse después del 7 de junio de 2012. Puede leer más acerca de esta funcionalidad en el Blog de Windows Azure: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/06/12/introducing-asynchronous-cross-account-copy-blob.aspx.

Espero que esto ayude.

+1

Me he enfrentado a este problema exacto y una copia de seguridad con el cliente de almacenamiento .net. Si lo estuviese escribiendo de nuevo hoy, usaría Asynchonous Copy Blob, mucho más rápido. – knightpfhor

+0

Los cmdlets de administración de Cerebrata Azure parecen descontinuados – TWilly

+0

[Gaurav Mantri] (https://stackoverflow.com/users/188096/gaurav-mantri) El enlace de la primera opción ya no funciona. – SashaPinsk

4

La respuesta aceptada está bien, pero me llevó algunas horas descifrar todo.

He creado una solución que utilizo ahora en producción. Expongo el método Backup() a través de Web Api que luego se llama por Azure WebJob todos los días (a la medianoche).

Tenga en cuenta que me he tomado el código fuente original, y lo modificó:

  • que no están al día así que cambié algunos nombres de los métodos
  • añadido operación de copia de reintento guardia de seguridad (se falla después de 4 intentos para el mismo blob)
  • agregué un poco de registro - debería cambiarlo por el suyo.
  • hace la copia de seguridad entre dos cuentas de almacenamiento (replicantes contenedores & gotas)
  • añaden purga - se deshace envases viejos que no son necesarios (mantiene 16 días de datos).siempre puedes desactivar esto, ya que el espacio es barato.

la fuente se puede encontrar en: https://github.com/ChrisEelmaa/StackOverflow/blob/master/AzureStorageAccountBackup.cs

y así es como lo uso en el controlador (tenga en cuenta su controlador debe ser exigible por la webjob azul - se puede comprobar las credenciales de los encabezados):

[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!")); 
    } 
} 

nota: yo quería añadir este código como parte del post, pero perdió 6 minutos tratando de conseguir que el código en este post, pero fracasó. el formateo no funcionó en absoluto, y se rompió por completo.

+0

Los nombres de las claves de metadatos ya no pueden contener "-". Si cambia el nombre a "CreateAt" y "BackupOf" todo funciona bien. – PMerlet

0

Puede hacer una instantánea de un contenedor de blog y luego descargar la instantánea de una copia de seguridad puntual.

https://docs.microsoft.com/en-us/azure/storage/storage-blob-snapshots

Una instantánea es una versión de sólo lectura de una burbuja que se toma en un punto en el tiempo . Las instantáneas son útiles para hacer copias de seguridad de blobs. Después de crear una instantánea , puede leerla, copiarla o eliminarla, pero no puede modificarla. + Una instantánea de un blob es idéntica a su blob base, excepto que el URI blob tiene un valor DateTime adjunto al URI de blob para indicar el tiempo al que se tomó la instantánea. Por ejemplo, si un URI de blob de página es http://storagesample.core.blob.windows.net/mydrives/myvhd, el URI de instantánea es similar a http://storagesample.core.blob.windows.net/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000Z.

Cuestiones relacionadas