ruby-on-rails - create - heroku postgres plans

¿Cómo prepararse para la pérdida de datos en un sitio web de producción? (4)

Estoy construyendo una aplicación que se está moviendo rápidamente hacia la producción y me preocupa la posibilidad de que debido a piratería, algún error personal tonto (como ejecutar rake db:schema:load o rake db:rollback ) u otras circunstancias podamos sufrir pérdida de datos en una tabla de base de datos o incluso en todo el sistema.

Si bien no es probable que ocurra lo anterior, sería negligente no estar preparado en caso de que alguna vez lo haga.

Estoy usando PG Backups de Heroku (que será reemplazado por otra cosa este mes), y también realizo copias de seguridad automáticas diarias en S3: http://trevorturk.com/2010/04/14/automated-heroku-backups/ , generando .dump archivos .dump

¿Cuál es la forma correcta de lidiar con la pérdida de datos en una aplicación de producción?

¿Cómo restauraría el archivo .dump en caso de que lo necesite? ¿Puedo hacer una restauración selectiva si se golpea una pequeña parte del sistema?
En caso de que no sea posible una restauración selectiva: supongamos que una tabla pierde datos 4 horas después de la última copia de seguridad. Resultado => ¿la fijación de la tabla perdida requeriría retroceder 4 horas de actividad de los usuarios? ¿Alguna buena solución para esto?
¿Cuál es la mejor manera de ayudar a los usuarios a superar los inconvenientes si ocurre algo como esto?

Acerca de las copias de seguridad, no puede estar seguro al 100 por ciento cada vez que no se perderán datos. Lo mejor es probarlo en otro servidor. Debe tener al menos dos tipos de copia de seguridad:

Una copia de seguridad de la base de datos, como pg-dump. Un volcado es exclusivo de comandos SQL, por lo que puede usarlo para recrear toda la base de datos, solo una tabla o solo unas pocas filas. Perdiste los datos agregados mientras tanto.
Una copia de seguridad de código, por ejemplo, un repositorio de git.

Una solución completa de DR (recuperación de desastres) requiere lo siguiente:

Multisite. Si un incendio, una inundación, Osama Bin Laden o lo que ocurre golpea al centro de datos de Amazon (¿o es Salesforce?) Que usa Heroku, debe asegurarse de que sus datos estén seguros en otro lugar.
Replicación continua de los datos a un sitio (o sitios) por separado. Eso significa que cada transacción que se escribe en su base de datos en un sitio, se replica en segundos a la base de datos reflejada en el otro sitio. La mayoría de los RDBMS tienen mecanismos para permitirle hacer una replicación maestro-esclavo así.
Lo mismo vale para cualquier cosa que coloque en un sistema de archivos fuera de la base de datos, como imágenes, archivos de configuración XML, etc. S3 es una buena solución aquí: replican todo en múltiples centros de datos por usted.
No me hará daño crear depósitos periódicos (diarios o similares) de la base de datos y almacenarlos por separado (por ejemplo, en S3). Esto lo ayuda a recuperarse de la corrupción de datos que se propaga a los DB esclavos.
Automatice el proceso de recuperación de datos. Quieres que esto funcione cuando lo necesites.
Prueba todo Lo ideal es que desee automatizar el proceso de prueba y ejecutarlo periódicamente para garantizar que sus copias de seguridad puedan restaurarse. Netflix Chaos Monkey es un ejemplo extremo de esto.

No estoy seguro de cómo implementarías todo esto en Heroku. Una solución completa todavía está fuera del alcance de la mayoría de las compañías: estamos ejecutando esto en nuestros propios centros de datos (uno en los EE. UU., Uno en la UE) y cuesta muchos millones. Trabaje de acuerdo con la regla 80-20: la copia de seguridad en curso en un sitio diferente, además de un plan de recuperación bien probado (prueba continuamente su capacidad de recuperación a partir de copias de seguridad) cubre el 80% de lo que necesita.

En cuanto a los usuarios que brindan soporte, la mejor solución es simplemente comunicar oportuna y verazmente cuando surgen problemas y asegurarse de no perder ningún dato. Si sus usuarios están pagando por su servicio (es decir, no están respaldados por publicidad), entonces probablemente debería tener un SLA en su lugar.

además de la respuesta de Hartator:

utilice la replicación si su DB lo ofrece, por ejemplo, al menos replicación maestro / esclavo con un esclavo
hacer copias de seguridad de la base de datos en un servidor de base de datos esclavo y almacenarlas externamente (por ejemplo, scp o rsync fuera de su servidor)
utilice un buen sistema de control de versiones para su código fuente, por ejemplo, Git
utilice un mecanismo de despliegue sólido, como Capistrano y escriba sus tareas personalizadas, para que nadie tenga que migrar las bases de datos a mano
Haga que alguien en quien confíe verifique la configuración de su firewall y la seguridad de su sistema en general

Los DB-Dumps contienen comandos SQL para recrear todas las tablas y todos los datos ... si tuviera que restaurar solo una tabla, podría extraer esa parte de una copia del archivo de volcado y (muy cuidadosamente) editarla y luego restaurarla con el archivo de volcado modificado (para una tabla).

Siempre restaure primero a una máquina independiente y verifique si los datos se ven bien. por ejemplo, podría usar un servidor esclavo, tomar si fuera de línea, luego restaurar allí localmente y verificar los datos. Bien si tiene dos esclavos en su sistema, entonces el sistema restante tiene todavía un maestro y un esclavo mientras restaura al segundo esclavo.

Para simular una "recuperación de desastres total" bastante simple en Heroku, cree otro proyecto de Heroku y replique completamente su aplicación de producción (excepto que use un nombre de dominio personalizado diferente).

Puede agregar múltiples destinos de git remotos a un único repositorio de git para que pueda usar su base de código de producción actual. Puede enviar sus copias de seguridad de la base de datos al proyecto replicado, y entonces debería estar listo para comenzar.

El único paso que falta en este ejercicio frente a una recuperación de desastres real es asignar su dominio de producción al proyecto Heroku replicado.

Si puede permitirse ejecutar dos copias de su aplicación en paralelo, puede automatizar este ejercicio y hacer que se replique de forma periódica (p. Ej., Por hora, por día) en función de su tolerancia a la pérdida de datos.