Muchas gracias Horacio por tu respuesta y muchas gracias a todos los que respondieron, me ayudo todo.
Saludos De: Horacio Miranda [mailto:hmira...@gmail.com] Enviado el: miércoles, 25 de septiembre de 2024 19:38 Para: Daymel Bonne Solís; Romero, Fernando CC: pgsql-es-ay...@postgresql.org Asunto: Re: Consulta backup Depende a que llamas grandes volumenes? Sobre las herramientas de respaldos y recuperación debes saber que hay dinstintos tipos de respaldos y recuperación. Dependiendo de tus SLA es lo que debes utilizar para poder recuperarte y dependiendo del tipo de operación que te genera la necesidad de volver atraz en el tiempo es el nivel de protección que vas a tener. Ejemplo, tienes base primaria y secundaria, con replicación por WAL, pero alguien se equivoca y hace un truncate de una tabla Importante, y te debes recuperar, eso es recuperación logica donde pg_dump te puede servir para recuperar una tabla especifica. Como te mensionan pg_dump no se considera una herramienta de recuperación, es una herramienta para generar respaldos logicos. pg_backup que es lo que las otras herramientas usan utiliza los WAL que son los archivos con transacciones generados cuando la base de datos esta en modo archive, (en Oracle es archivelog y redologs ). El modo archive te permite aplicar estas transaciones y recuperarte en el tiempo. sobre el pg_dump dependendiendo de lo que respaldas y como te recuperas junto con el compresor es lo que se demora. Ejemplo: una base de 400G que me genera un respaldo pg_dump usando zstd ( compresor nuevo del 2016 ) me queda en 55G y el respaldo es en paralelo. lo que es rapido y la recuperación tambien es en paralelo, mientras mas IOPS tengas y CPU mas rapido es el respaldo/recuperación de pg_dump y pg_restor ( usando -Fd -j (CPUs / 2 ) o algo que use la maquina bien. Dependiendo de tu hardware es que tan rapido es, pero recuerda esto es un DUMP logico, no es un respaldo fisico en caliente. es decir si estas dispuesto a perder las transacciones entre respaldos, esta bien. si necesitas algo mas robusto hay varias herramientas que te permiten recuperarte en el tiempo. Ten un ojo con PG17 que parece que van a incluir un respaldo diferencial, hay un commit hecho en el 2022 Dic que habla de eso. Para resumir, con pg16 -zstd ( debes tener el compressor zstd instalado ) y -Fd el respaldo es rapido. Sin -Fd y con -Fc ( puedes usar -j para pg_restore, el dump tiene una estructura que te permite recuperación en paralelo. Espero que esto te ayude a hacer unas pruebas y disminuir el tiempo de tus respaldos. Este articulo habla del zstd y te puede dar una idea de los tamaños generados. https://www.cybertec-postgresql.com/en/lz4-zstd-pg_dump-compression-postgresql-16/<%5b***%20El%20vinculo%20ha%20sido%20removido.%20%20***%5d> De hecho tengo ganas de escribir algo sobre esto por que zstd es super rapido. 300MB/s de entrada comprimiendo, y en un DL360G10 con CPU GOLD de 3.2Ghz descomprime a 1.45GB/s. PS: DE que tamaño estamos hablando ? On 26/09/2024 5:14 am, Daymel Bonne Solís wrote: Hola Fernando: pg_dump nunca se ha catalogado por ser una herramienta para recuperarse en caso de desastres. Mucho menos aplicable para grandes volúmenes de datos. Yo te recomiendo herramientas probadas y recomendadas por la comunidad, Barman, PgBackrest. Incluso hacer snapshots de volúmenes + WAL archivíng es mejor que utilizar pg_dump para respaldos. Saludos On 25 Sep 2024, at 11:43 AM, Romero, Fernando <fernando.rom...@trenesargentinos.gob.ar><mailto:fernando.rom...@trenesargentinos.gob.ar> wrote: Hola como están Consulta, actualmente estoy realizando respaldos en bases de datos con pg_dump, para las bases de datos de gran volumen los tiempos de respaldo de recuperación son altos. Según la experiencia de uds tendría que hacer backup lógicos o físicos (por ejemplo pg_basebackup). Me gustaría leer sus recomendaciones. Saludos “El contenido del presente mensaje (y sus anexos) es privado, confidencial y de exclusivo uso para el destinatario referenciado; es de público conocimiento que las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualquier otra manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y en los archivos adjuntos son propias del remitente y no representan la opinión o políticas de SOFSE, salvo que se diga expresamente y el remitente se encuentre autorizado para ello” “El contenido del presente mensaje (y sus anexos) es privado, confidencial y de exclusivo uso para el destinatario referenciado; es de público conocimiento que las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualquier otra manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y en los archivos adjuntos son propias del remitente y no representan la opinión o políticas de SOFSE, salvo que se diga expresamente y el remitente se encuentre autorizado para ello”
