Este es un consejo específico de MySQL:
Uno de los mayores problemas con un enfoque que no es EBS es el tiempo que lleva restaurar desde una copia de seguridad. Si está utilizando MySQLDump, puede llevar días o incluso semanas restaurar un conjunto de datos de varios terabytes, incluso en un c1.xlarge, incluso después de haberlo descargado. (Gunzip tomará mucho tiempo y luego tendrás que ejecutar SQL para cada registro). Esto se aplica no solo a la restauración, sino también a la puesta en línea de nuevos esclavos.
Una forma de evitar esto, si está utilizando MyISAM, es hacer una copia de seguridad de los archivos individuales .MYD, .MYI y .FRM en los directorios de la biblioteca MySQL directamente en S3. Aún mejor, no los comprima y use la carga y descarga de varias partes (ambas compatibles con S3, pero no muchas aplicaciones de S3 las usan; tuvimos que escribir nuestra propia biblioteca para hacer esto). No conozco una forma más rápida de hacer las cosas. Y esto es mucho más barato que usar EBS para un conjunto de datos de varios terabytes.
- Cómo ser bueno en informática distribuida
- ¿Dailymotion Cloud es caro para un sitio de intercambio de videos muy grande?
- Ahora tengo un nombre de dominio y quiero actualizar algunos archivos HTML en él. ¿Puedo asociarlo con una instancia de AWS sin usar IP elástica en AWS?
- ¿Cómo llega Vader a la ciudad de nubes antes del Halcón?
- Computación en la nube: ¿Cuál es la diferencia entre una nube y un servidor? ¿Puede el servidor ser una nube y viceversa?
El problema, entonces, es con sus tablas InnoDB. Tendrá que usar MySQLDump para estos, así que asegúrese de archivar datos en tablas MyISAM y, en general, mantenerlos lo más pequeños posible
Por cierto, ¡nunca subestimes el valor de un buen RAID! Realmente hace una diferencia cuando pones 8 volúmenes EBS uno al lado del otro con RAID 0. Pero sí, el almacenamiento fue, es y siempre será un cuello de botella doloroso. 
