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/
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> 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”
