services glacier costo aws amazon-web-services amazon-s3 backup amazon-glacier

amazon-web-services - glacier - aws calculator



Estrategias de respaldo para el cubo AWS S3 (6)

Originalmente publicado en mi blog: http://eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/

Sincronice su cubo S3 a un servidor EC2 periódicamente

Esto se puede lograr fácilmente mediante la utilización de múltiples utilidades de línea de comandos que hacen posible sincronizar un depósito S3 remoto con el sistema de archivos local.

s3cmd
Al principio, s3cmd parecía extremadamente prometedor. Sin embargo, después de probarlo en mi enorme cubo S3, no logró escalar, y se saltó con un Segmentation fault . Sin embargo, funcionó bien en pequeños cubos. Dado que no funcionó para grandes cubos, me puse a buscar una alternativa.

s4cmd
La alternativa más nueva y multihilo a s3cmd . Parecía incluso más prometedor, sin embargo, noté que seguía volviendo a descargar archivos que ya estaban presentes en el sistema de archivos local. Ese no es el tipo de comportamiento que esperaba del comando de sincronización. Debe verificar si el archivo remoto ya existe localmente (la comprobación de hash / filesize sería clara) y omitirlo en la próxima ejecución de sincronización en el mismo directorio de destino. Abrí un problema ( bloomreach/s4cmd/#46 ) para informar sobre este extraño comportamiento. Mientras tanto, me puse a buscar otra alternativa.

awscli
Y luego encontré awscli . Esta es la interfaz de línea de comando oficial de Amazon para interactuar con sus diferentes servicios en la nube, incluido S3.

Proporciona un útil comando de sincronización que descarga rápida y fácilmente los archivos del cubo remoto a su sistema de archivos local .

$ aws s3 sync s3://your-bucket-name /home/ubuntu/s3/your-bucket-name/

Beneficios:

  • Escalable: admite enormes cubos S3
  • Multihebra: sincroniza los archivos más rápido al utilizar múltiples hilos
  • Inteligente: solo sincroniza archivos nuevos o actualizados
  • Rápido - gracias a su naturaleza multihilo y al algoritmo de sincronización inteligente

Eliminación accidental

Convenientemente, el comando de sync no eliminará archivos en la carpeta de destino (sistema de archivos local) si faltan en el origen (segmento S3) y viceversa. Esto es perfecto para realizar copias de seguridad de S3, en caso de que los archivos se eliminen del depósito, volver a sincronizarlos no los eliminará localmente. Y en caso de que elimine un archivo local, tampoco se eliminará del depósito de origen.

Configurando awscli en Ubuntu 14.04 LTS

Comencemos instalando awscli . Hay varias maneras de hacerlo, sin embargo, me pareció más fácil de instalar a través de apt-get .

$ sudo apt-get install awscli

Configuración

A continuación, debemos configurar awscli con nuestra Clave de acceso, ID y clave secreta, que debe obtener de IAM , creando un usuario y adjuntando la política de AmazonS3ReadOnlyAccess . Esto también evitará que usted o cualquiera que obtenga acceso a estas credenciales elimine sus archivos S3. Asegúrese de ingresar su región S3, como us-east-1 .

$ aws configure

Preparación

/home/ubuntu/s3/{BUCKET_NAME} directorio de respaldo S3 local, preferiblemente en /home/ubuntu/s3/{BUCKET_NAME} . Asegúrate de reemplazar {BUCKET_NAME} con tu nombre real de depósito.

$ mkdir -p /home/ubuntu/s3/{BUCKET_NAME}

Sincronización inicial

Avancemos y sincronicemos la cubeta por primera vez con el siguiente comando:

$ aws s3 sync s3://{BUCKET_NAME} /home/ubuntu/s3/{BUCKET_NAME}/

Suponiendo que el depósito existe, las credenciales y la región de AWS son correctas, y la carpeta de destino es válida, awscli comenzará a descargar todo el depósito al sistema de archivos local.

Dependiendo del tamaño del cucharón y su conexión a Internet, podría tomar desde unos segundos hasta horas. Una vez hecho esto, procederemos a configurar un trabajo cron automático para mantener actualizada la copia local del depósito.

Configurando un trabajo Cron

sync.sh y crea un archivo sync.sh en /home/ubuntu/s3 :

$ nano /home/ubuntu/s3/sync.sh

Copie y pegue el siguiente código en sync.sh :

#!/bin/sh # Echo the current date and time echo ''-----------------------------'' date echo ''-----------------------------'' echo '''' # Echo script initialization echo ''Syncing remote S3 bucket...'' # Actually run the sync command (replace {BUCKET_NAME} with your S3 bucket name) /usr/bin/aws s3 sync s3://{BUCKET_NAME} /home/ubuntu/s3/{BUCKET_NAME}/ # Echo script completion echo ''Sync complete''

Asegúrese de reemplazar {BUCKET_NAME} con su nombre de depósito S3, dos veces a lo largo del script.

Sugerencia: debe usar /usr/bin/aws para vincular al binario de aws , ya que crontab ejecuta comandos en un entorno de shell limitado y no podrá encontrar el ejecutable por sí mismo.

A continuación, asegúrese de chmod el script para que pueda ejecutarse mediante crontab .

$ sudo chmod +x /home/ubuntu/s3/sync.sh

Intentemos ejecutar el script para asegurarnos de que realmente funciona:

$ /home/ubuntu/s3/sync.sh

El resultado debería ser similar a esto:

A continuación, editemos el crontab del usuario actual ejecutando el siguiente comando:

$ crontab -e

Si esta es la primera vez que ejecuta crontab -e , tendrá que seleccionar un editor preferido. Recomiendo seleccionar nano ya que es el más fácil para los principiantes para trabajar.

Frecuencia de sincronización

Necesitamos contar a crontab qué frecuencia ejecutar nuestro script y dónde reside el script en el sistema de archivos local escribiendo un comando. El formato para este comando es el siguiente:

m h dom mon dow command

El siguiente comando configura crontab para ejecutar el script sync.sh cada hora (especificado a través de los parámetros minute: 0 y hour: *) y para que sync.log la salida del script a un archivo sync.log en nuestro directorio s3 :

0 * * * * /home/ubuntu/s3/sync.sh > /home/ubuntu/s3/sync.log

Debe agregar esta línea al final del archivo crontab que está editando. Luego, adelante y guarde el archivo en el disco presionando Ctrl + W y luego Enter . Luego puede salir de nano presionando Ctrl + X. crontab ahora ejecutará la tarea de sincronización cada hora.

Sugerencia: puede verificar que el trabajo cron por hora se ejecute correctamente inspeccionando /home/ubuntu/s3/sync.log , verificando su contenido para la fecha y hora de ejecución, e inspeccionando los registros para ver qué archivos nuevos se han sincronizado .

¡Todo listo! Su cubo S3 ahora se sincronizará con su servidor EC2 cada hora automáticamente, y debería estar listo para comenzar. Tenga en cuenta que con el tiempo, a medida que su segmento S3 crezca, es posible que tenga que aumentar el tamaño del volumen EBS de su servidor EC2 para acomodar archivos nuevos. Siempre puede aumentar el tamaño de su volumen EBS siguiendo esta guía .

Estoy buscando algunos consejos o mejores prácticas para hacer una copia de seguridad del cubo S3.
El propósito de la copia de seguridad de los datos de S3 es evitar la pérdida de datos debido a lo siguiente:

  1. Problema S3
  2. problema donde elimino accidentalmente estos datos de S3

Después de algunas investigaciones, veo las siguientes opciones:

  1. Utilice el control de versiones http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html
  2. Copie de un depósito S3 a otro usando AWS SDK
  3. Copia de seguridad en Amazon Glacier http://aws.amazon.com/en/glacier/
  4. Copia de seguridad en el servidor de producción, que a su vez está respaldado

¿Qué opción debería elegir y qué tan seguro sería almacenar datos solo en S3? ¿Quieres escuchar tus opiniones?
Algunos enlaces útiles:

Pensarías que ahora habría una forma más fácil de mantener algún tipo de copias de seguridad incrementales en una región de diferencias.

Todas las sugerencias anteriores no son realmente soluciones simples o elegantes. Realmente no considero la opción de glaciar, ya que creo que es más una solución de archivo que una solución de respaldo. Cuando pienso en la copia de respaldo, creo que la recuperación ante desastres de un desarrollador junior elimina de forma recursiva un depósito o quizás un exploit o error en su aplicación que elimina cosas de s3.

Para mí, la mejor solución sería una secuencia de comandos que simplemente haga una copia de seguridad de un segmento en otra región, una por día y otra por semana, de modo que si sucede algo terrible, simplemente puede cambiar de región. No tengo una configuración como esta, la he investigado simplemente porque no me ha costado hacer eso porque me tomaría un poco de esfuerzo hacer esto, y es por eso que desearía que hubiera alguna solución estándar para usar.

Puede hacer una copia de seguridad de sus datos S3 utilizando los siguientes métodos

  1. Programe el proceso de copia de seguridad utilizando AWS datapipeline, se puede hacer de 2 maneras mencionadas a continuación:

    a. Usando copyActivity de datapipeline con el que puede copiar de un depósito s3 a otro cubo s3.

    segundo. Usar ShellActivity de datapipeline y comandos "S3distcp" para hacer la copia recursiva de las carpetas s3 recursivas de un depósito a otro (en paralelo).

  2. Utilice el control de versiones dentro del depósito S3 para mantener diferentes versiones de datos

  3. Use glacier para hacer una copia de seguridad de sus datos (úselo cuando no necesite restaurar la copia de seguridad rápidamente a los contenedores originales (toma tiempo recuperar los datos del glaciar ya que los datos se almacenan en formato comprimido) o cuando desea guardarlos algún costo al evitar el uso de otro depósito de s3 para la copia de seguridad), esta opción se puede configurar fácilmente utilizando la regla del ciclo de vida en el segmento s3 del que desea realizar la copia de seguridad.

La opción 1 puede brindarle más seguridad, por favor, deje en caso de que elimine accidentalmente su cubo s3 original y otro beneficio es que puede almacenar su copia de seguridad en carpetas datewise en otro cubo s3, de esta manera usted sabe qué datos tenía en una fecha determinada y puede restaurar una copia de seguridad de fecha específica. Todo depende de tu caso de uso.

Si bien esta pregunta se publicó hace algún tiempo, pensé que era importante mencionar la protección de eliminación de MFA con las otras soluciones. El OP intenta resolver la eliminación accidental de datos. La autenticación de múltiples factores (MFA) se manifiesta en dos escenarios diferentes aquí:

  1. Eliminar permanentemente las versiones de objetos: habilite eliminar MFA en el control de versiones del depósito.

  2. Eliminar accidentalmente el depósito en sí mismo: configure una política de depósito que niegue la eliminación sin autenticación MFA.

Combinar con replicación y versioning de versioning regiones para reducir el riesgo de pérdida de datos y mejorar los escenarios de recuperación.

Aquí hay una publicación de blog sobre este tema con más detalles.

Teniendo en cuenta el enlace relacionado, que explica que S3 tiene 99.99999999% de durabilidad, descartaría su preocupación n. ° 1. Seriamente.

Ahora, si el n. ° 2 es un caso de uso válido y una preocupación real para usted, definitivamente me quedaré con las opciones n. ° 1 o n. ° 3. ¿Cual de ellos? Realmente depende de algunas preguntas:

  • ¿Necesita alguna otra característica de control de versiones o solo para evitar sobreescrituras / eliminaciones accidentales?
  • ¿El costo adicional impuesto por el control de versiones es asequible?
  • Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. ¿Esto está bien para ti?

A menos que su uso de almacenamiento sea realmente grande, me quedaría con el control de versiones del cubo. De esta forma, no necesitará ningún código / flujo de trabajo adicional para realizar copias de seguridad de datos en Glacier, en otros sectores o incluso en ningún otro servidor (lo cual es realmente una mala opción en mi humilde opinión, olvídese de ello).