Estrategias de respaldo para el bucket de AWS S3


92

Estoy buscando algún consejo o las mejores prácticas para realizar una copia de seguridad del depósito S3.
El propósito de realizar una 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 borro accidentalmente estos datos de S3

Después de investigar un poco, veo las siguientes opciones:

  1. Utilice el control de versiones http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html
  2. Copie de un bucket de S3 a otro con 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 debo elegir y qué tan seguro sería almacenar datos solo en S3? Quiere escuchar sus opiniones.
Algunos enlaces útiles:


Respuestas:


63

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

Sincronice su bucket de S3 con un servidor EC2 periódicamente

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

s3cmd
Al principio, s3cmdparecía muy prometedor. Sin embargo, después de probarlo en mi enorme cubo S3, no se pudo escalar, con un error de Segmentation fault. Sin embargo, funcionó bien en cubos pequeños. Como no funcionó para cubos enormes, me propuse buscar una alternativa.

s4cmd
La alternativa más nueva de subprocesos múltiples a s3cmd. Sin embargo, parecía aún más prometedor, 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. Debería comprobar si el archivo remoto ya existe localmente (la comprobación de hash / hash estaría bien) 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 este extraño comportamiento. Mientras tanto, me propuse buscar otra alternativa.

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

AWSCLI

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

$ aws s3 sync s3: // nombre-de-tu-depósito / home / ubuntu / s3 / nombre-de-tu-depósito /

Beneficios:

  • Escalable: admite grandes depósitos S3
  • Multi-hilo: sincroniza los archivos más rápido utilizando varios hilos
  • Inteligente: solo sincroniza archivos nuevos o actualizados
  • Rápido: gracias a su naturaleza de subprocesos múltiples y su algoritmo de sincronización inteligente

Eliminación accidental

Convenientemente, el synccomando no eliminará archivos en la carpeta de destino (sistema de archivos local) si faltan en el origen (depósito S3) y viceversa. Esto es perfecto para hacer una copia 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.

Configuración de awscli en Ubuntu 14.04 LTS

Comencemos por instalar awscli. Hay varias formas de hacer esto, sin embargo, me resultó más fácil instalarlo a través de apt-get.

$ sudo apt-get install awscli

Configuración

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

$ aws configure

aws configure

Preparación

Preparemos el directorio de respaldo local de S3, preferiblemente en formato /home/ubuntu/s3/{BUCKET_NAME}. Asegúrese de reemplazarlo {BUCKET_NAME}con el nombre real de su depósito.

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

Sincronización inicial

Sigamos adelante y sincronicemos el depósito 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, awsclicomenzará a descargar el depósito completo en el sistema de archivos local.

Dependiendo del tamaño del depósito y de su conexión a Internet, podría llevar desde unos segundos hasta horas. Cuando termine, seguiremos adelante y configuraremos un trabajo cron automático para mantener actualizada la copia local del depósito.

Configuración de un trabajo cron

Continúe y cree un sync.sharchivo en /home/ubuntu/s3:

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

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

#! / bin / sh

# Hacer eco de la fecha y hora actuales

eco '-----------------------------'
fecha
eco '-----------------------------'
eco ''

# Inicialización del script de eco
echo 'Sincronizando el depósito S3 remoto ...'

# Ejecute el comando de sincronización (reemplace {BUCKET_NAME} con el nombre de su depósito de S3)
/ usr / bin / aws s3 sync s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

# Finalización del guión de eco
echo 'Sincronización completa'

Asegúrese de reemplazar {BUCKET_NAME} con el nombre de su depósito de S3, dos veces a lo largo de la secuencia de comandos.

Consejo profesional: debe usar /usr/bin/awspara vincular al awsbinario, ya que crontabejecuta comandos en un entorno de shell limitado y no podrá encontrar el ejecutable por sí solo.

A continuación, asegúrese de chmodutilizar el script para que pueda ejecutarlo crontab.

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

Intentemos ejecutar el script para asegurarnos de que realmente funcione:

$ /home/ubuntu/s3/sync.sh

La salida debería ser similar a esta:

salida sync.sh

A continuación, editemos el usuario actual crontabejecutando el siguiente comando:

$ crontab -e

Si es la primera vez que lo ejecuta crontab -e, deberá seleccionar un editor preferido. Recomiendo seleccionarlo nanoya que es el más fácil de trabajar para los principiantes.

Frecuencia de sincronización

Necesitamos decir con crontabqué frecuencia ejecutar nuestro script y dónde reside el script en el sistema de archivos local escribiendo un comando. El formato de este comando es el siguiente:

