Cómo elegir un servicio en la nube para copias de seguridad

Estoy pensando en usar un servicio en la nube para hacer una copia de seguridad del sitio web de mi cliente.

Mis principales preocupaciones (clientes) son (en orden decreciente de importancia)

1. Protección de IP (secretos comerciales, código fuente), detalles de cuenta de usuario, etc.
2. Garantía de tiempo de actividad ofrecida por el proveedor de servicios (para minimizar los tiempos de inactividad del servidor web)
3. Costo
4. Velocidades de carga / descarga

Idealmente, me gustaría un servicio que no tenga un vínculo prolongado (es decir, preferiría un tipo de servicio de "pago por uso")

También me gustaría evitar el bloqueo del proveedor, donde es casi imposible pasar a otro servicio.

Me gustaría algunas pautas generales sobre:

1. Cómo elegir un proveedor de servicios
2. ¿Quiénes son los principales jugadores en el campo?
3. Recomendación de software a utilizar para: copia de seguridad / restauración / y carga / descarga de los archivos guardados / restaurados

El software del servidor será Ubuntu o Debian (probablemente publicaré una pregunta sobre qué SO elegir como servidor, ya estoy familiarizado con Ubuntu)

Cualquier solución que no incluya el cifrado en el lado del cliente con las claves en poder del propietario no va a cumplir con el primer requisito establecido (protección / seguridad de IP): cualquier pirateo del lado del servidor revela datos sin cifrar. Esto descarta los sistemas de sincronización en la nube, como Dropbox, que posee las claves.

Para evitar alojar las claves de cifrado más importantes en el servidor del sitio web, que también es probable que sea pirateado en algún momento, esto es lo que haría:

1. Servidor de respaldo interno en el propio sitio del cliente: tiene claves de cifrado y claves SSH para los otros dos servidores
2. Servidor que aloja el sitio web: podría ser un host web
3. Servidor o servicio de respaldo en la nube

Paso 1: el servidor (1) extrae la copia de seguridad de (2), por lo que la mayoría de los hacks del servidor del sitio web no comprometerán las copias de seguridad. El cifrado tiene lugar en este punto.

• Me gustaría utilizar rsnapshot a través de SSH usando inicio de sesión basado en clave, ya que esto tiene unos requisitos mínimos sobre la red de acogida e internos servidor de copia de seguridad - a menos que tenga una gran base de datos de copia de seguridad es muy eficiente en ancho de banda y almacena varias versiones del sitio, y también maneja la purga de copias de seguridad antiguas.
• El cifrado puede hacerse mediante cualquier herramienta de archivo a archivo, como GPG, copiando el árbol rsnapshot a otro árbol, o puede usar la duplicidad para el paso 2, ahorrando espacio en el disco.
• "Extraer" del servidor de respaldo es importante: si el servidor principal (2) tiene las contraseñas / claves para el servidor de respaldo, los piratas informáticos pueden y, a veces, eliminarán los respaldos después de piratear el servidor principal (ver más abajo). Los hacks realmente avanzados pueden instalar binarios SSH troyanos que luego podrían comprometer el servidor de respaldo, pero eso es menos probable para la mayoría de las empresas.

Paso 2: el servidor (1) empuja las copias de seguridad cifradas a (3) para que haya una copia de seguridad externa. Si las copias de seguridad se cifraron en el paso 1, puede usar un espejo rsync del árbol de rsnapshot local para el sistema remoto.

• La duplicidad sería una buena opción para encriptar y respaldar directamente el árbol rsnapshot sin cifrar en el servidor remoto. Las características de Duplicity son un poco diferentes a rsnapshot, ya que utiliza archivos tar cifrados con GPG, pero proporciona cifrado de respaldo en el host remoto y solo requiere SSH en ese host (o puede usar Amazon S3). Duplicity no admite enlaces duros , por lo que si es necesario (por ejemplo, para una copia de seguridad completa del servidor), es mejor si un script convierte el árbol rsnapshot (que admite enlaces duros) en un archivo tar (tal vez solo los archivos que tienen> 1 enlace duro, que será bastante pequeño) para que la duplicidad pueda hacer una copia de seguridad del archivo tar.
• Dado que el servidor remoto es solo un host SSH, posiblemente con rsync, podría ser un host web (pero de un proveedor de alojamiento diferente y en una parte diferente del país), o un servicio en la nube que proporciona rsync y / o SSH. esta respuesta en las copias de seguridad de rsync a la nube por su recomendación de bqbackup y rsync.net, aunque no estoy de acuerdo con la configuración de copia de seguridad mencionada.
• Puede usar Amazon S3 como servidor remoto con duplicidad, lo que le daría una disponibilidad realmente buena, aunque tal vez le costaría más para copias de seguridad grandes.
• Otras opciones para copias de seguridad cifradas remotas son Boxbackup (no tan maduro, algunas características agradables) y Tarsnap (servicio en la nube comercial basado en Amazon S3 con interfaz de línea de comandos simple, buena deduplicación y cifrado muy completo).
  • JungleDisk puede ser una opción, pero no he tenido una gran experiencia con ellos en el pasado y su cifrado tiene algunos problemas (del autor de Tarsnap).

