EC2 - ¿Cómo hacer una copia de seguridad correcta de los datos de PostgreSQL?

Aquí está la configuración: 1 pequeña instancia EC2 de Amazon Linux (respaldada por EBS) con 3 volúmenes adicionales. Este es un servidor web y un servidor de base de datos. Un volumen para el código, uno para el directorio de datos PostgreSQL (8.4) y un volumen para almacenar archivos WAL de PostgreSQL.

(1) El volumen con archivos WAL también tendrá una copia de seguridad base del directorio de datos, que se copia después de hacer un pg_start_backup (). Luego almacenará la salida del archivo continuo de PostgreSQL (archivos WAL). Para hacer una instantánea de este volumen, ¿hay algún punto en emitir una sincronización y congelar el sistema de archivos (usando xfs_freeze si es XFS o dmsetup si es EXT4)? ¿O puedo tomar una instantánea en vivo? Los archivos WAL se enviarán a una velocidad de uno por minuto. ¿Es posible que se pueda iniciar una instantánea mientras se copia un solo archivo WAL y se producen datos corruptos?

(2) El volumen que contiene el directorio de datos de PostgreSQL en vivo también se realizará una copia de seguridad (a diario). Antes de hacer una instantánea de este volumen, emito un pg_dump y el archivo SQL resultante se mantiene en el directorio de datos. ¿Hay algún punto en tomar precauciones para garantizar que los datos reales de la base de datos sean consistentes? ¿Sería correcto suponer que tomar una instantánea en vivo correctamente (a) respaldará los archivos de configuración (postgresql.conf, pg_hba.conf, pg_ident.conf) y (b) respaldará el archivo de volcado SQL. Hacer una copia de seguridad de esas dos cosas, el archivo de volcado sql y los archivos de configuración, sería el punto principal de capturar este volumen. La base de datos no es muy grande, así que no me importa el hecho de que los archivos de datos llenen esta instantánea. Y en ese caso, puedo hacer una instantánea en vivo, ¿correcto?

(2a) ¿Sería mejor mantener el directorio de datos en el volumen raíz y tener una secuencia de comandos de copia de seguridad que copie el archivo de volcado sql, así como los archivos de configuración en otro volumen, y tome una instantánea de ese volumen una vez que la copia esté hecha?

(3) En cuanto al volumen con código, ¿hay algún punto en sincronizar y congelar el sistema de archivos? ¿O solo se puede tomar una instantánea en vivo? Estos datos deberían ser bastante "estáticos".

(4) ¿Es este un esquema de respaldo sólido? No se realiza una copia de seguridad del volumen raíz de forma regular, ya que solo mantendré una imagen de la máquina una vez que esté configurada y configurada.

Gracias

Ver el buen manual . Si mi consejo entra en conflicto con su 'de alguna manera, es correcto.

1. Una sincronización no es una mala idea, a menos que su herramienta de copia fsync () s cada archivo WAL que escribe y el directorio en el que está antes de copiar el siguiente. Un último archivo WAL incompleto no importa mucho; en el peor de los casos, simplemente lo eliminas. Pg generalmente se atragantará con un WAL incompleto, aunque no se ha realizado una suma de comprobación, por lo que podríaser realmente desafortunado y hacer que intente aplicar datos basura que por pura casualidad parecían registros WAL reales. En su posición, estaría sincronizando el volumen antes de una instantánea para asegurarme de que cualquier búfer sucio no escrito en la RAM golpee la imagen del sistema de archivos en el disco. Un congelamiento ayudaría a evitar los WAL desordenados pero no fatales escritos parcialmente, por lo que no es una idea terrible pero no es vital. Lo vital es tener una línea de tiempo sin daños hasta el punto de recuperación. Personalmente, escribo mis WAL en un nombre de archivo temporal y los renombro a su nombre final solo una vez que están completamente copiados; si haces esto, no necesitas congelarte.

2. Suena correcto Una instantánea en vivo es como hacer una prueba de extracción de enchufe en un sistema en vivo con almacenamiento en caché de escritura. Su base de datos debería recuperarse bien cuando se restaure desde una instantánea en vivo, igual que después de plug-pull. Le recomiendo que automatice las pruebas de restauraciones a partir de instantáneas. (Nota: Una prueba de restauración de instantáneas no es un sustituto completo de la prueba de extracción de enchufe porque no tiene en cuenta el posible almacenamiento en caché de disco, controlador de incursión, etc.). No solo los archivos de configuración y el volcado, sino que la base de datos en sí misma debería estar bien después de su instantánea. Considere sincronizar el volumen antes de la instantánea para asegurarse de que todos los datos de volcado, etc., hayan llegado al disco.
   
   2a. Podría ahorrar algo de espacio en disco. Poca diferencia de lo contrario. Podrá mantener las instantáneas mucho más tiempo sin toda la rotación de la base de datos en vivo en ellas.

3. ¿Por qué incluso capturar el volumen de su código? Una copia a nivel de archivo puede estar bien. Ciertamente, debería ser una instantánea en vivo.

4. Este no es un esquema de respaldo sólido. Falla en un área crítica: no se realizan pruebas de restauración y validación. Siempre debe probar sus copias de seguridad regularmente para asegurarse de que realmente pueda restaurarlas.

   Personalmente, le recomiendo que use el envío de WAL o envíe volcados de la base de datos a un host diferente , preferiblemente uno que no esté en Amazon EC2 o al menos en una región diferente. Este host debe realizar pruebas de restauración automáticas, enviarle informes de los resultados y también debe verificarse manualmente.

   Si bien sus instantáneas (que contienen volcados) estarán en S3, y estarán a salvo allí, eso no significa que estarán accesibles cuando las necesite con urgencia. Las afirmaciones de durabilidad de Amazon son tranquilizadoras, pero sus datos aún pueden ser seguros y completamente inaccesibles para usted durante una interrupción del servicio S3 en el momento oportuno.