comando mh dom mon dow

El siguiente comando se configura crontabpara ejecutar el sync.shscript cada hora (especificado mediante los parámetros minuto: 0 y hora: *) y para que canalice la salida del script a un sync.logarchivo en nuestro s3directorio:

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

Debe agregar esta línea al final del crontabarchivo que está editando. Luego, continúe y guarde el archivo en el disco presionando Ctrl + W y luego Enter . A continuación, puede salir nanopulsando Ctrl + X . crontabahora ejecutará la tarea de sincronización cada hora.

Consejo profesional: puede verificar que el trabajo cron por hora se esté ejecutando con éxito 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 bucket de 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 bucket de S3 crece, es posible que deba aumentar el tamaño del volumen de EBS de su servidor EC2 para dar cabida a nuevos archivos. Siempre puede aumentar el tamaño de su volumen de EBS siguiendo esta guía .


Dejé una pregunta en tu blog, pero me preguntaba si también hay alguna forma de sincronizar los metadatos.
Devology Ltd

@Devology Ltd, Desafortunadamente no he tenido la oportunidad de trabajar con metadatos de objetos de S3. De una búsqueda rápida en Google, no parece que el awsclisoporte sincronice esto automáticamente en el aws s3 synccomando. Parece que debe implementar esto manualmente.
Elad Nava

Gracias @Ekad Nava. Le agradezco que confirme lo que yo creía que era el caso.
Devology Ltd

1
Esto es fantástico @EladNava, gracias por compartir, ¡sigue siendo relevante en 2020!
user1130176

esta respuesta no encaja, cuando tiene millones de archivos. Se vuelve muy costoso, lento y, a veces, imposible, debido a los límites del sistema de archivos.
Psicozoico

30

Teniendo en cuenta el enlace relacionado, que explica que S3 tiene una durabilidad del 99,999999999%, descartaría su preocupació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ía con las opciones n. ° 1 o n. ° 3. ¿Cual de ellos? Realmente depende de algunas preguntas:

  • ¿Necesita alguna otra de las funciones de control de versiones o es solo para evitar sobrescrituras / eliminaciones accidentales?
  • ¿Es asequible el coste adicional que impone el control de versiones?
  • 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 enorme, me quedaría con el control de versiones de cubos. De esta manera, no necesitará ningún código / flujo de trabajo adicional para hacer una copia de seguridad de los datos en Glacier, en otros depósitos o incluso en cualquier otro servidor (que es realmente una mala elección en mi humilde opinión, olvídese).


4
@SergeyAlekseev Si Glacier es algo que funcionará para usted, es muy rápido configurar una regla de ciclo de vida en un depósito que archiva automáticamente sus archivos en glacier. Seguirán apareciendo en un depósito (en la interfaz de usuario web), pero la clase de almacenamiento cambiará de estándar a glaciar. Muevo archivos procesados ​​de mi depósito principal a un depósito "hecho", y el depósito hecho tiene la regla del ciclo de vida que archiva cualquier cosa que tenga más de 1 día de antigüedad. Estos son archivos de datos que probablemente nunca volveré a tocar, pero que debo guardar para el cliente.
Dan

28
No creo que el 99,999999999% sea una buena razón para tener una pila completa de AWS en el almacenamiento / copia de seguridad. No me refiero al 0,0000000001% restante, pero más si ocurre algo muy inesperado, se siente incómodo tener todo tu negocio en alguna parte. De forma inesperada, podría ser que EE. UU. Vaya a la guerra a un país específico, Amazon sea completamente pirateado (ver Sony), etc., etc.
Augustin Riedinger

11
Respaldaré a @AugustinRiedinger en este caso: "Problema de S3" puede ser, por definición, algo que no conoces (por ejemplo, problemas gubernamentales) que podría invalidar las hipótesis en las que se basan los números de SLA de S3 como 99,99 ... Al hacer algo a largo plazo, incluida la copia de seguridad de sus datos, la diversificación es una buena práctica, si no debería ser un requisito previo
lajarre

2
Definitivamente estoy de acuerdo en que tus puntos son válidos. Pero según las opciones que ofrece el OP (casi todas, incluidas las alternativas de AWS al problema), no creo que el "problema de S3" sea tan amplio como ustedes se están expandiendo. Sin embargo, es bueno ver algunos pensamientos más amplios.
Viccari