La seguridad de todos los distintos hosts es importante, por lo que debe ajustarse para cumplir con el perfil de seguridad del cliente, es decir, analizar las amenazas, los riesgos, los vectores de ataque, etc. Ubuntu Server no es un mal comienzo ya que tiene actualizaciones de seguridad frecuentes para 5 años, pero se requiere atención a la seguridad en todos los servidores.

Esta configuración proporciona 2 copias de seguridad independientes, una de las cuales puede ser un servicio de almacenamiento en la nube de alta disponibilidad, funciona en modo pull, por lo que la mayoría de los ataques en el sitio web no pueden destruir las copias de seguridad al mismo tiempo, y utiliza herramientas de código abierto bien probadas que no Requiere mucha administración.

• Las copias de seguridad independientes son críticas, porque los piratas informáticos a veces eliminan todas las copias de seguridad al mismo tiempo que piratean el sitio web; en el caso más reciente, los piratas informáticos destruyeron 4800 sitios web, incluidas las copias de seguridad al piratear el entorno de alojamiento web en lugar de los sitios. Vea también esta respuesta y esta .
• Restaurar es muy fácil con rsnapshot: hay un archivo en cada árbol de instantáneas para cada archivo respaldado, así que solo busque los archivos con las herramientas de Linux y rsync o regréselos al sitio web. Si el servidor de respaldo en el sitio no está disponible por alguna razón, solo use duplicidad para restaurarlo desde el servidor de respaldo en la nube, o puede usar herramientas estándar como GPG, rdiff y tar para restaurar los respaldos.

Dado que esta configuración utiliza SSH y rsync estándar, debería ser más fácil elegir un proveedor adecuado con las garantías de tiempo de actividad correctas, seguridad sólida, etc. No tiene que cerrar un contrato largo y si el servicio de respaldo tiene una catástrofe falla, aún tiene una copia de seguridad local y puede cambiar a otro servicio de copia de seguridad con bastante facilidad.

En cuanto al software, considere la duplicidad de copias de seguridad incrementales con cifrado asimétrico y un receptor mudo (no nube howto ).

Siempre les digo a mis clientes que la solución de copia de seguridad mejor, menos costosa y más eficiente es la que usted crea, para sus propios fines.

Cuando construyo un sistema para mis clientes, utilizo rsync con claves SSH para manejar la autenticación entre el servidor A y el servidor B, donde el servidor A contiene los datos a respaldar. El comando para archivar y sincronizar los datos está contenido en un script bash en un directorio no accesible desde la web, llamado por cron cada H horas (24 para diario, etc., etc.)

El servidor de respaldo, serverB, debe usarse SOLO para respaldos. Siempre aconsejo a mis clientes que utilicen una contraseña extremadamente larga con autenticación de clave SSH para permitir la descarga de copias de seguridad y copias de seguridad. A veces, mis clientes necesitan que se guarden copias de seguridad para los días D, así que escribo algunos scripts para manejar eso (tomar datos del directorio de copia de seguridad activo, aplicar una marca de tiempo, agregar a un archivo en otro directorio).

Para pequeñas empresas / prosumidores, recomendaría el servicio de almacenamiento de Amazon .

• Control de región (es decir, los objetos almacenados en una UE nunca salen de la UE).
• 99.9% de tiempo de actividad para cualquier ciclo de facturación
• $ 0.150 por GB almacenado por mes
• $ 0.170 por GB descargado
• Carga gratuita hasta junio de 2010, $ 0.10 por GB a partir de entonces

Y la garantía bastante vaga de que "se proporcionan mecanismos de autenticación para garantizar que los datos se mantengan seguros frente a accesos no autorizados"

Si bien bluenovember está en el camino correcto con S3, el sistema de Amazon no es realmente una solución de copia de seguridad directa, es una solución de almacenamiento de datos sin procesar que aún requiere un sistema front-end para la copia de seguridad, ya sea unas pocas llamadas API o un conjunto completo de gestión de copias de seguridad. Algo como JungleDisk Server Edition , que usa S3 en el backend pero proporciona una mejor interfaz para usar como solución de respaldo, probablemente sería mejor.

Además, JungleDisk le proporcionaría un cifrado integrado, algo que necesitaría agregar independientemente de cómo planee conectarse a S3 / "la nube". También tienen un software de cliente bastante bueno para Linux.

Me gusta almacenar mi copia de seguridad en Amazon AWS y uso la herramienta gratuita s3cmd ( http://s3tools.org/s3cmd )

Se puede instalar con bastante facilidad (Debian: apt-get install s3cmd).

Todo lo que necesita es una cuenta de Amazon AWS para almacenar sus archivos en S3. Luego, un comando simple puede ejecutar su copia de seguridad, incluso incremental o como una solución de sincronización, por ejemplo:

s3cmd sync /srv/backup  s3://your-bucket-name-at-amazon/

Asegúrate de correr

s3cms --configure 

primero en ingresar sus credenciales de AWS.