4
Respuesta anterior, pero siento que necesito mencionar eventos recientes (-ish). "El día que Amazon rompió la web", un técnico borró accidentalmente una gran parte de sus servidores S3. Incluso durante esas 24 horas, el problema fue la accesibilidad. No pérdida de datos. No hubo absolutamente ninguna pérdida de datos, incluso dada la gran cantidad de servidores que se eliminaron, y aún así lograron cumplir con su SLA
Oberst

14

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

  1. Programe el proceso de copia de seguridad mediante la tubería de datos de AWS; se puede realizar de las 2 formas mencionadas a continuación:

    a. Utilizando copyActivity de la tubería de datos con la que puede copiar de un depósito s3 a otro depósito s3.

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

  2. Utilice el control de versiones dentro del depósito S3 para mantener una versión diferente de los datos

  3. Use glacier para hacer una copia de seguridad de sus datos (utilícelo cuando no necesite restaurar rápidamente la copia de seguridad a los depósitos originales (se necesita algún tiempo para recuperar los datos de glacier ya que los datos se almacenan en formato comprimido) o cuando desee guardar algunos costos al evitar usar otro bucket de s3 para la copia de seguridad), esta opción se puede configurar fácilmente usando la regla del ciclo de vida en el bucket de s3 para el que desea realizar una copia de seguridad.

La opción 1 puede brindarle más seguridad, por ejemplo, en caso de que elimine accidentalmente su depósito s3 original y otro beneficio es que puede almacenar su copia de seguridad en carpetas con fecha en otro depósito s3, de esta manera sabrá qué datos tenía en una fecha en particular y puede restaurar una copia de seguridad de una fecha específica. Todo depende de tu caso de uso.


@David: Como David sugirió en su solución a continuación, que podría haber un script que haga una copia de seguridad del cubo s3 diaria o semanalmente. Esto se puede lograr fácilmente en mi primer punto (AWS datapipeline, que le brinda la posibilidad de programar el proceso de copia de seguridad diariamente , semanal, etc.). Recomendaría realizar una búsqueda en la tubería de datos de AWS.
Varun

Esto parece prometedor, porque no se basa en enfoques anticuados que no sobresalen en aprovechar al máximo la nube (léase: crons). Data Pipeline también tiene reintentos automatizados y es un servicio administrado (sin servidor).
Felipe Alvarez

13

¿Qué tal si se utiliza la función de replicación entre regiones disponible en los depósitos de S3? Aquí hay algunos artículos útiles sobre la función.


¿Qué sucede si elimina un archivo en una región que no debería replicarse en la otra?
michelem

S3 no replica las eliminaciones, consulte este enlace docs.aws.amazon.com/AmazonS3/latest/dev/… .
ᐅ devrimbaris

9

Pensaría que a estas alturas ya habría una forma más fácil de simplemente mantener algún tipo de copias de seguridad incrementales en una región diferencial.

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

Para mí, la mejor solución sería un script que simplemente haga una copia de seguridad de un depósito en otra región, una diaria y otra semanal, de modo que si sucede algo terrible, simplemente pueda cambiar de región. No tengo una configuración como esta, he investigado, pero no he podido hacerlo porque tomaría un poco de esfuerzo hacerlo, por lo que desearía que hubiera alguna solución estándar para usar.


Convenido. Es interesante que cuando profundiza en S3 (incluso CRR - replicación incorporada) hay grandes agujeros para la recuperación de desastres. Por ejemplo, no puede restaurar nunca un depósito, los historiales de versiones de archivos, los metadatos (especialmente las últimas fechas de modificación), etc. Todos los escenarios de recuperación actualmente disponibles son recuperaciones parciales.
Paul Jowett

7

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

  1. Eliminación permanente de versiones de objetos: habilite la eliminación de MFA en el control de versiones del depósito.

  2. Eliminación accidental del depósito en sí: configure una política de depósito que niegue la eliminación sin autenticación MFA.

Combine la replicación y el control de versiones entre 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.


0

Si, tenemos demasiados datos. Si ya tiene un cubo, la primera vez que la sincronización llevará demasiado tiempo. En mi caso, tenía 400 GB. Tomó 3 horas la primera vez. Así que creo que podemos hacer que la réplica sea una buena solución para la copia de seguridad de S3 Bucket.


Estoy a punto de mover unos 7 TB en un cubo y estoy tratando de encontrar la mejor opción ... Creo que necesito algo mejor que la sincronización. Me pregunto si el uso de una tubería para copiar datos a la versión GCS de glacier podría ofrecer la mejor seguridad general.
Brendon Whateley

AWS DataSync podría ser una opción aquí.
Felipe Alvarez
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.